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_SANDBOX cost nothing extra and stop the two from being swapped in a config file later. If you’re ever unsure which one you’re holding, compare it against the masked value in the API Keys table for each organization. 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 test against a sandbox instead of production, use a key issued from your sandbox organization: the request looks identical, same host and all, since a key authenticates against the organization it was issued from rather than against a separate host. 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.