Errori e limiti

Anteprima: non è ancora attivo nulla. Qui è descritto il contratto dell’API di distribuzione (versione 1.0.0).

Errori

Una richiesta rifiutata risponde con un problema RFC 9457, Content-Type: application/problem+json:

{
  "type": "https://api.gridbeds.com/problems/insufficient-scope",
  "title": "…",
  "status": 403,
  "code": "insufficient_scope",
  "required_scopes": ["read:ari"],
  "instance": "urn:uuid:5f0c6f0e-6a53-4a8e-9f57-3c1f0f0b8b1d",
  "request_id": "5f0c6f0e-6a53-4a8e-9f57-3c1f0f0b8b1d"
}

Campo
`type`	Un URL che nomina il problema, `https://api.gridbeds.com/problems/<slug>`, e porta a una pagina che lo descrive.
`code`	Un identificativo stabile del rifiuto. Decidi in base a `code` o `type`.
`title`	Per una persona, nella lingua di `Accept-Language`. Non decidere mai in base a questo.
`status`	Lo stato HTTP.
`detail`	Quando c’è, altri dettagli su questo caso.
`request_id`	Uguale all’intestazione `Request-Id` e a `instance` (`urn:uuid:<Request-Id>`). Indicalo quando scrivi all’assistenza.

Una validazione fallita (invalid_parameters) aggiunge errors, una voce per ogni regola violata, ognuna con un detail, il code della regola (max, date_format, url_not_allowed, max_nights, …) e dove è fallita: parameter, header o pointer (un JSON Pointer RFC 6901 nel corpo della richiesta).

Stato	`code`
400	`invalid_parameters`, `invalid_cursor`, `window_beyond_horizon` (con l’`horizon_end` della struttura)
401	`missing_api_key`, `invalid_api_key`, `api_key_wrong_environment`, `api_key_expired`, `api_key_revoked` (Autenticazione)
403	`insufficient_scope` (con `required_scopes`), `partner_suspended`
404	`not_found`: la risorsa non esiste, non ti è mai stata distribuita, appartiene a un altro canale o ha un id malformato, oppure (per la disponibilità) la struttura è ritirata o cancellata. La risposta è identica in tutti i casi.
405	`method_not_allowed`
409	`webhook_endpoint_exists`, `webhook_endpoint_limit_reached`, `webhooks_suspended_by_platform`, `webhook_endpoint_still_failing`
410	`sync_window_expired`, `event_cursor_expired` (Sincronizzazione)
415	`unsupported_media_type`
429	`rate_limited`, `too_many_failed_authentications`
500	`internal`
503	`service_unavailable`

Come ogni enumerazione qui, l’elenco dei codici è aperto: tratta un codice che non conosci in base al suo stato. 405 e 503 ricevono la stessa risposta su ogni percorso.

Limiti di richieste

Il limite del tuo canale è un numero di richieste al minuto, almeno 600; GET /channel te lo dà in rate_limit.per_minute. Ogni risposta autenticata conta, rifiuti compresi, e dice quanto ne resta:

Intestazione
`RateLimit-Limit`	Le richieste consentite nella finestra.
`RateLimit-Remaining`	Le richieste che restano.
`RateLimit-Reset`	I secondi al reset della finestra.
`RateLimit-Policy`, `RateLimit`	Le stesse informazioni, nella forma della bozza IETF `draft-ietf-httpapi-ratelimit-headers`, per esempio `"partner";q=600;w=60` e `"partner";r=598;t=37`. Provvisorie: il contratto stabile sono le tre intestazioni sopra.

Una pagina di GET /availability costa max(1, ceil(nights / 1000)) unità invece di una. Oltre il limite la risposta è 429 con l’intestazione Retry-After, i secondi da aspettare prima di riprovare. Ripetuti tentativi di autenticazione falliti dallo stesso indirizzo ricevono 429 allo stesso modo.

Guida

Riferimento

Errori

Limiti di richieste

​Errori

​Limiti di richieste

Errori

Limiti di richieste