Skip to main content
For AI agents: a documentation index is available at https://docs.parallel.ai/llms.txt. The full text of all docs is at https://docs.parallel.ai/llms-full.txt. You may also fetch any page as Markdown by appending .md to its URL or sending Accept: text/markdown.For Search and Extract, use /v1/search and /v1/extract for all new integrations and agent tool calls. Use /v1beta/search and /v1beta/extract only when maintaining an existing integration that already uses them. Do not substitute /v1 for the documented FindAll or Ingest endpoint paths.
The Account API lets your application call Parallel programmatically on behalf of a user without prompting them to paste an API key. Authentication uses the OAuth 2.0 Device Authorization Grant (RFC 8628), which is designed for clients without a browser or with limited input — CLIs, IDE plugins, IoT devices, and similar. The flow produces an access token that you pass as a Bearer token on every Account API request. See the full endpoint reference in the Account API tab in the navigation.
The Parallel CLI handles the entire device-OAuth flow for you — register, device code, polling, refresh, and revoke — and exposes every Account API endpoint as a regular CLI command. If you don’t need to embed the flow in your own application, the CLI is the fastest way to use the Account API. The rest of this page describes what the CLI does under the hood, for clients that need to implement it themselves.

​
Base URL

All endpoints below are rooted at:

​
Overview

The full lifecycle is:
  1. Register your client once, to obtain a client_id.
  2. Request a device code to start an authorization session.
  3. Prompt the user to verify in their browser using the verification URL and user code returned in step 2.
  4. Poll the token endpoint until the user approves and you receive an access_token and refresh_token.
  5. Call the Account API with Authorization: Bearer <access_token>.
  6. Refresh the access token when it expires, or revoke the refresh token when the user signs out.
The access_token returned by step 4 is what authorizes Account API calls. Without a valid bearer token, requests to the Account API will be rejected.

​
1. Register your client

Register your application once to receive a client_id. Send a description of your client and the platform it runs on:
The response contains a client_id you reuse for all subsequent device-code requests from the same installation.

​
2. Request a device code

Start an authorization session by requesting a device code. The body is application/x-www-form-urlencoded:
The response includes:
  • device_code — opaque code your client uses when polling the token endpoint.
  • user_code — short code the user types in the browser.
  • verification_uri (and typically verification_uri_complete) — the URL to send the user to.
  • expires_in — lifetime of the device code, in seconds.
  • interval — minimum number of seconds to wait between polls.
Display the user_code and verification_uri to the user, or open verification_uri_complete in their browser directly.

​
3. Poll for the access token

While the user completes verification in the browser, poll the token endpoint at the interval the server specified:
Polling returns one of:
  • authorization_pending — user has not yet approved. Wait interval seconds and try again.
  • slow_down — you are polling too fast. Increase your interval.
  • access_denied — the user rejected the request. Stop polling.
  • expired_token — the device code expired. Restart from step 2.
  • Success — a JSON body containing access_token, refresh_token, token_type (Bearer), and expires_in.
Once you have the access_token, you can call the Account API.

​
4. Call the Account API

Every Account API request must include an Authorization header with the access token from step 3:
Requests without a valid bearer token are rejected. The endpoint catalogue is documented in the Account API tab in the navigation.

​
5. Refresh the access token

Access tokens are short-lived. When one expires, exchange your refresh token for a new pair without prompting the user again:
The response contains a new access_token and (typically) a new refresh_token. Persist both and use the new pair going forward.

​
6. Revoke a refresh token

When the user signs out, or when you want to invalidate a session, revoke the refresh token:
After revocation, the refresh token can no longer be used to obtain new access tokens. Existing access tokens remain valid until they expire on their own.

​
End-to-end example