> ## Documentation Index > Fetch the complete documentation index at: https://docs.whitebit.com/llms.txt > Use this file to discover all available pages before exploring further. # Check OAuth API key existence > The endpoint returns whether a partner-issued API key already exists for the authenticated user and OAuth2 client pair. The endpoint is Bearer-authenticated, so it is reachable only once the partner holds a token for that user: a returning partner calls it before redirecting the user again, while a first-time authorization reaches it only after the authorization code has been exchanged. When a key already exists, skip the redirect and surface the appropriate message to the user. The endpoint reports absence through the payload, never through an error status. A key that was deleted, a key belonging to a different OAuth2 client, and a manually created key are all reported as `exists: false` with an empty `permissions` list. The only failure status is `401`, which covers every problem with the token itself. **Required scope:** `apikeys.read`. **Region availability:** The endpoint is available on the global server (`https://whitebit.com`) only. ## Authentication OAuth 2.0 Bearer token. Required scope: `apikeys.read`. The endpoint cannot be reached before the partner holds a token for the user, so a first-time integration calls it only after the authorization code has been exchanged. See [Authentication](/api-reference/authentication). The endpoint is available on `https://whitebit.com` only. ## Cache No caching. ## Notes Use the decision matrix below to interpret the `(exists, isEnabled)` response and choose the next action. | `exists` | `isEnabled` | Meaning | Recommended action | | - | - | - | - | | `false` | `false` | No partner-issued API key is visible for this `(user, OAuth2 client)` pair — never created, deleted, owned by another client, or created manually. | Start the OAuth API key flow. | | `true` | `true` | An active partner-issued API key already exists. | Skip the OAuth API key flow. Surface "an active API key for this partner already exists" to the user. | | `true` | `false` | A disabled partner-issued API key exists (post-inactivity, awaiting user-side deletion). | Skip the OAuth API key flow. Ask the user to delete the disabled key from the WhiteBIT dashboard, then retry. | * For a returning user whose token is still valid, call the endpoint before redirecting again — an existing key is reused rather than recreated, and a second creation attempt is rejected. See [Returning users](/guides/fast-api-key-integration#returning-users). For a first-time user no token exists yet, so the endpoint is reachable only after the authorization code has been exchanged. * Disabled keys are not deletable through the OAuth2 partner endpoint. Disabled keys are removed by the user from the WhiteBIT dashboard. * See [Retrieve OAuth API key secret](/api-reference/oauth/usage/api-key-secret) for the secret-fetch step and [Delete OAuth API key](/api-reference/oauth/usage/api-key-delete) for partner-initiated revocation. * The `permissions` array lists the permission groups the user granted on the consent screen — see [Key permissions](/guides/fast-api-key-integration#key-permissions) for the full permission model. When the user granted no permissions at all, the key is still created and the array comes back empty; the user deletes that key and re-runs the flow to grant a usable set. ## Used in these guides * [Copy Trading](/guides/copy-trading) — mirror a lead trader's orders into followers' own accounts via OAuth-issued keys. * [Fast API Key integration](/guides/fast-api-key-integration) — OAuth-issued API keys created on behalf of end users. ## OpenAPI ````yaml openapi/oauth2.yaml GET /oauth2/api-key/info openapi: 3.0.3 info: title: OAuth 2.0 API Reference description: WhiteBIT OAuth 2.0 API for authentication and account management version: 1.0.0 servers: - url: https://whitebit.com description: WhiteBIT Global Server - url: https://whitebit.eu description: WhiteBIT EU Server security: [] tags: - name: Authentication description: > OAuth 2.0 authentication endpoints for obtaining and refreshing access tokens. Available Scopes (requested during client setup): - general: General API access - show.userinfo: Access to basic user information - users.read: Read user data - users.email.read: Read user email information - users.kyc.read: Information about whether a user has passed KYC verification - orders.read: Read trading orders - orders.create: Create trading orders - orders.delete: Delete trading orders - balances.read: Read account balances - markets.read: Read market information - deals.read: Read trading deals - orders_history.read: Read order history - users.transactions.read: Read user transactions - users.converts.read: Read currency conversion history - users.balances.read: Read user account balances - users.orders.read: Read user orders - users.deals.read: Read user deals - apikeys.create: Issue an OAuth-bound API key during the consent flow - apikeys.read: Read OAuth-issued API key state and retrieve its secret once - apikeys.delete: Delete an OAuth-issued API key linked to the partner - name: Account Endpoints description: >- Endpoints for retrieving account information, balances, and transaction history - name: OAuth API Keys description: > Partner-facing endpoints for managing API keys created via the OAuth API key flow. Available on the global server (`https://whitebit.com`) only. The EU server (`https://whitebit.eu`) does not expose these endpoints in this release. Required scopes: - `apikeys.read` for `GET /oauth2/api-key/info` and `GET /oauth2/api-key/{externalId}/secret` - `apikeys.delete` for `DELETE /oauth2/api-key/{externalId}` A third scope, `apikeys.create`, authorizes key creation on the WhiteBIT consent screen and is not consumed by any endpoint here. Holding at least one of the three admits an OAuth2 client to the flow. paths: /oauth2/api-key/info: get: tags: - OAuth API Keys summary: Check OAuth API key existence description: > The endpoint returns whether a partner-issued API key already exists for the authenticated user and OAuth2 client pair. The endpoint is Bearer-authenticated, so it is reachable only once the partner holds a token for that user: a returning partner calls it before redirecting the user again, while a first-time authorization reaches it only after the authorization code has been exchanged. When a key already exists, skip the redirect and surface the appropriate message to the user. The endpoint reports absence through the payload, never through an error status. A key that was deleted, a key belonging to a different OAuth2 client, and a manually created key are all reported as `exists: false` with an empty `permissions` list. The only failure status is `401`, which covers every problem with the token itself. **Required scope:** `apikeys.read`. **Region availability:** The endpoint is available on the global server (`https://whitebit.com`) only. responses: '200': description: Successful response content: application/json: schema: type: object properties: data: type: object properties: exists: type: boolean description: >- A partner-issued API key exists for the authenticated user and OAuth2 client pair. `false` covers every absence case — no key was ever created, the key was deleted by the user or by the system, the key belongs to a different OAuth2 client, or the key was created manually rather than through OAuth. example: true isEnabled: type: boolean description: >- The existing key is active. `false` when no key exists or when a key exists but is disabled (post-inactivity, awaiting user deletion from the dashboard). example: true externalId: type: string format: uuid nullable: true description: >- External UUID of the existing key. `null` when `exists` is `false`. example: 550e8400-e29b-41d4-a716-446655440000 permissions: type: array description: >- Permission groups assigned to the key. Empty array when `exists` is `false`, and also when the user granted zero permissions during the OAuth handshake — the key is still created in that case, and the user deletes it and re-runs the flow to grant a usable set. For a disabled key (`isEnabled` is `false`), the array still reflects the permissions the user granted at creation time, so the partner can show the original scope. items: type: object properties: name: type: string description: >- Locale-independent identifier of the permission group. Use the value for partner-side logic. example: trading title: type: string description: >- Translated label of the permission group. The value depends on the authenticated user's locale — display only, never branch on the value. example: Trading urls: type: array description: >- Endpoint permissions inside the group. `enable` set to `true` means the user granted the action during the OAuth handshake; `enable` set to `false` means the action was offered but not granted. items: type: object properties: url: type: string description: Endpoint path the permission controls. example: /v2/order enable: type: boolean description: >- The user granted the action during the OAuth handshake. example: true '401': description: >- Missing, invalid, or expired Bearer token. A token that does not carry the `apikeys.read` scope returns the same status — an insufficient scope is not reported separately. content: application/json: schema: type: object properties: data: type: object properties: message: type: array items: type: string example: - Unauthorized. security: - BearerAuth: [] servers: - url: https://whitebit.com description: WhiteBIT Global Server components: securitySchemes: BearerAuth: type: http scheme: bearer bearerFormat: JWT description: > OAuth 2.0 Bearer Token authentication. Include the access token in the Authorization header. Example: `Authorization: Bearer YOUR_ACCESS_TOKEN` ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.