Docs · API
Authentication
Authenticate user API requests with an invite-issued bearer key, and understand worker credentials.
On this page
Every public user endpoint requires an API key in the Authorization header.
Keys are issued through the invite process. There is no public signup, login,
or self-service key-creation endpoint.
Bearer authentication
curl https://<your-domain>/v1/models \
-H "Authorization: Bearer $EASYAI_API_KEY"The header format is Authorization: Bearer <key>. The server accepts the
scheme case-insensitively but requires the key itself.
A missing, invalid, revoked, or expired key returns 401:
{ "error": { "code": "UNAUTHORIZED" } }The same response is used when the key belongs to a user who is not active. Keys are hashed at rest by the control plane, and a revoked key cannot be reactivated by the client.
Worker credentials are separate
Worker-control and worker-execution routes under /v1/worker/* do not accept
user API keys. A worker enrolls with a one-time invite token, then uses a
short-lived session token plus a refresh token for later starts. Keep the two
credential types separate:
- User key: for
/v1/chat/completions,/v1/models, and/v1/jobs/:id. - Worker session: for heartbeat, capability reports, assignment polling, and token submission.
The invite email carries the enrollment token; the desktop app discards it after enrollment and stores a rotating device session instead.
Rate limiting
The current gateway enforces a fixed window of 60 requests per minute per API
key. Successful responses include X-RateLimit-Remaining. A request over the
limit returns 429 with the usual error shape:
{ "error": { "code": "RATE_LIMITED" } }Wait for the next window before retrying. The limiter is process-local in the current deployment.