API reference
The Qeet ID REST API — 142 paths over JSON/HTTPS, with ApiKey and Bearer-JWT auth schemes, a stable error envelope, and cursor pagination.
The Qeet ID REST API is JSON over HTTPS, versioned under /v1/. The OpenAPI spec
covers 142 paths with 100% route coverage, guarded in CI — it's the source of
truth for every SDK.
https://api.qeetid.com (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.qeetid.com; 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.qeetid.com/v1/users \
-H "Authorization: ApiKey $QEETID_API_KEY"curl https://api.qeetid.com/v1/auth/me \
-H "Authorization: Bearer $ACCESS_TOKEN"Endpoint groups
Users
Tenants
Roles & checks
/check.Sessions
Errors
Pagination
The protocol-level groups (OIDC/OAuth, SAML, SCIM, MFA, webhooks, audit, secrets, GDPR) are documented 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.