canonical: https://jentic.com/apis/clerk.com/clerk-backend

# Clerk Backend API

Jentic publishes the only available OpenAPI specification for Clerk Backend API, keeping it validated and agent-ready. Provides server-side user and session management with 109 endpoints covering user creation, organization administration, session verification, email and phone number management, and template customization. Built for modern web applications with API-versioned releases identified by date (e.g., 2021-02-05) and bearer token authentication.

## For AI agents

Manage users, organizations, sessions, and invitations from backend servers. Verify sessions, create user accounts, and administer multi-tenant organizations with role-based memberships.

## Scope

Does not handle frontend login UI components, client-side session management, or Clerk.js widget rendering - use for backend server-side operations only.

## Capabilities

- Verify active sessions and issue session tokens for specific JWT templates
- Create and manage user accounts with email addresses, phone numbers, and metadata
- Administer organizations with role-based membership invitations and domain restrictions
- Configure email and SMS notification templates with custom variables
- Manage OAuth application connections and SAML enterprise SSO configurations
- Issue sign-in tokens for custom authentication flows and actor impersonation
- Control instance-level settings including allowed origins and auth restrictions

## Use cases

### AI Agent User Management

AI agents manage Clerk user accounts through Jentic by searching for operations like user creation or session verification. The agent loads the schema (email_address, password, first_name, last_name), executes POST /users, and receives the created user object with session configuration. Backend user administration completes in under a minute without manual API exploration.

Example prompt: Create a new user via POST /users with email_address and password, then verify the user's email by calling POST /email_addresses with the user_id and verified flag

### Session Verification and Token Issuance

Verify active user sessions from backend servers and issue custom JWT tokens for specific templates. The /sessions/{session_id}/verify endpoint validates session tokens, and /sessions/{session_id}/tokens/{template_name} issues JWTs with custom claims defined in the Clerk dashboard. Essential for protecting backend routes and API endpoints.

Example prompt: Verify a session via POST /sessions/{session_id}/verify with the session token, then issue a custom JWT using POST /sessions/{session_id}/tokens/{template_name}

### Multi-Tenant Organization Administration

Create organizations, invite members with specific roles, and manage domain-based auto-enrollment. The /organizations endpoint creates org instances, /organization_invitations sends role-based invites, and /organization_memberships tracks active members. Supports hierarchical roles and custom permissions per organization.

Example prompt: Create an organization via POST /organizations with name and slug, then invite a member via POST /organizations/{org_id}/invitations with email_address and role

### Enterprise SSO Configuration

Configure SAML connections for enterprise single sign-on directly from the backend. The /saml_connections endpoint creates and manages SAML identity provider configurations including metadata URLs, attribute mappings, and domain restrictions. Enables B2B applications to onboard enterprise customers with their existing identity providers.

Example prompt: Create a SAML connection via POST /saml_connections with name, domain, and idp_metadata_url, then verify the connection status

### Email and SMS Template Management

Customize authentication-related email and SMS templates including verification codes, password resets, and invitation messages. The /templates/{template_type}/{slug} endpoints enable reading, updating, previewing, and reverting templates. Supports variable interpolation for dynamic content personalization.

Example prompt: Retrieve the current email verification template via GET /templates/email/verification_code, update it via PUT /templates/email/verification_code with custom HTML body, then preview via POST /templates/email/verification_code/preview

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | /users | Create a new user account |
| GET | /users | List all users with filtering and pagination |
| POST | /sessions/{session_id}/verify | Verify a session token is valid |
| POST | /sessions/{session_id}/tokens/{template_name} | Issue a custom JWT for a session |
| GET | /organizations | List all organizations |
| POST | /organizations | Create a new organization |
| POST | /invitations | Create an invitation to the instance |
| POST | /sessions/{session_id}/revoke | Revoke an active session |

## Key resources

