Environments, limits and versioning
One base URL for sandbox and production; the key you sign with selects the environment.
Sandbox and production, one base URL
Base URL: https://api.dubaitrip.com/v1. Sandbox and production share it; the key you sign with selects the environment. A dt_sbx_ key runs against our suppliers’ test environments — searches, pricing, rate checks, orders, bookings, ticketing and cancellations all work end to end on test inventory, with no real ticket or voucher and nothing charged. A dt_live_ key, issued after the production review, reaches live inventory and settles against your deposit.
Sandbox and production bookings are kept apart in your developer portal (each booking is marked), and scopes, limits and IP rules are managed per environment.
Rate limits and quotas
Each key is throttled by a token bucket (sustained requests per second plus a burst) and a daily quota. Sandbox defaults: 2 requests/second, burst 5, 2,000 requests/day. Production limits are agreed per account. Exceeding the bucket answers 429 api_rate_limited with a Retry-After header; exhausting the quota answers 429 api_quota_exceeded until midnight UTC.
Heavy searches are asynchronous by design: pass wait=false to get a searchId immediately and poll the search endpoint, or wait=true to receive the complete result in one call. Polling counts against your limits like any other request.
Look-to-book guard
Searches are also rationed against the bookings you make. Every day of a trailing window (7 days by default) grants a free allowance of searches, and every booking made in that window adds another cap searches on top — cap is the searches-per-booking figure agreed for your account and shown on the developer portal. Polls, pricing, fare rules and content reads never count; only flight and hotel search calls do.
Once the allowance is spent, searches answer 429 look_to_book_exceeded with a Retry-After header pointing at the next midnight UTC, when the oldest window day drops out. A booking reopens the allowance immediately. The developer portal's Look-to-book card shows the live counters, the cap and what is left; if your integration legitimately searches far more than it books, ask us to raise the cap rather than retrying through the refusal.
Idempotency
Endpoints that commit money or inventory — creating an order or booking, issuing, cancelling — require an Idempotency-Key header (any unique string up to 128 characters, a UUID is ideal). Retrying with the same key returns the original response instead of creating a duplicate; a different body under a reused key answers 409.
Versioning
The version is in the path (/v1). Additive changes — new optional fields, new enum values, new endpoints — ship without a version bump, so parse defensively and ignore unknown fields. Breaking changes get a new major version with a migration window; the Changelog guide lists every change.