API conventions
How the Qeet ID REST API works across every endpoint — base URL, ApiKey and Bearer-JWT auth schemes, the error envelope, and cursor pagination.
The Qeet ID REST API is JSON over HTTPS, versioned under /v1/. This page covers the
conventions that apply to every endpoint; for the endpoints themselves, see the
interactive API reference at apis.qeet.in — the full OpenAPI
surface in Swagger UI, with request/response schemas and a "Try it out" console (switchable
across local / staging / production).
https://api.id.qeet.in (or your self-hosted base URL)Self-hosted base URL
Qeet ID is self-hostable, so the base URL is whatever you deploy. Examples use
https://api.id.qeet.in; substitute your own host. The OpenAPI
servers list also includes local dev (:4000/
:4001).
Authentication schemes
There are several auth modes — use the right one per route:
| Scheme | Header | Used by |
|---|---|---|
apiKeyAuth | Authorization: ApiKey qk_… | Server-side API access. |
bearerAuth | Authorization: Bearer <jwt> | User / service ES256 JWTs. |
scimBearer | Authorization: Bearer <scim-token> | Per-tenant SCIM provisioning. |
clientCredentials | form client_id/client_secret or HTTP Basic | OAuth M2M token/revoke/introspect. |
ssoCookie | qe_ls cookie (HttpOnly) | Hosted-login SSO session flows. |
ApiKey ≠ Bearer
The API-key scheme is literally Authorization: ApiKey <key>
— not
Bearer. The Bearer scheme on the same authenticated
routes is for user/service JWTs. Don't send a qk_… key as a
Bearer token.
curl https://api.id.qeet.in/v1/users \
-H "Authorization: ApiKey $QEETID_API_KEY"curl https://api.id.qeet.in/v1/auth/me \
-H "Authorization: Bearer $ACCESS_TOKEN"Endpoints
Every endpoint lives in the Qeet API portal at apis.qeet.in — the full OpenAPI surface in Swagger UI, grouped by bounded context, with request/response schemas and a "Try it out" console (local / staging / production selectable per request).
Open the API portal
All endpoints, schemas, and a Try-it-out console at apis.qeet.in.
Errors
The error envelope and codes.
Pagination
Cursor-based list pagination.
The protocol-level groups (OIDC/OAuth, SAML, SCIM, MFA, webhooks, audit, secrets, GDPR) are also documented as guides in their product sections — OIDC, Enterprise, MFA, and Platform.
Conventions
- Tokens are ES256 JWTs verified against
/.well-known/jwks.json. - Errors use a stable
{ "error": { "code", "message", … } }envelope — see Errors. - Lists are cursor-paginated (
items+next_cursor) — see Pagination. - Request IDs are returned in the
X-Request-Idheader and echoed in error bodies.