Getting started
The end-to-end path from partner registration to your first content call.
This walkthrough orders the Access SDK endpoints into the path a partner platform follows the first time it connects a user to a DAM. Each step links to its full reference. No code is reproduced here; follow the links for request and response detail.
Building in TypeScript or JavaScript? Read this page for the flow, then implement it with the client library, which wraps every step behind typed methods.
Working with AI
The docs assistant answers Access SDK questions and cites the pages behind each answer. Open it from the Ask AI button in the bottom right of any page. Building against the API with an AI agent of your own? Point it at /access/llms.txt for a page index, or /access/llms-full.txt for every page as plain text.
Before you start
Two things are set up with CI HUB during onboarding:
- Partner registration. CI HUB registers your issuer and the URL of your JWKS, so it can verify the JWTs your backend signs. See Partner registration.
- An SDK subscription. Your platform's subscription is what authorizes SDK use. Commercial terms are agreed during onboarding.
The walkthrough assumes you have both.
1. Exchange a token
Your backend signs a short-lived JWT for the current user and posts it to CI HUB. CI HUB verifies the signature against your JWKS, checks the subscription, and returns a CI HUB access token and refresh token. This call is server to server, with no browser redirect. See Exchange token.
The access token identifies the user inside CI HUB. It travels in the Authorization header on every later call.
2. List the providers
With the access token, ask CI HUB which DAM providers the user can connect to. The result drives your connection picker. Send the access token here: without it the endpoint returns only a single degraded entry, not the real list. See Providers.
3. Connect the user to a DAM
The access token identifies the user inside CI HUB but does not grant access to any DAM. Each DAM authenticates the user separately.
Start a login for the chosen provider. CI HUB returns a one-time URL and a state token. Open the URL in the user's browser so they sign in at the DAM, and poll with the state until the login completes. The completed poll returns a DAM connection token. See DAM login for the initiate and poll calls, and DAM connection for the model behind them.
4. Read the connection details
Once the user is connected, read the provider's runtime details (its host, the search filters it exposes, and other provider-specific settings) to shape your UI. See Provider info.
5. Make content calls
Content calls carry two tokens: the CI HUB access token in Authorization, and the DAM connection token from step 3 in provider-authorization. The first identifies the user, the second authorizes access to the DAM. The two-token pattern is described in the authentication overview.
Keeping the session alive
The CI HUB access token expires after an hour. Use the refresh token to mint a new one without a fresh exchange. See Refresh token. The DAM connection token has its own lifetime per provider; renew it as covered under DAM connection.