DAM connection
How a partner connects an end user to a DAM provider.
A CI HUB access token from Exchange token identifies the user inside CI HUB. It does not grant access to any DAM the user wants to browse. The DAM provider (Bynder, AEM, Frontify, and so on) authenticates the end user separately and returns its own access token. The partner platform sends both tokens on every content call (the two-token pattern, summarized in the overview).
Flow
The partner platform starts a login by posting to /auth/login?provider={id}&polling=true. CI HUB returns a one-time redirect_uri and a state token. The partner opens the redirect URI in the end user's browser, where the end user signs in at the DAM. While that runs, the partner polls /auth/login?state={state}&polling=true, which returns an empty object until the login completes. The completed poll returns an access_token and a refresh_token. If the state is unknown, expired, or already consumed, or the end user did not finish signing in, the poll still answers 200 but carries an error property instead of tokens; treat any body with error as final and start a new login. The partner sends the access_token as provider-authorization on every content call. Full detail is on the DAM login reference.
Token storage
The partner platform stores DAM connection tokens. CI HUB does not persist them server-side. Each DAM has its own lifetime and refresh model, so the partner caches the token and refreshes it before expiry.
Refresh
Refresh behavior varies per provider. Where a provider supports it, the partner renews a connection through /auth/refreshToken with the DAM refresh token; where it does not, the partner starts a fresh login. Handle both with one path: try refresh, fall back to login. See Token refresh for the request and how the try-then-fallback pattern covers providers without a refresh path.