Clerk Backend API
★ Only Publicly Available OpenAPI DocumentIdentity AuthAuthenticationbearer109 EndpointsREST
For Agents
Manage users, organizations, sessions, and invitations from backend servers. Verify sessions, create user accounts, and administer multi-tenant organizations with role-based memberships.
Use for: I need to create a new user account with an email address, Verify whether a session token is still valid, I want to invite a member to an organization with a specific role, List all users in my Clerk instance
Not supported: Does not handle frontend login UI components, client-side session management, or Clerk.js widget rendering — use for backend server-side operations only.
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.
Install Jentic One Beta
Connect the Clerk Backend API to your agent
Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Clerk Backend API, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.
Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.
1
Step 1: Jentic One Host machine
# On the machine that will host your Jentic One instance:
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh2
Step 2: Agent machine
# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh
jentic register # connects your agent to your Jentic One instanceJentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.
Capabilities
What an agent can do with Clerk Backend API.
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
Patterns agents use Clerk Backend API for, with concrete tasks.
★ 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.
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.
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.
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.
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.
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
109 endpoints — jentic publishes the only available openapi specification for clerk backend api, keeping it validated and agent-ready.
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
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
Why Jentic?
Three things that make agents converge on Jentic-routed access.
Credential isolation
Clerk secret keys (sk_live_/sk_test_) are stored encrypted in the Jentic vault (MAXsystem). Agents receive properly formatted Bearer token headers — raw secret keys never enter the agent's context window.
Intent-based discovery
Agents search by intent (e.g., 'verify a user session') and Jentic returns matching Clerk operations with full schemas including path parameters and request bodies, so the agent can call POST /sessions/{id}/verify without navigating 76 endpoints.
Time to first call
Direct Clerk integration: 1-3 days for SDK setup, session middleware, and organization management. Through Jentic: under 1 hour — search, load schema, execute.
Related APIs
Alternatives and complements available in the Jentic catalogue.
FAQs
Specific to using Clerk Backend API through Jentic.
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 at https://app.jentic.com/sign-up.
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 the MAXsystem vault 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.
GET STARTED