Machine-to-machine

OAuth client_credentials for service principals — token-endpoint auth, scopes, and lifecycle.

For service-to-service calls with no user present, use the OAuth client_credentials grant against a service principal. The service principal authenticates at the token endpoint and receives an access token it presents to your APIs.

Two machine-identity models

For simple backend access to the Qeet ID API, an API key (Authorization: ApiKey qk_…) is usually enough. Use client_credentials when a machine client needs a standard OAuth access token (e.g. to call your own OAuth-protected resource servers).

Create a service principal

POST/v1/service-principalsCreate an M2M service principal

DELETE/v1/service-principals/{id}Disable a service principal

GET/v1/tenants/{tenantID}/service-principalsList service principals

Get a token

POST/v1/oauth/tokenclient_credentials token

Clients authenticate with client_id/client_secret as form params or HTTP Basic.

Bash

curl -X POST https://api.qeetid.com/v1/oauth/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d grant_type=client_credentials \
  -d client_id=$CLIENT_ID \
  -d client_secret=$CLIENT_SECRET \
  -d scope="reports:read"

OAuthTokenResponse

JSON

{
  "access_token": "eyJhbGciOiJFUzI1Ni…",
  "token_type": "Bearer",
  "expires_in": 3600,
  "scope": "reports:read"
}

The access token is an ES256 JWT — your resource servers verify it against the JWKS exactly like a user token. Revocation and introspection use the same client authentication — see Tokens.

Create a service principal

Get a token

On this page