Authentication
API keys, sandbox and live environments, and keeping keys safe.
Every request is authenticated with an API key sent in a header. Keys are never accepted in the URL, so they cannot leak into server logs, proxies or browser history.
Authorization: Bearer sk_live_...X-API-Key: sk_live_... is accepted as an alternative for clients that cannot set Authorization.
Sandbox and live keys
| Prefix | Environment | Charged | Use it for |
|---|---|---|---|
sk_test_ | Sandbox | No | Development and CI: real calculations, up to 500 calls a day |
sk_live_ | Live | Yes | Production traffic |
A key works only in its own environment.
Managing keys
- Shown once. We store only a fingerprint, never the key itself. If you lose a key, rotate it.
- Named. Give each integration its own key, so revoking one never breaks another. Every key can call every capability.
- In a project. Every key belongs to a project of your organization. Its calls count toward that project's usage and, if the project has one, its monthly credit budget (
429 project_budget_exceededwhen it is used up). Keys belong to projects, not people: a key keeps working when the teammate who created it leaves the team, unless it is revoked. - Rotation. Create the new key, deploy it, then revoke the old one. Both work during the changeover.
- Last used. The dashboard shows when each key was last used.
- Revocation takes effect immediately.
- Who can manage keys. In a team, owners, admins and developers can create keys; developers can revoke the keys they created, owners and admins any key. Billing members and viewers cannot see or create keys. See Teams and projects.
Keep keys on your server
Call the API from your backend. A key inside a mobile app, a single-page app or a WordPress theme can be extracted by anyone. If you need astrology data in a browser or app, have it call your server, and have your server call us.