API Reference
Authentication
API keys and Bearer token authentication.
Overview
Authenticate every API request with a Bearer token in the Authorization header. API keys are created in Admin Center → Developer → API keys and inherit the permissions of the creating user's role unless scoped further.
Rotate keys on a defined schedule (quarterly recommended for production) and immediately revoke any key suspected of exposure. Use separate keys per environment and per integration.
Step-by-step procedure
Create an API key
Admin Center → Developer → API keys → Create key.
Name the key by purpose (e.g., "GitHub Actions staging").
Copy the key once, it may not be shown again.
Store securely
Save as a CI secret or vault entry, never commit to git.
Restrict access to pipeline and service principals that need it.
Send with requests
Include header: Authorization: Bearer YOUR_API_KEY.
Use Content-Type: application/json for POST/PATCH bodies.
Best practices
- Use least-privilege service accounts for automation
- Monitor Admin audit log for key creation and revocation
- Never embed keys in browser or mobile client code
Example request
curl -s https://api.zof.ai/v1/projects \ -H "Authorization: Bearer $ZOF_API_KEY" \ -H "Content-Type: application/json"
Separate identity, scope, and credential lifecycle
Successful authentication establishes who is making a request; it does not establish permission for every resource or operation. Use a test identity to verify the intended access boundary and a separate denied operation to check that excess access is not granted.
Record the owner, intended use, scope, expiry where applicable, and revocation procedure for each automation credential. Keep credentials out of URLs, logs, screenshots, and committed configuration. When rotating, confirm the new credential works before retiring the old one, subject to your security policy.
Was this page helpful?