المصادقة
بيانات اعتماد OAuth 2.0 ورموز محددة النطاق ورؤوس المستأجر.
TravelCore uses OAuth 2.0 client credentials. You exchange a client id and secret for a short-lived bearer token, then send that token on every request. There are no long-lived API keys in the request path, because a leaked key that never expires is the worst failure mode in this category of system.
Headers on every call
| Header | Required | Purpose |
|---|---|---|
| Authorization | Yes | Bearer <access_token> from the token endpoint. |
| X-TravelCore-Tenant | Yes | Which tenant the call acts on. A token may be authorised for more than one. |
| Idempotency-Key | On writes | A UUID you generate. Replays return the original result. |
| X-Request-Id | Optional | Your correlation id. Echoed back and stored in our logs. |
| Accept-Language | Optional | Content language, where the supplier provides it. |
Scopes
Tokens are scoped per capability, and the scopes you request must be a subset of what your client is authorised for. Ask for the narrowest set the calling service needs, so a compromised service cannot book.
| Scope | Allows |
|---|---|
| hotels.search | Search, property content and rate checks. |
| hotels.book | Booking creation, retrieval and cancellation. |
| bookings.read | Read-only access across product types. |
| admin.pricing | Reading and modifying pricing rules. |
| admin.suppliers | Supplier configuration and credentials. |
ملاحظة:Client secrets are displayed once at creation and are not retrievable afterwards. Rotate by creating a second credential, migrating traffic, then revoking the first — there is no downtime path that involves us emailing you a secret.