Developer documentation
Authentication and API keys
Store, rotate, and revoke personal or organization keys without exposing credentials to a browser.
- Audience
- Developers and organization administrators
- Before you start
- Access to the developer portal and a server-side secret store
Send the key
Every v1 operation, including the free catalog, requires exactly one bearer key. Current keys begin with otmw_live_.
Authorization: Bearer otmw_live_...Send requests over HTTPS. Do not place the key in a query parameter or log it in full.
Personal and organization ownership
| Context | Who manages it | Budget used |
|---|---|---|
| Personal | The account developer | Personal credits |
| Organization | An administrator or developer role | The organization’s shared credits or quota |
Select the correct context before creating a key. An organization educator cannot create or revoke keys. An organization developer can manage API access without holding a worksheet-app seat.
Storage and scope
- Store the secret in your platform’s secret manager or a server environment variable. The service stores only a hash and cannot reveal the value again.
- Keys do not have granular scopes: an active key can call every public v1 operation and uses its owner’s budget. Use separate keys per environment or integration so they can be revoked independently.
- There is no browser-direct integration contract or public CORS guarantee. The browser should call your backend; your backend calls this API.
- Never send student names, emails, or other personal data: the API fields do not require them.
Rotate without downtime
- Create a new key with a label that identifies the system or environment.
- Update the secret in your backend and deploy the change.
- Test the new key with GET /catalog; the check is free.
- Revoke the previous key in the portal and confirm it is no longer active.