Store the key outside your code
Put the key in an environment variable or your secret manager as soon as you receive it:DUALENTRY_API_KEY_PROD and DUALENTRY_API_KEY_DEV cost nothing extra and stop the two from being swapped in a config file later. The key’s own prefix records which environment issued it, so if you are ever unsure which one you are holding, compare it against the masked value in the API Keys table. See Authentication for the format.
Send it in the X-API-KEY header
Every request takes the key in theX-API-KEY header. Confirm the credential works with a single read before you build anything on top of it:
- cURL
- Python
- JavaScript
200 and a JSON body means you are authenticated. The same key works against /public/v2/ for the current API version. /public/ with no version segment is the deprecated legacy mount and should not be used for new work.
To run against development instead, swap the host for https://api-dev.dualentry.com and use a key issued from your sandbox organization in that environment. A production key does not authenticate there, because each environment holds its own organizations and keys. Keep the two keys in separately named variables so a revocation on one side never takes down the other.
If it does not authenticate
Authentication failures return403, not 401, and a missing header and a bad key are not distinguished by status code. Read the error message to tell them apart.
API key authentication failed means the header did not arrive, arrived empty, or carried a key that is unknown or revoked:
Authorization instead. If the header is definitely arriving, ask your Admin to confirm the key’s status reads Active in the API Keys table. If it reads Revoked, you need a new key.
Access denied means the opposite: the key authenticated, but its roles do not cover the operation.
