Authentication
API keys for sandbox and production accounts, and keeping keys safe.
Every request carries a secret key as a bearer token.
curl https://api.daybookhealthcare.com/v1/remits \
-H "Authorization: Bearer $DAYBOOK_API_KEY"Sandbox and production
| Key prefix | Account | Opens |
|---|---|---|
sk_test_ | Sandbox | That sandbox account only. A production account refuses it |
sk_live_ | Production | That production account only. A sandbox refuses it |
A sandbox account and a production account are separate accounts, each with its own keys, webhook endpoints and data. Anyone can open a sandbox account; a production account is set up with our team (book a demo).
Isolation follows from that: a key sees only its own account's objects, and an id from another account answers 404, never a hint that it exists. Create one key per system that calls Daybook, so a queue, a dashboard and a CI job can each be revoked alone.
Sandbox and payer calls
A sandbox is a real Daybook workspace with every capability of a production one. Nothing is switched off there, so what you try in the sandbox is what your production workspace will do. Three things differ: its keys are sk_test_, its webhook events carry mode: test, and its clearinghouse traffic goes to Stedi's test environment when Daybook has given it a Stedi test key, which is how Daybook sets sandboxes up. A Stedi account you connect yourself is a production account and reaches real payers from a sandbox too; ask your Daybook contact which your sandbox uses.
Creating and revoking keys
Keys are created and revoked from Developers → API keys in the Daybook app, by the account owner or anyone who manages its integrations. A key is shown once, when it is created; Daybook keeps only a hash of it. An account holds up to 10 active keys.
Keeping keys safe
Secret keys act on your behalf with payers. Use them only on your server.
- Store keys in your secrets manager, not in code or config files.
- Create one key per system so you can revoke one without touching the rest.
- To replace a key, create a new key, deploy it, then revoke the old one. A revoked key stops working at once.
Errors
A missing or wrong key returns 401 with authentication_failed. A key without access to an object returns 404, so ids from other accounts can't be probed. A route a key may not use at all, returns 403. See Idempotency and errors.