# Partner API credentials Adrasis exposes a read-only Distribution API that partner systems — booking aggregators, internal B2B tooling, channel operators — can call directly to retrieve property catalogs, search live offers and pull pricing snapshots. Each partner authenticates with a dedicated credential issued through the Console, in one of three authentication mechanisms picked to fit the partner's integration profile. ## Pick an authentication mechanism | Mechanism | When it fits | What the partner sends | | -------------- | ---------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | | **OAuth 2.0** | Modern partners that already speak OAuth — booking aggregators, large B2B platforms. | Exchange `client_id` + `client_secret` for a short-lived access token; send the token on every call. | | **HTTP Basic** | Legacy integrations that grew up around fixed username + password headers. | Send `username` + `password` on every call. | | **API Key** | Self-serve developer integrations — internal tools, dashboards, lightweight back-office. | Send a single long-lived bearer key on every call. | The operator picks the mechanism once at credential-creation time. Different partners on the same operator account can use different mechanisms — the rest of the Console (scopes, lifecycle, audit) stays identical across all three. ## When to issue a credential Operators issue a new credential every time a fresh partner integration goes live — one credential per integration, never reused across partners. Common triggers: * A new B2B aggregator agreement and the partner needs technical access. * An in-house client (operator's own back-office, kiosk, internal analytics) needs read access to live offers. * A connector partner needs a dedicated identity scoped to one channel context so its activity stays auditable. Operators never share a single credential across partners. Audit trails, revocation and rate-limit accounting all key off the credential, so a shared credential erases the line between "partner X misbehaved" and "partner Y misbehaved". ## How the partner uses the credential ### OAuth 2.0 The partner runs a two-step flow on every refresh cycle: 1. **Authenticate.** Post `client_id` + `client_secret` to the Adrasis token endpoint. Adrasis verifies the secret, checks the credential is active and returns a short-lived access token plus its remaining lifetime in seconds. 2. **Call the Distribution API.** Send the access token in `Authorization: Bearer ` on every request. Access tokens are valid for one hour. The partner caches the token until expiry, then re-authenticates. There is no refresh token — the round trip to swap a fresh access token is intentionally simple so a compromised token cannot survive past its natural lifetime. ### HTTP Basic The partner sends `Authorization: Basic ` on every request. No token-mint round trip — Adrasis verifies the credential on each call. For partners coming from older B2B channels this is the most familiar shape. ### API Key The partner sends `Authorization: Bearer adr_<32-character body>` on every request. The key is generated server-side at creation time, returned exactly once, and remains valid until rotated or revoked. This is the shape modern developer-tools APIs use (Stripe-style) — the simplest possible integration. ## Scopes Scopes pin which endpoints the credential can reach. The same two scopes apply regardless of authentication mechanism: | Scope | What it grants | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `distribution:read` | All read endpoints — live offer search, property catalog feed, diagnostic and metadata endpoints. | | `distribution:booking` | Booking commit, modify and cancel endpoints (reserved for future release; available on credentials so partners do not need to rotate when booking goes live). | Every new credential carries both scopes by default so a partner onboarded today does not have to rotate when booking endpoints land. Operators can adjust the set during rotation when downscoping is needed. ## Lifecycle controls After a credential is issued, operators have three lifecycle levers — all reachable from the **Distribution API Credentials** page: * **Rotate** — Generates a fresh secret on the same credential row. The public identifier (`client_id` / `username` / row-level public\_id) stays stable; only the secret part changes, so the partner swaps a single value to keep operating. Operators rotate proactively on a fixed cadence (typically every quarter) and reactively the moment a secret is suspected leaked. * **Disable** — Pauses authentication. Subsequent requests are refused; OAuth tokens already minted before the disable keep working until they expire naturally. Use this when an integration is temporarily off (testing, maintenance, partner is suspended pending review). * **Revoke** — Marks the credential permanently dead. New requests are refused immediately and the row drops off the active list. OAuth access tokens already minted continue to be honoured until they expire (the one-hour token window also bounds the maximum exposure). Basic and API-key credentials are cut off after the verifier's short caching window. For a hard immediate cutover during a security incident, contact Adrasis support to rotate the global signing key. ## What operators see Each credential row carries an operator-friendly label (`Partner A — production`, `Internal back-office`, etc.) plus: * The authentication mechanism the credential uses (OAuth 2.0 / HTTP Basic / API Key). * The public identifier the partner sends (`client_id`, `username`, or API key prefix — never the full secret). * The bound connector context — every credential is tied to one connector, so partner activity stays mapped to its channel. * The scope set granted to the credential. * Lifecycle status — Active, Disabled or Revoked. * Last successful authentication timestamp — the simplest stale-credential signal. The plain-text secret never appears in any list, audit log or export after the initial one-time reveal. ## Operational discipline Three rules keep the partner API safe: 1. **Never email or paste secret values into chat.** Adrasis surfaces a copy button and a "I have safely shared this with the partner" acknowledgement on the one-time reveal for exactly this reason. 2. **Rotate on a schedule, not only on incident.** Quarterly rotation is the lowest-friction cadence that keeps secrets fresh without disturbing partners — applies to all three mechanisms. 3. **One credential per partner integration.** When a partner stands up a new environment (staging, production, disaster recovery), each environment gets its own credential row. ## Related * [Channels](/console/distribution/channels.md) — how connectors are configured before a credential is issued. * [Bedbank distribution (supplier feed)](/console/distribution/outbound/bedbank-distribution.md) — outbound feed scenarios that consume the Distribution API. * [Metasearch & B2B platforms](/console/distribution/outbound/metasearch.md) — partner families that typically consume read scope. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://adrasis.gitbook.io/console/distribution/outbound/partner-api-credentials.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.