Skip to main content
The REST API accepts a personal access token as a Bearer credential on every request. The MCP server and the REST API also share one OAuth 2.0 authorization server, mounted at {origin}/oauth, for clients that act on behalf of a user.

​
Personal access tokens

For scripts, backend services, and anything else calling the REST API directly, use a personal access token (PAT):
Create one from the dashboard: User Settings → API Keys. A token is shown exactly once at creation time — store it in a secret manager or environment variable, never in source control. Personal access tokens are available on plans that include the REST API; revoke a token from the same screen at any time, which takes effect immediately.

​
OAuth 2.0 (third-party apps)

Use the authorization-code + PKCE flow for clients that act on behalf of a user.

​
Discovery

Clients discover the authorization server via standard metadata documents: The MCP endpoint returns 401 with a WWW-Authenticate header, so spec-compliant MCP clients bootstrap the OAuth flow automatically.

​
Flow

  1. GET /oauth/authorize with response_type=code, client_id, redirect_uri, code_challenge, code_challenge_method=S256, and state.
  2. The user authenticates and approves; iZap redirects back with code.
  3. POST /oauth/token with grant_type=authorization_code, code, redirect_uri, and code_verifier → returns an access_token (JWT) and a refresh_token.
Public clients may self-register via POST /oauth/register. Refresh an expired token with grant_type=refresh_token.

​
Token notes

  • Every token — personal access token or OAuth access token — is a secret. Read it from an environment variable or secret manager, never hardcode it.
  • A personal access token does not expire on its own; it is valid until you revoke it from the dashboard.
  • OAuth access tokens expire. Use the refresh grant when a request returns 401.