Skip to main content
Headless agents — CI runners, containerised workers, server-side pipelines — cannot open a browser to complete the authorization-code + PKCE flow. The OAuth 2.0 device-authorization grant (RFC 8628) is the correct mechanism for these callers: the agent requests a short user_code, the human operator approves it in a browser, and the agent polls the token endpoint until it receives an access token. For a full comparison of all supported authentication methods, see Authentication.

Flow overview

1

Request device and user codes

The agent sends POST /v1/oauth/device_authorization and receives a device_code, user_code, verification_uri, expires_in, and interval.
2

Display the code to the operator

The agent displays the user_code and verification_uri to the human operator — log them to a console, embed in a CLI prompt, or generate a QR code from verification_uri_complete.
3

Operator approves in a browser

The operator opens verification_uri, enters the user_code, and approves access. No action is required from the agent during this step.
4

Agent polls for the access token

The agent polls POST /v1/oauth/token with grant_type=urn:ietf:params:oauth:grant-type:device_code at the prescribed interval until it receives an access token or a terminal error.

Device-authorization request

Successful response (HTTP 200):

Poll loop

After the device-authorization request succeeds, poll POST /v1/oauth/token at interval-second intervals. On each slow_down response, permanently increase the interval by 5 seconds for the remainder of the session. Stop when you receive an access token or a terminal error.

Error codes

The following error codes may be returned by POST /v1/oauth/token during the poll loop:
Never poll faster than the current interval value. Each slow_down error permanently increases the required interval for that session. Repeated fast polling may result in the session being terminated with access_denied.

Token response

A successful poll returns HTTP 200 with a token response:
Use the access token as a Bearer token on subsequent API requests:
The refresh token can be exchanged for a new access token via the standard refresh_token grant at POST /v1/oauth/token before the access token expires.

TTLs at a glance


Client registration

If you do not yet have a client_id, register your OAuth client with POST /v1/oauth/register (RFC 7591 dynamic client registration) before starting the device flow. Public clients (no client secret) are supported. See the OAuth register endpoint.

See also

  • Authentication — full auth method comparison (passkeys, MFA, SSO, API keys)
  • API Keys — server-to-server auth without OAuth; simpler for non-delegated agent calls
  • API reference overview — auth header formats and rate limits