Zum Inhalt springen

Umgebungen, Limits und Versionierung

Eine Basis-URL für Sandbox und Produktion; der Schlüssel, mit dem Sie signieren, wählt die Umgebung.

  1. Sandbox und Produktion, eine Basis-URL
  2. Ratenlimits und Kontingente
  3. Look-to-Book-Schutz
  4. Idempotenz
  5. Versionierung

Sandbox und Produktion, eine Basis-URL

Basis-URL: https://api.dubaitrip.com/v1. Sandbox und Produktion teilen sie sich; der Schlüssel, mit dem Sie signieren, wählt die Umgebung. Ein dt_sbx_-Schlüssel läuft gegen die Testumgebungen unserer Anbieter – Suchen, Bepreisung, Ratenprüfungen, Aufträge, Buchungen, Ticketausstellung und Stornierungen funktionieren durchgängig mit Testangebot, ohne echtes Ticket oder echten Voucher und ohne Belastung. Ein dt_live_-Schlüssel, ausgestellt nach der Produktionsprüfung, erreicht das Live-Angebot und wird mit Ihrer Einlage verrechnet.

Sandbox- und Produktionsbuchungen werden in Ihrem Entwicklerportal getrennt geführt (jede Buchung ist gekennzeichnet), und Berechtigungen, Limits und IP-Regeln werden pro Umgebung verwaltet.

Ratenlimits und Kontingente

Jeder Schlüssel wird durch einen Token-Bucket (dauerhafte Anfragen pro Sekunde plus Burst) und ein Tageskontingent gedrosselt. Sandbox-Standardwerte: 2 Anfragen/Sekunde, Burst 5, 2.000 Anfragen/Tag. Produktionslimits werden pro Konto vereinbart. Wird der Bucket überschritten, lautet die Antwort 429 api_rate_limited mit einem Retry-After-Header; ist das Kontingent aufgebraucht, lautet sie 429 api_quota_exceeded bis Mitternacht UTC.

Aufwendige Suchen sind bewusst asynchron: Übergeben Sie wait=false, um sofort eine searchId zu erhalten und den Such-Endpunkt abzufragen, oder wait=true, um das vollständige Ergebnis in einem Aufruf zu erhalten. Abfragen zählen wie jede andere Anfrage gegen Ihre Limits.

Look-to-Book-Schutz

Suchen werden außerdem im Verhältnis zu Ihren Buchungen kontingentiert. Jeder Tag eines gleitenden Zeitfensters (standardmäßig 7 Tage) gewährt ein kostenloses Suchkontingent, und jede in diesem Fenster getätigte Buchung fügt weitere cap Suchen hinzu – cap ist der für Ihr Konto vereinbarte Wert für Suchen pro Buchung, der im Entwicklerportal angezeigt wird. Abfragen, Bepreisung, Tarifregeln und Inhaltsabrufe zählen nie; nur Flug- und Hotelsuchaufrufe zählen.

Ist das Kontingent aufgebraucht, antworten Suchen mit 429 look_to_book_exceeded und einem Retry-After-Header, der auf die nächste Mitternacht UTC zeigt, wenn der älteste Tag aus dem Fenster fällt. Eine Buchung öffnet das Kontingent sofort wieder. Die Look-to-Book-Karte im Entwicklerportal zeigt die Live-Zähler, die Obergrenze und das verbleibende Kontingent; wenn Ihre Integration legitimerweise weit mehr sucht als bucht, bitten Sie uns, die Obergrenze anzuheben, statt die Ablehnung mit Wiederholungen zu umgehen.

Idempotenz

Endpunkte, die Geld oder Kontingent verbindlich binden – Auftrag oder Buchung erstellen, ausstellen, stornieren –, erfordern einen Idempotency-Key-Header (eine beliebige eindeutige Zeichenfolge bis 128 Zeichen, eine UUID ist ideal). Ein erneuter Versuch mit demselben Schlüssel liefert die ursprüngliche Antwort, statt ein Duplikat zu erzeugen; ein anderer Body unter einem wiederverwendeten Schlüssel wird mit 409 beantwortet.

Versionierung

Die Version steht im Pfad (/v1). Additive Änderungen – neue optionale Felder, neue Enum-Werte, neue Endpunkte – werden ohne Versionssprung ausgeliefert; parsen Sie also defensiv und ignorieren Sie unbekannte Felder. Inkompatible Änderungen erhalten eine neue Hauptversion mit einem Migrationszeitraum; der Leitfaden Änderungsprotokoll listet jede Änderung auf.