- **Users** — Create, list, update, and delete user accounts with profile data and authentication methods
- **Sessions** — Verify, revoke, and issue tokens for active authentication sessions
- **Organizations** — Multi-tenant organization lifecycle with memberships and invitations
- **Email Addresses** — Add, verify, and manage email addresses linked to user accounts
- **Templates** — Customize email and SMS templates for authentication notifications
- **SAML Connections** — Enterprise SSO configuration with SAML identity providers

## Why Jentic

- **Setup:** Wiring the Clerk Backend API by hand means attaching its bearer secret key to every call against api.clerk.com/v1 across its user, session, and organization operations. Through Jentic you install once, import the Clerk Backend API from the API Directory, store the key once, and your agent calls it.
- **Permission scoping:** Clerk puts the session id in the URL path (/sessions/{session_id}/verify), so a rule can pin your agent to one session: it can verify or mint tokens for that session and nothing else. You choose the operations it may call, so session revocation or user creation is not included unless you add it.
- **Credential handling:** Your Clerk secret key is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'create a user' or 'verify a session in Clerk', and Jentic returns the matching operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **Auth0 Authentication API** — Protocol-focused authentication with OAuth 2.0, SAML, and passwordless flows
- **FusionAuth API** — Self-hosted identity platform with full lifecycle management and no per-user costs
- **Stytch API** — API-first auth with passwordless focus and fraud detection built in
- **Okta Admin Management API** — Enterprise directory and policy management for complex organizational structures

## FAQ

### Why is there no official OpenAPI spec for Clerk Backend API?

Clerk does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call Clerk Backend API via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer.

### What authentication does the Clerk Backend API use?

The Clerk Backend API uses bearer token authentication. You pass your Clerk secret key (sk_live_... or sk_test_...) as a Bearer token in the Authorization header. Through Jentic, the secret key is stored in your Jentic One instance and agents receive properly formatted Authorization: Bearer headers without handling raw keys.

### Can I verify user sessions with the Clerk Backend API?

Yes. POST /sessions/{session_id}/verify accepts the session token and returns the session object with status, user ID, and expiration. For custom JWTs, POST /sessions/{session_id}/tokens/{template_name} issues a token with claims defined in your JWT template. Through Jentic, search for 'verify clerk session' to load the schema and execute.

### What are the rate limits for the Clerk Backend API?

Clerk enforces rate limits based on your plan tier. The free plan allows 100 monthly active users and standard API rate limits. Pro and Enterprise plans have higher limits. Rate-limited responses return HTTP 429 with Retry-After headers. Most read endpoints allow higher request volumes than write operations.

### How do I create an organization and invite members through the Clerk Backend API via Jentic?

Search Jentic for 'create clerk organization' to find POST /organizations. The schema requires a name and optional slug. After creation, search for 'invite organization member' to find POST /organizations/{org_id}/invitations, which accepts email_address and role. The invited user receives an email and joins the organization upon acceptance.

### Does the Clerk Backend API support SAML enterprise SSO?

Yes. POST /saml_connections creates a SAML configuration with the identity provider's metadata URL, domain restriction, and attribute mappings. GET /saml_connections/{saml_connection_id} retrieves the connection status and SP metadata. This enables enterprise customers to authenticate with their corporate identity providers through your Clerk-powered application.

### Can I manage email and phone verification with the Clerk Backend API?

Yes. POST /email_addresses creates an email for a user with an optional verified flag. PATCH /email_addresses/{email_address_id} updates verification status. POST /phone_numbers works the same way for phone verification. Both resources link to the user record and can trigger verification flows when not pre-verified.

### Can I limit what my agent is allowed to do with the Clerk Backend API?

Yes. Jentic One is self-hosted by you, so your own rules decide which Clerk operations and credentials the agent may use. Because Clerk puts the session id in the URL path, such as POST /sessions/{session_id}/verify, you can pin the agent to a single session and let it only verify that session or mint tokens for it. You pick the exact operations it may call, so session revocation, user creation, or organization changes stay off limits unless you explicitly add them.
