> ## Documentation Index
> Fetch the complete documentation index at: https://www.bitnob.dev/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Bitnob API requests authenticate with an `X-Auth-Client` API key header against https://api.bitnob.com.
> Always use the sandbox environment for testing. Never put live API keys in sample code.
> Money amounts are integers in the smallest unit of the currency (satoshis for BTC, cents for fiat). Never use floats.
> Every state-changing request takes a client-supplied `reference` and must be treated as idempotent on retry.
> Quotes expire. Re-quote rather than reusing a stale quote id.

# Bitnob Enterprise API authentication

> How Bitnob Enterprise API keys are issued, scoped to a permission set, and used to authenticate requests.

> [!NOTE]
>
> This page covers the **Bitnob Enterprise API**, the non-custodial product. The custodial Bitnob Business API used for payouts, cards, and trading signs requests with HMAC instead. See [Business API authentication](https://www.bitnob.dev/api-reference/authentication/authentication.md).

Every request to the Bitnob Enterprise API is authenticated with an API key. Keys are issued from the Bitnob dashboard and carry a permission set that is bound to your organization at issue time.

## Base URL

```
https://api.platform.bitnob.com
```

## Send your API key

Pass your key on the `X-API-Key` header with every request. To confirm a key works, call [Get API Key Info](https://www.bitnob.dev/api-reference/platform/meta/get-api-key-info.md). A 200 means the key is valid, and the response lists the organization and granted scopes:

```http theme={null}
POST /wallets HTTP/1.1
X-API-Key: <your_api_key>
Content-Type: application/json
Idempotency-Key: <unique_key>
```

The organization context is resolved automatically from the key. You never need to send an org ID header.

> [!WARNING]
>
> Keep keys server-side. Never expose a Bitnob Enterprise API key in a mobile app, frontend JavaScript bundle, or public repository. A leaked key grants the same authority a signed-in admin user does, up to the limits of its permission set and configured policies. Make every API call from your backend.

## Required headers

| Header | Required | Description |
| - | - | - |
| `X-API-Key` | Yes | Your API key. Organization is derived from the key automatically. |
| `API-Version` | No | Pins the API version, for example `v1`. Leave it out to use the current default. See [Versioning](https://www.bitnob.dev/docs/platform/making-requests.md#versioning). |
| `Content-Type` | For writes | Must be `application/json` for all POST, PUT, and PATCH requests. |
| `Idempotency-Key` | For writes | Send it on `POST`, `PATCH`, and `DELETE` requests. Some endpoints require it. See [Idempotency](https://www.bitnob.dev/docs/platform/making-requests.md#idempotency). |

## How authorization works

API key calls never receive a WebAuthn or MFA challenge. When the key has the required permission and your enforced policy allows the request, the Bitnob Secure Enclave signs synchronously.

The authorization flow for every transaction is:

1. **API key is verified.** The key must exist, be active, and carry the permission required for the requested operation: inspect scopes on [Get API Key Info](https://www.bitnob.dev/api-reference/platform/meta/get-api-key-info.md) to check.
2. **The policy is evaluated.** Your organization's enforced policy is checked against the transaction. Its rules run in order, and the first rule that matches decides the outcome. See [How policy evaluation works](https://www.bitnob.dev/docs/platform/policies/how-policy-evaluation-works.md).
3. **Enclave signs, holds, or blocks.** If the policy allows the transaction, the Enclave signs immediately. A `require_approval` rule holds it in `pending_authorization` until approvers approve, a `delay` rule holds it in `delayed` until its time lock expires, and a `block` rule rejects it.
4. **Transaction is broadcast.** After signing, the transaction is broadcast to the network. If gas sponsorship is needed, the gas station tops up the wallet first.

A leaked key cannot exfiltrate funds beyond what its policies permit. Spending limits, destination allowlists, time locks, and approvals all enforce constraints independently of the key's permission set.

## Next

Versioning, idempotency, pagination, errors, and rate limits are covered in [Making requests](https://www.bitnob.dev/docs/platform/making-requests.md).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.