Spring til indhold

Miljøer, grænser og versionering

Én basis-URL til testmiljø og produktion; den nøgle, du signerer med, vælger miljøet.

  1. Testmiljø og produktion, én basis-URL
  2. Hastighedsgrænser og kvoter
  3. Look-to-book-grænse
  4. Idempotens
  5. Versionering

Testmiljø og produktion, én basis-URL

Basis-URL: https://api.dubaitrip.com/v1. Testmiljø og produktion deler den; den nøgle, du signerer med, vælger miljøet. En dt_sbx_-nøgle kører mod vores leverandørers testmiljøer — søgninger, prissætning, pristjek, ordrer, bookinger, billetudstedelse og afbestillinger fungerer alle fra start til slut på testudbud, uden rigtige billetter eller vouchere og uden at noget bliver opkrævet. En dt_live_-nøgle, der udstedes efter produktionsgennemgangen, rammer det rigtige udbud og afregnes mod dit depositum.

Bookinger i testmiljø og produktion holdes adskilt i din udviklerportal (hver booking er markeret), og adgangsområder, grænser og IP-regler administreres pr. miljø.

Hastighedsgrænser og kvoter

Hver nøgle begrænses af en token bucket (vedvarende forespørgsler pr. sekund plus en spidskapacitet) og en daglig kvote. Standard i testmiljøet: 2 forespørgsler/sekund, spidskapacitet 5, 2.000 forespørgsler/dag. Grænser i produktion aftales pr. konto. Overskrides bucket, svares der 429 api_rate_limited med en Retry-After-header; er kvoten opbrugt, svares der 429 api_quota_exceeded indtil midnat UTC.

Tunge søgninger er asynkrone af design: send wait=false for straks at få et searchId og polle søge-endpointet, eller wait=true for at modtage hele resultatet i ét kald. Polling tæller med i dine grænser som enhver anden forespørgsel.

Look-to-book-grænse

Søgninger rationeres også i forhold til de bookinger, du foretager. Hver dag i en glidende periode (som standard 7 dage) giver en gratis kvote af søgninger, og hver booking foretaget i perioden lægger yderligere cap søgninger oveni — cap er det antal søgninger pr. booking, der er aftalt for din konto og vises i udviklerportalen. Polling, prissætning, prisregler og indholdsopslag tæller aldrig med; kun søgekald for fly og hoteller gør.

Når kvoten er brugt, svarer søgninger 429 look_to_book_exceeded med en Retry-After-header, der peger på næste midnat UTC, hvor den ældste dag i perioden falder ud. En booking åbner straks kvoten igen. Look-to-book-kortet i udviklerportalen viser de aktuelle tællere, loftet og hvad der er tilbage; hvis din integration legitimt søger langt mere, end den booker, så bed os hæve loftet i stedet for at prøve igen gennem afvisningen.

Idempotens

Endpoints, der binder penge eller udbud — oprettelse af en ordre eller booking, udstedelse, afbestilling — kræver en Idempotency-Key-header (en vilkårlig unik streng på op til 128 tegn; et UUID er ideelt). Et nyt forsøg med samme nøgle returnerer det oprindelige svar i stedet for at oprette en dublet; en anden brødtekst under en genbrugt nøgle besvares med 409.

Versionering

Versionen står i stien (/v1). Tilføjende ændringer — nye valgfrie felter, nye enum-værdier, nye endpoints — udgives uden versionsskift, så parse defensivt, og ignorér ukendte felter. Bagudinkompatible ændringer får en ny hovedversion med en migreringsperiode; guiden Ændringslog oplister alle ændringer.