Bearer authentication
Authorization: Bearer <GATEWAY_API_KEY>Both public API endpoints require this header. The key identifies a workspace and grants access to its allowed models. A signed-in browser session does not replace a bearer key for /v1/*.
Environment-specific keys
| Prefix | Environment | Data |
|---|---|---|
gw_sandbox_ | Any (sandbox) | Simulated model only; free; nothing reaches a provider |
gw_test_ | Local demo | Synthetic only; simulated usage |
gw_stage_ | Private staging | Synthetic only; real provider calls can cost money |
gw_live_ | Approved live deployment | Subject to activated account and route policy |
A key from one environment is rejected in another. Prefixes help identify keys; they are not authorization by themselves. The server verifies the stored hash and active status.
Create the narrowest useful key
- Allow only the models your service needs.
- Set a monthly spending limit. The current allowed range is $0.01–$10,000 per key.
- Use separate keys for services and environments.
- The current workspace limit is 20 active keys. Production keys allow 30 requests per minute; sandbox keys 10.
New keys are synthetic-only unless the account and every selected route meet healthcare requirements. A customer cannot activate PHI by changing a request field.
Rotate and revoke
- Create a replacement key with the same necessary permissions.
- Update your server’s secret store and validate one synthetic request.
- Revoke the old key in the dashboard.
- Check failures and usage for unexpected callers.
The key is shown once and persisted as a hash. Revoked or paused keys cannot authenticate. There is no supported public key-management API in this release; use the dashboard.
Protect credentials
Keep Gateway keys server-side and remove authorization headers from your logs. Never include a key in a prompt, patient record, support screenshot, analytics event, or browser URL. Your customers do not need access to Accountable’s upstream provider credentials.
Dashboard sign-in
The dashboard uses a dedicated sign-in screen powered by Clerk, and the server verifies every session. The sign-in methods offered depend on the deployment’s Clerk configuration. Use a staff work account; never enter patient information into authentication fields.
Gateway verifies native Clerk sessions on the server without an extra OAuth consent screen. Clerk components run only on the sign-in page, with telemetry disabled; no Clerk SDK runs on the dashboard or playground, and API-key inference does not contact Clerk. Browser sessions are capped at 24 hours and the underlying Clerk session expiry, with active-session checks and logout revocation. Signing in does not accept a BAA or enable healthcare model routes.
Dashboard session security
There is no inactivity lock on the dashboard. Leaving a tab idle does not sign you out or clear your work. The normal absolute session lifetime and the underlying identity-provider expiry still apply, and you can sign out at any time.
When you sign out or your session actually expires, the page clears session content and asks you to sign in again. Application API keys remain independent of dashboard sessions; use API keys to revoke a compromised key.