Authentication
Every request carries an API key in the Authorization header, with the Bearer scheme:
Authorization: Bearer dbk_live_<credential id>_<secret>
- A live key starts with
dbk_live_, then a 20-character credential id (lower-case letters and the digits 2 to 7), an underscore and a 43-character secret. The credential id is not secret: it identifies the key in your audit trail. The secret is. - Keys that start with
dbk_test_belong to the test environment. - Keys created before the API existed (
eng_live_...from the old console page) do not work with this API.
Only in the header
Send the key only in the Authorization header. A key found in the URL is refused with 400
credential_in_url, and you must treat that key as exposed: revoke it and create a new one. A body
that contains something that looks like a key is refused with 400 credential_in_body.
When a key is refused
| Status | Code | Meaning |
|---|---|---|
| 401 | invalid_api_key |
Missing, malformed, unknown, expired or revoked key. |
| 403 | api_access_disabled |
API access is off for the account, or the API client is disabled. |
| 403 | ip_not_allowed |
The request came from an address that is not allowed. |
| 403 | insufficient_scope |
The API client lacks the scope the operation needs. |
| 403 | tier_not_enabled |
A Tier-2 operation that is not switched on for the account. |
Every key problem gets the same answer, invalid_api_key, so the answer never tells anyone whether
a key exists, has expired or was revoked. Check the key's state in the console.
IP allow-lists
An account can have an IP allow-list, and each API client can have its own list. When both are set, both apply: the request must come from an address on each of them.
When changes take effect
A revoked key, a disabled API client, a changed IP list or a switch turned off takes effect within 15 seconds.
Server-side only
The API is for server-to-server use. It sends no CORS headers, so a browser page cannot call it, and a key must never ship in a browser, mobile or desktop app. See Security.