Everything an AI agent can do with the Clerk API.

A reference guide for building AI agents: every method, how to authenticate, and the permissions each one needs.

Endpoints35
API version2026-05-12
Last updated23 June 2026
Orientation

How the Clerk Backend API works.

The Clerk API is how an app or AI agent manages an application's accounts from a server: listing and creating users, banning or deleting one, building organizations and their memberships, and revoking live sessions. Access is granted through a single secret key tied to one instance, and that key is instance-level with no per-endpoint scopes, so it reaches every user, organization, and session in the instance. Clerk dates each API version and a request pins one explicitly, and a state change can be pushed to a webhook so an integration learns about activity without polling.

35Endpoints
11Capability groups
12Read
23Write
0Permissions
Authentication
The Clerk Backend API authenticates with a single secret key, sent as a Bearer token. The key is tied to one instance, either development (sk_test_) or production (sk_live_), and objects never cross instances. The key must stay server-side; the publishable key used in client code cannot call the Backend API.
Permissions
A Clerk secret key is instance-level and has no granular per-endpoint scopes. One key can call every Backend API method and reach every user, organization, and session in the instance. There is no way to issue a narrower key, so the access boundary is the instance itself, which is why a gateway in front of the key matters for limiting what an agent can do.
Versioning
Clerk dates each API version, like 2026-05-12, and a request pins one with the Clerk-API-Version header (or the __clerk_api_version query parameter, but not both). Without a pin, a request uses the version associated with the key or the instance default. New dated versions are released only for changes that are not backward-compatible.
Data model
Clerk is resource-oriented: JSON requests and responses over predictable /v1/ paths. The core objects are users, organizations and their memberships, sessions, and clients (a device's view of sessions). A state change can be pushed as a Svix-signed webhook event, and errors come back as an errors array with a machine-readable code, a message, and a long_message.
Connect & authenticate

Connection & authentication methods.

How an app or AI agent connects to Clerk determines what it can reach. There is the Backend API for managing users and organizations from a server, a webhook stream for receiving account events, and an official server that exposes Clerk's docs to coding agents, and each is governed by the key or secret behind it.

Ways to connect

Backend API

The Backend API takes JSON request bodies, returns JSON, and pages through lists with limit and offset query parameters, at https://api.clerk.com/v1. Every request authenticates with the instance secret key (sk_test_... or sk_live_...) as a Bearer token. The key is instance-wide: it can call every endpoint, so there are no per-endpoint scopes to narrow it.

Best forConnecting an app or AI agent to Clerk from a server.
Governed byThe secret key, which carries full instance access.
Docs ↗

Webhooks (Svix)

Clerk delivers events through Svix, POSTing a signed JSON payload to a registered HTTPS endpoint when something changes, like user.created or organization.updated. The receiver verifies the Svix signature headers (svix-id, svix-timestamp, svix-signature) against the endpoint's signing secret to confirm the message came from Clerk. Svix retries failed deliveries on a schedule.

Best forReceiving Clerk events at an app or AI agent.
Governed byThe Svix signing secret on the endpoint.
Docs ↗

MCP server (docs)

Clerk publishes an official remote Model Context Protocol server at https://mcp.clerk.com/mcp that gives AI coding assistants up-to-date Clerk SDK snippets and implementation guidance. It is a documentation and code-pattern server, not a tool layer over the Backend API, so it does not read or change live users, organizations, or sessions. Launched in public beta in January 2026.

Best forHelping an AI coding assistant write correct Clerk integration code.
Governed byOpen docs access; it exposes no instance data.
Docs ↗
Authentication

Secret key

A secret key authenticates every Backend API call, sent as a Bearer token. It is instance-level: a single key can call every endpoint and reach every user, organization, and session in the instance, with no granular per-endpoint scopes. Each key belongs to one instance, either development (sk_test_...) or production (sk_live_...), and must never appear in client code. A leaked key reaches everything, so rotate it if exposed.

TokenBearer secret key (sk_test_... / sk_live_...)
Best forServer-side calls that manage users, organizations, and sessions.
Docs ↗
Capability map

What an AI agent can do in Clerk.

The Clerk Backend API is split into areas an agent can act on, like users, organizations and their memberships, sessions, and invitations. Each area has its own methods, and a write here can ban a person, delete an account, or revoke a live session.

Users

8 endpoints

Methods for listing, reading, creating, updating, and removing user accounts.

A write here can create, change, ban, lock, or permanently delete a person's account.
View endpoints

Organizations

5 endpoints

Methods for working with organizations: the tenant or team objects users belong to.

A write here can create, change, or delete an organization and everything tied to it.
View endpoints

Organization Memberships

4 endpoints

Methods for adding, listing, changing, and removing who belongs to an organization.

A write here can add a member, change their role, or remove them from an organization.
View endpoints

Invitations

3 endpoints

Methods for inviting people to sign up to the application by email.

A write here sends a real email and creates a path for someone to join.
View endpoints

Organization Invitations

1 endpoint

Methods for inviting people into a specific organization.

A write here sends a real email inviting someone into an organization.
View endpoints

Sessions

4 endpoints

Methods for listing, reading, revoking, and verifying authenticated sessions.

A write here can revoke a live session and sign a person out.
View endpoints

Allow-list / Block-list

2 endpoints

Methods for controlling who can sign up or sign in, by email address or phone number.

A write here changes who is allowed, or blocked, from accessing the application.
View endpoints

Sign-in & Actor Tokens

2 endpoints

Methods for minting one-time tokens that sign a user in or impersonate one.

A write here mints a token that can sign someone in without their password.
View endpoints

Email & SMS Templates

2 endpoints

Methods for reading and editing the email and SMS messages Clerk sends.

A write here changes the wording of messages sent to every user.
View endpoints

JWT Templates

2 endpoints

Methods for managing the JWT templates that shape session tokens for other services.

A write here changes the claims encoded into tokens other systems trust.
View endpoints

Clients

2 endpoints

Methods for listing, reading, and verifying client objects, a device's view of sessions.

A read here exposes the sessions and sign-in state tied to a device.
View endpoints
Endpoint reference

Every Clerk Backend API method.

Filter by method, access, or permission, or search any path. Select a row for version detail, rate limits, the related webhook event, and the source.

MethodEndpointWhat it doesAccessPermissionVersion

Users

Methods for listing, reading, creating, updating, and removing user accounts.8

Read-only. The secret key grants instance-wide access; Clerk has no per-endpoint scopes.

Acts onuser
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Read-only.

Acts onuser
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

A core write that provisions a real account; fires user.created.

Acts onuser
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventuser.created
Rate limitStandard limits apply

As of 2026-05-12, metadata fields moved to the dedicated metadata endpoint; fires user.updated.

Acts onuser
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventuser.updated
Rate limitStandard limits apply

Irreversible; removes the account and fires user.deleted.

Acts onuser
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventuser.deleted
Rate limitStandard limits apply

Blocks the user from signing in until unbanned.

Acts onuser
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventuser.updated
Rate limitStandard limits apply

A lock can be lifted with the unlock method.

Acts onuser
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventuser.updated
Rate limitStandard limits apply

Limited to 10 requests per 10 seconds per user.

Acts onuser
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventuser.updated
Rate limit10 requests / 10s per user

Organizations

Methods for working with organizations: the tenant or team objects users belong to.5

Read-only.

Acts onorganization
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Read-only.

Acts onorganization
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Fires organization.created and an organizationMembership.created for the creator.

Acts onorganization
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventorganization.created
Rate limitStandard limits apply

As of 2026-05-12, metadata fields moved to the metadata endpoint; fires organization.updated.

Acts onorganization
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventorganization.updated
Rate limitStandard limits apply

Irreversible; removes the organization and its memberships, and fires organization.deleted.

Acts onorganization
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventorganization.deleted
Rate limitStandard limits apply

Organization Memberships

Methods for adding, listing, changing, and removing who belongs to an organization.4

Fires organizationMembership.created.

Acts onorganization_membership
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventorganizationMembership.created
Rate limitStandard limits apply

Read-only.

Acts onorganization_membership
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Fires organizationMembership.updated.

Acts onorganization_membership
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventorganizationMembership.updated
Rate limitStandard limits apply

Fires organizationMembership.deleted.

Acts onorganization_membership
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventorganizationMembership.deleted
Rate limitStandard limits apply

Invitations

Methods for inviting people to sign up to the application by email.3

Sends an email. Limited to 100 invitations per hour.

Acts oninvitation
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventNone
Rate limit100 / hour

Read-only.

Acts oninvitation
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Only works on pending invitations.

Acts oninvitation
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Organization Invitations

Methods for inviting people into a specific organization.1

Sends an email. Limited to 250 per hour; fires organizationInvitation.created.

Acts onorganization_invitation
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventorganizationInvitation.created
Rate limit250 / hour

Sessions

Methods for listing, reading, revoking, and verifying authenticated sessions.4

Read-only.

Acts onsession
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Read-only.

Acts onsession
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Ends a live session and fires session.revoked.

Acts onsession
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventsession.revoked
Rate limitStandard limits apply

Returns a JWT that authenticates the session against other services.

Acts onsession_token
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Allow-list / Block-list

Methods for controlling who can sign up or sign in, by email address or phone number.2

Controls who is permitted to sign up or sign in.

Acts onallowlist_identifier
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Blocks the identifier from signing up or signing in.

Acts onblocklist_identifier
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Sign-in & Actor Tokens

Methods for minting one-time tokens that sign a user in or impersonate one.2

The token grants sign-in for the named user; treat it like a credential.

Acts onsign_in_token
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Enables impersonation; the actor signs in as the target user.

Acts onactor_token
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Email & SMS Templates

Methods for reading and editing the email and SMS messages Clerk sends.2

Read-only. template_type is email or sms.

Acts ontemplate
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Changes the wording sent to every user for that message.

Acts ontemplate
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

JWT Templates

Methods for managing the JWT templates that shape session tokens for other services.2

Read-only.

Acts onjwt_template
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Defines claims that downstream services read and trust.

Acts onjwt_template
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Clients

Methods for listing, reading, and verifying client objects, a device's view of sessions.2

Read-only.

Acts onclient
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

A verification check; reads state without changing it.

Acts onclient
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply
No endpoints match those filters.
Webhooks

Webhook events.

Clerk can notify an app when something happens in an instance, like a user being created or an organization being updated. Delivery runs on Svix, which signs each message and retries failed deliveries, so an integration learns about activity without polling.

EventWhat it signalsTriggered by
user.createdA new user account was created in the instance./users
user.updatedA user's details changed, including a ban, lock, or metadata update./users/{user_id}
/users/{user_id}/ban
/users/{user_id}/lock
/users/{user_id}/metadata
user.deletedA user account was permanently deleted./users/{user_id}
organization.createdA new organization was created./organizations
organization.updatedAn organization's details changed./organizations/{organization_id}
organization.deletedAn organization was deleted, along with its memberships./organizations/{organization_id}
organizationMembership.createdA user was added as a member of an organization./organizations/{organization_id}/memberships
/organizations
organizationMembership.updatedA member's role within an organization changed./organizations/{organization_id}/memberships/{user_id}
organizationMembership.deletedA member was removed from an organization./organizations/{organization_id}/memberships/{user_id}
organizationInvitation.createdAn invitation into an organization was created and sent./organizations/{organization_id}/invitations
session.revokedA session was revoked, signing the person out of that session./sessions/{session_id}/revoke
No events match that search.
Rate limits & pagination

Rate limits, pagination & request size.

Clerk limits how fast an app can call the Backend API, counted against the secret key making the request, with tighter caps on a few endpoints that send email or write metadata.

Request rate

Clerk meters Backend API requests against the secret key making the call, not by a per-method cost. A production instance allows 1000 requests per 10 seconds across the instance, and a development instance allows 100 per 10 seconds. A few endpoints carry their own tighter limits: sending invitations is capped at 100 per hour (25 per hour in bulk), organization invitations at 250 per hour (50 in bulk), and merging a user's or organization's metadata at 10 requests per 10 seconds for that object. Going over returns HTTP 429 with a Retry-After header giving the seconds until the block clears.

Pagination

List endpoints page with limit and offset query parameters. limit sets the page size, defaulting to 10 and capped at 500, and offset sets how many records to skip. Many list responses include a total_count alongside the page of data, so a client can page through the full set.

Request size

A list endpoint returns at most 500 records per page, the maximum value of limit. Some filter parameters accept up to 100 values, for example listing users by up to 100 email addresses at once.

Errors

Status codes & error handling.

The status codes an agent should handle, and what to do about each.

StatusCodeMeaningWhat to do
401authentication_invalidThe request was not authenticated, for example a missing, malformed, or wrong secret key (could_not_authenticate_request).Send a valid secret key for the right instance as a Bearer token, and rotate the key if it may be compromised.
403authorization_invalidThe request was authenticated but not permitted for this action or resource.Confirm the instance and the resource match the key, and that the action is allowed for it.
404resource_not_foundThe requested object does not exist in this instance, or the path is wrong.Verify the ID and that it belongs to the same instance as the key.
422form_param_value_invalidThe request body failed validation, for example a missing or invalid parameter (form_param_missing, form_param_value_invalid). This status covers most request errors.Read the long_message and the meta.param_name field, fix the parameter, and resend.
429too_many_requestsThe rate limit for the secret key, or for a specific endpoint, was exceeded.Back off using the Retry-After header, then retry. Smooth the request rate.
Versioning & freshness

Version history.

Clerk dates each API version and a request pins one with a header, so an integration moves to a new version deliberately rather than being changed underneath it.

Version history

What changed, and when

Latest version2026-05-12
2026-05-12Current version
Current version

Clerk identifies each API version by its release date and a request pins one with the Clerk-API-Version header. A new dated version is cut only for changes that are not backward-compatible.

What changed
  • Removes metadata fields from the user and organization update endpoints; metadata is now set through the dedicated metadata endpoints.
2025-11-10Requires migration
November 2025

A dated version bringing more consistency to the Clerk Billing API endpoints.

What changed
  • Reworks Billing API endpoint behavior for more consistency and clarity.
2025-04-10Requires migration
April 2025

A dated version introducing session token version 2.

What changed
  • Adds support for session token version 2.
2024-10-01Requires migration
October 2024

A dated version changing the SAML sign-in response.

What changed
  • SAML sign-in responses return needs_first_factor instead of needs_identifier.
2021-02-05Feature update
Initial version

The first Clerk API version. Every later change up to the next dated version is backward-compatible with it.

What changed
  • Baseline Clerk API version.

Pin a dated version with the Clerk-API-Version header and move up when ready.

Clerk API versions ↗
Questions

Clerk Backend API, answered.

How does authentication work, and which key do I use?+
The Backend API uses the instance secret key, sent as a Bearer token in the Authorization header. A development instance key starts with sk_test_ and a production one with sk_live_. The publishable key (pk_) used in front-end code cannot call the Backend API. The secret key must never be exposed in client code, and should be rotated if it leaks.
Can I limit a secret key to only some endpoints or resources?+
No. A Clerk secret key is instance-level and grants full access to every Backend API endpoint and every user, organization, and session in that instance. Clerk does not offer granular per-endpoint scopes on the key. To restrict what a particular app or agent can do, the access has to be limited in front of the key, by a gateway that decides which calls to allow.
How does API versioning work?+
Each version is identified by its release date, like 2026-05-12. A request pins a version with the Clerk-API-Version header, or the __clerk_api_version query parameter, but not both at once. Without a pin, the request uses the version tied to the key or the instance default. Clerk releases a new dated version only for changes that are not backward-compatible.
What do error responses look like?+
Clerk returns errors as a JSON object with an errors array and a clerk_trace_id for support. Each entry has a machine-readable code (like form_param_value_invalid or resource_not_found), a short message, and a long_message with detail, plus an optional meta object naming the parameter at fault. Most request errors come back as HTTP 422.
How do I receive Clerk webhooks, and how are they secured?+
Clerk sends webhooks through Svix. Register an HTTPS endpoint, then verify each incoming message with the svix-id, svix-timestamp, and svix-signature headers against the endpoint's signing secret before trusting it. Svix retries failed deliveries. Events include user.created, user.updated, user.deleted, organization.updated, and organizationMembership.created, among others.
What are the rate limits?+
Backend API requests are counted against the secret key. A production instance allows 1000 requests per 10 seconds and a development instance 100 per 10 seconds. Some endpoints are tighter: invitations at 100 per hour, organization invitations at 250 per hour, and metadata merges at 10 per 10 seconds per object. A 429 response carries a Retry-After header with the seconds to wait.
Does Clerk have an official MCP server?+
Yes, but it is a documentation server, not a tool layer over the Backend API. The remote server at mcp.clerk.com gives AI coding assistants up-to-date Clerk SDK snippets and implementation patterns, and launched in public beta in January 2026. It does not read or change live users, organizations, or sessions, so managing real Clerk data still goes through the Backend API.
Related

More security API guides for agents

What is Bollard AI?

Control what every AI agent can do in Clerk.

Bollard AI sits between a team's AI agents and Clerk. Grant each agent exactly the access it needs, read or write, resource by resource, and every call is checked and logged.

  • Set read, write, or full access per agent, never a shared Clerk secret key.
  • Denied by default, so an agent reaches only what has been explicitly allowed.
  • Every call recorded in plain English: who, what, where, and the decision.
Clerk
Support Agent
View users ResourceOffReadFull use
Ban or delete a user ActionOffReadFull use
Organizations ResourceOffReadFull use
Send an invitation ActionOffReadFull use
Per-agent access, set in Bollard AI, not in Clerk