@clerk/backend

@clerk/backend is Clerk’s server-side SDK for JavaScript and TypeScript runtimes, exposing a fully typed REST client for the Clerk Backend API alongside low-level utilities for verifying session tokens, handling webhooks, and authorizing requests. It underpins nearly every framework-specific Clerk package (Next.js, Express, Fastify, Remix, Hono, and more), so it ships the request-authentication primitives and resource clients that the rest of the Clerk JavaScript ecosystem builds on top of.

The package targets any V8-isolate or Node.js runtime, offering both edge- and Node-specific crypto implementations so the same authentication logic works in serverless middleware, edge functions, and traditional servers alike. Typed API classes cover users, organizations, sessions, sign-in tokens, webhooks, machine-to-machine tokens, and billing, giving backend code a single consistent client for everything the Clerk dashboard manages.

What You Get

• A fully typed REST client covering Users, Organizations, Sessions, Webhooks, Machine-to-Machine tokens, Billing, and other Clerk Backend API resources
• authenticateRequest/token verification utilities for validating Clerk session JWTs without a round trip to the API
• Dual runtime crypto implementations (Node and edge/browser) selected automatically via package exports conditions
• Webhook verification helpers built on standardwebhooks for validating Clerk webhook payloads
• The shared foundation consumed by every framework-specific Clerk SDK (Next.js, Express, Fastify, Remix, Hono, Astro, Nuxt)

Common Use Cases

• Verifying incoming request session tokens in custom middleware for a framework Clerk doesn’t ship a dedicated SDK for
• Calling the Clerk Backend API directly to manage users, organizations, or sessions from server-side code or scripts
• Validating and processing Clerk webhook events (user created, session ended, etc.) in a backend handler
• Building a custom framework integration on top of Clerk’s authentication primitives

Under The Hood

Architecture - @clerk/backend sits at packages/backend inside the clerk/javascript monorepo and is organized around two pillars: a generated REST client under src/api/endpoints/ (one class per resource such as UserApi, SessionApi, OAuthApplicationsApi, BillingApi, M2MTokenApi) built on a shared AbstractApi/factory.ts request pipeline, and a tokens/ module implementing local JWT verification so requests can be authenticated without calling the API. webhooks.ts and createRedirect.ts provide supporting helpers, and index.ts re-exports the public surface consumed by every framework SDK in the monorepo.

Tech Stack - Written in TypeScript, built with tsup, and dependent on @clerk/shared (cross-package utilities), standardwebhooks (webhook signature verification), and tslib. Package exports use conditional imports (#crypto) to select a Node-specific crypto implementation versus a browser/edge-light one, letting the same published package run correctly on Node.js, Cloudflare Workers, and other V8-isolate runtimes without a separate build.

Code Quality - Tests live under src/__tests__/ (webhooks, exports, createRedirect, proxy) using Vitest-style specs, with msw for mocking HTTP calls to the Backend API in tests; the surface area is large (dozens of endpoint classes) but each follows the same AbstractApi pattern, keeping naming and request/response shapes consistent across resources.

API Design - The client groups methods by resource (e.g. clerkClient.users.getUser(), clerkClient.sessions.verifySession()), mirroring the Backend API’s REST structure, which keeps the API predictable once a developer learns the pattern for one resource. Getting started requires an API secret key and, for most apps, pulling in a framework-specific package (e.g. @clerk/nextjs) rather than calling @clerk/backend directly — a small amount of indirection that pays off in consistent framework ergonomics.