Skip to main content
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.
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

​
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. A 200 means the key is valid, and the response lists the organization and granted scopes:
The organization context is resolved automatically from the key. You never need to send an org ID header.
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

​
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 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.
  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.