# Clerk Changelog (full content) > Full content of every Clerk changelog entry, concatenated for LLM/agent consumption. ## Other formats - [Changelog index](https://clerk.com/changelog/llms.txt): Index of every Clerk changelog entry - [Changelog (detailed)](https://clerk.com/changelog/llms-index.txt): Index of all Clerk changelog entries with metadata and table of contents ## Companion files - [All sections index](https://clerk.com/llms-full.txt): Top-level index linking to every llms-full.txt file - [Documentation](https://clerk.com/docs/llms-full.txt): Full Clerk documentation in one file - [Articles](https://clerk.com/articles/llms-full.txt): Full content of all Clerk articles - [Blog](https://clerk.com/blog/llms-full.txt): Full content of all Clerk blog posts - [Glossary](https://clerk.com/glossary/llms-full.txt): Full content of all Clerk glossary entries - [Dashboard index](https://dashboard.clerk.com/llms.txt): Index of the Clerk Dashboard for LLMs and agents --- ## OAuth Device Authorization Grant - URL: https://clerk.com/changelog/2026-09-08-device-authorization-grant.md - Date: 2026-09-08 OAuth 2.0 Device Authorization Grant is currently available in beta. To try it, [contact support](https://clerk.com/contact/support) to enable it for your workspace. The grant provides a standards-based flow for applications that cannot open a browser or easily accept text input. CLIs, TVs, game consoles, and other devices can ask a user to approve access from a browser-capable device without entering their credentials on the original device. ## What's new - **Device authorization and token polling.** Clients request a device code, display a short user code and verification URL, then poll for tokens at the interval Clerk provides. - **Public and confidential clients.** Public clients send only their Client ID, while confidential clients authenticate with their Client ID and Client Secret. - **Hosted user verification.** Clerk's Account Portal displays the OAuth application, requested scopes, Organization selection when applicable, and equally visible approve and deny actions. - **Automatic discovery.** Clerk advertises `device_authorization_endpoint` and `urn:ietf:params:oauth:grant-type:device_code` through OAuth 2.0 and OpenID Connect metadata when Device Authorization Grant is available and the verification page is reachable. Device Authorization Grant follows [RFC 8628](https://www.rfc-editor.org/rfc/rfc8628) and supports the same Clerk OAuth scopes, tokens, consent context, and Organization claims as the Authorization Code Flow. It does not use Proof Key for Code Exchange (PKCE) or redirect URIs. See [Use OAuth Device Authorization Grant](/docs/guides/configure/auth-strategies/oauth/device-authorization-grant) to configure an OAuth application, implement device and token requests, and handle polling responses. --- ## Customize the reverification window - URL: https://clerk.com/changelog/2026-08-28-customize-reverification-window.md - Date: 2026-08-28 You can now customize how long a successful sign-in or reverification remains valid for Clerk-protected sensitive actions. Set the reverification window between 1 and 10 minutes. The default remains 10 minutes. A shorter window can prompt users to verify their credentials more often before actions such as changing a password, adding and removing an email address, revoking a session, or deleting an account. To configure the window, open the [**Sessions**](https://dashboard.clerk.com/~/sessions) page in the Clerk Dashboard. Under **Session lifetime**, set **Reverification window** to the number of minutes you want, between 1 and 10. This setting applies to [sensitive actions protected by Clerk](/docs/guides/secure/reverification#sensitive-actions-that-require-reverification). For sensitive actions unique to your application, define the required window in your application. See the [reverification guide](/docs/guides/secure/reverification) for details. --- ## Audit Dashboard activity with Admin Logs - URL: https://clerk.com/changelog/2026-08-25-admin-logs.md - Date: 2026-08-25 The Clerk Dashboard now has [**Admin Logs**](https://dashboard.clerk.com/~/admin-logs): an audit trail of the configuration changes made across your workspace — from the Dashboard, the Backend API, or the Platform API. Admin Logs track actions like creating OAuth applications, updating instance settings, rotating secrets, and managing Roles and Permissions, [and more](/docs/guides/dashboard/logs/admin-logs). ## Filtering and search The logs page shows a reverse-chronological feed of events. Each entry lists a description of what happened (e.g., "Brandon Romano created a user"), the application it happened in (when applicable), the originating IP address with a country flag (when available), and the timestamp. Select any entry to see its full details. You can narrow the feed with filters: - **Event type** — Filter by event type (e.g., `oauth_application.updated`, `domain.created`). Supports trailing wildcards (e.g., `oauth_application.*`). - **Instance** — Filter by the instance the action targeted. - **Application** — Filter by the application the action targeted. - **Actor** — Filter by the actor that triggered the event. - **IP address** — Filter by the IP address the action originated from. - **Time range** — Scope results to a specific time window. ## Get started Admin Logs are available on the Business and Enterprise plans — see the [pricing page](/pricing) for details. They start recording on August 24, 2026; actions before that date aren't included. Open [**Admin Logs**](https://dashboard.clerk.com/~/admin-logs) in the Clerk Dashboard, or read the [docs](/docs/guides/dashboard/logs/admin-logs). ### Going forward Admin Logs join [Application Logs](/changelog/2026-05-06-application-logs) and [Email Logs](/changelog/2026-06-01-email-logs-public-beta) in Clerk's ongoing observability work. --- ## Custom OAuth scopes - URL: https://clerk.com/changelog/2026-08-21-custom-oauth-scopes.md - Date: 2026-08-21 Clerk now gives you finer control over the access that MCP clients can request from your API. Define custom OAuth scopes in the Clerk Dashboard to match the actions and resources your API supports. For example: - `messages:read` - `tools:execute` - `resources/files:read` - `mcp_all` Assign only the scopes that each OAuth application needs. Separately, choose which scopes to advertise through Clerk's OAuth metadata so MCP clients can discover what your application supports. Open the **Scopes** tab on the [**OAuth applications**](https://dashboard.clerk.com/~/oauth-applications) page to get started. To enforce scopes in your API, verify each OAuth access token and check its granted scopes. See [Verify OAuth tokens with Clerk](/docs/guides/configure/auth-strategies/oauth/verify-oauth-tokens). --- ## Biometric sign-in for Expo, iOS, and Android - URL: https://clerk.com/changelog/2026-08-17-biometric-sign-in-mobile-sdks.md - Date: 2026-08-17 Clerk's mobile SDKs can now enroll a signed-in user's current device as a biometric credential, then let returning users sign in with Face ID, Touch ID, or Android biometrics. Clerk verifies a device-bound challenge while the private key stays on the device. Prebuilt auth and user profile views can show the enrollment prompt, biometric sign-in button, and current-device toggle. Custom flows can use the biometric credential APIs directly. ## Expo ```tsx import { useBiometricCredentials } from '@clerk/expo' const { enroll } = useBiometricCredentials() await enroll() ``` ```tsx import { useBiometricCredentials } from '@clerk/expo' const { signIn } = useBiometricCredentials() await signIn() ``` ```tsx import { useBiometricCredentials } from '@clerk/expo' const { revoke } = useBiometricCredentials() await revoke(biometricCredentialId) ``` ## iOS ```swift try await Clerk.shared.biometricCredentials.enroll() ``` ```swift try await Clerk.shared.auth.signInWithBiometrics() ``` ```swift try await Clerk.shared.biometricCredentials.revoke(id: biometricCredentialId) ``` ## Android ```kotlin scope.launch { Clerk.biometricCredentials.enroll() } ``` ```kotlin scope.launch { Clerk.auth.signInWithBiometrics() } ``` ```kotlin scope.launch { Clerk.biometricCredentials.revoke(biometricCredentialId) } ``` See the biometric sign-in docs for setup and reference material: - [iOS guide](/docs/ios/guides/development/custom-flows/authentication/biometric-sign-in) - [Android guide](/docs/android/guides/development/custom-flows/authentication/biometric-sign-in) - [Expo guide](/docs/expo/guides/development/custom-flows/authentication/biometric-sign-in) --- ## Discounts and promo codes for Billing - URL: https://clerk.com/changelog/2026-08-10-discounts-and-promo-codes.md - Date: 2026-08-10 Sometimes the list price isn't the right price. Sales closes a deal with a negotiated discount, you want to reward an early adopter, or you're running a launch promotion. Billing now supports discounts — apply them directly to a customer's subscription, or hand out a promo code customers redeem themselves at checkout. ![The Apply discount option on a subscription in the Dashboard](./manual-discounts.png) ## Create a discount once, use it anywhere Discounts are reusable and flexible: - **Percentage or fixed amount** — take 20% off, or $50 off - **Any duration** — a single billing cycle, a set number of cycles, or indefinitely - **Per-period amounts** — different discount amounts for monthly and annual plans ## Apply it yourself, or share a code - **Manual discounts** — apply a discount to any subscriber's active subscription from the Dashboard. Revoke it at any time to return the subscription to its original price at the next renewal. - **Promo codes** — publish a code (like `LAUNCH20`) that customers enter at checkout to redeem the discount themselves. Optionally cap the total number of redemptions, restrict redemption to new subscribers, and track how many times each code has been used. Discounts and promo codes are available now for everyone using Clerk Billing. See the [docs](/docs/guides/billing/discounts) to get started. --- ## Connect OAuth clients with Client ID Metadata Documents - URL: https://clerk.com/changelog/2026-08-06-client-id-metadata-documents.md - Date: 2026-08-06 Clerk's OAuth provider now supports [Client ID Metadata Documents](https://datatracker.ietf.org/doc/draft-ietf-oauth-client-id-metadata-document/) (CIMD), available today as a beta. A compatible client uses an HTTPS URL as its `client_id`. Clerk fetches the metadata document at that URL and validates the client's identity and redirect URIs. This gives MCP and other public OAuth clients a stable identity without a pre-issued client ID, client secret, or Dynamic Client Registration. ## Control which clients can connect The [**OAuth applications**](https://dashboard.clerk.com/~/oauth-applications) page lets you manage CIMD clients from the **Applications** tab and configure client admission on the **Settings** tab: - Explicitly allow a client by its Client ID URL and choose its scopes. - Allow supported popular clients with suggested scopes. - Review each client's admission status and metadata fetch health. - Edit scopes, refresh metadata, or delete a saved client. - Decide whether unknown clients may connect. - Block clients that were implicitly allowed during an earlier connection. On the **Settings** tab, under **Client onboarding**, enable **Publish CIMD support** to publish CIMD in your authorization server metadata. Once you do, any CIMD client can connect and Clerk records it when it first connects so you can review it later. **Client admission** settings let you further customize CIMD client behavior. ## Get started CIMD is currently available in beta. To try it, [contact support](https://clerk.com/contact/support) to enable it for your workspace. Read [Manage OAuth clients with Client ID Metadata Documents](/docs/guides/configure/auth-strategies/oauth/client-id-metadata-documents) to learn how CIMD works and how to configure client admission policies. We'd love to hear your feedback as you try out CIMD. Your input during the beta period will help us refine the feature. Have questions or suggestions? Reach out through [our feedback portal](https://feedback.clerk.com) or join the discussion in our [Discord community](https://clerk.com/discord). --- ## Google Workspace Directory Sync - URL: https://clerk.com/changelog/2026-08-05-google-workspace-directory-sync.md - Date: 2026-08-05 Directory Sync now supports Google Workspace. Clerk connects directly to your Workspace directory and syncs [users](https://clerk.com/docs/guides/configure/auth-strategies/enterprise-connections/directory-sync#view-directory-users), [groups, and group memberships](https://clerk.com/docs/guides/configure/auth-strategies/enterprise-connections/directory-sync#role-mapping). Clerk pulls the directory with a Google service account and computes changes, keeping your user base current without waiting for sign-in events. ## Set up Open a Google SAML connection in the [Clerk Dashboard](https://dashboard.clerk.com/~/user-authentication/sso-connections) and select the **Directory sync** tab. Upload a service account key with domain-wide delegation, along with the Workspace admin it should impersonate. Clerk validates the credentials against your directory before enabling Directory Sync. If you disable it later, Clerk keeps the stored credentials so you can re-enable it with one click. ## Works with role mapping and custom attributes Google groups sync automatically and can be mapped to Clerk Roles. Custom attribute mapping supports the full pulled directory record, including standard fields such as `organizations.title` and Workspace custom schemas such as `customSchemas.EmployeeInfo.costCenter`. Map array paths to a multi-valued attribute to sync all items. See the [Directory Sync docs](https://clerk.com/docs/guides/configure/auth-strategies/enterprise-connections/directory-sync) for the full setup guide. --- ## Sign-in-or-up now works with strict enumeration protection - URL: https://clerk.com/changelog/2026-08-04-sign-in-or-up-strict-enumeration.md - Date: 2026-08-04 At Clerk, we strive to provide an auth solution with the best user experience and the strongest security and privacy protections. Many customers use our all-in-one [``](/docs/reference/components/authentication/sign-in) component to implement sign-in-or-up, a single entry point for their application: A visitor types their email address and Clerk decides whether to sign them in or create an account, so nobody has to remember whether they signed up before. Previously, [Strict user enumeration protection](/docs/guides/secure/user-enumeration-protection#strict-user-enumeration-protection) was incompatible with this flow. Strict enumeration protection hides whether an email address or phone number is already registered with your app, by never showing a "no account found" response when signing in. Until now you had to pick one. We are happy to share that [``](/docs/reference/components/authentication/sign-in) now supports both together out-of-the-box, with no code changes needed. ## Verify first, decide second Under strict protection, a sign-in for an identifier that doesn't exist already continues to the verification screen instead of failing. Only after a visitor has proven their identity do we choose whether to sign them in or sign them up: 1. The visitor enters their email address or phone number. 2. Clerk shows the verification screen and sends a code or email link, whether or not the account exists. 3. The visitor enters the code or follows the link. 4. If the account exists, they're signed in. If it doesn't, Clerk creates it and continues to sign-up. The order is what makes this safe. The visitor proves they control the address before Clerk commits to anything, so someone probing your sign-in page with addresses they don't own learns nothing either way. New and returning users see the same screens in the same number of steps. ## Requirements **Your instance must be in [Open access mode](/docs/guides/secure/restricting-access#open).** **Password can't be the starting strategy.** Either disable **Password** or [set the instance's preferred sign-in strategy to OTP](/docs/reference/backend-api/tag/instance-settings/PATCH/instance). Under strict protection, a password step has no safe exit: - A visitor without an account lands on a password screen they can never get past, and Clerk isn't allowed to explain why. - A visitor who enters the wrong password can't be offered "sign up instead?", because that would answer the question strict protection is hiding. On development instances, `` logs a `sign_up_if_missing_password_preferred` console warning when it detects this combination. Username identifiers aren't supported either, since a username alone gives Clerk no way to contact the person to verify them. ## Get started Enable strict protection on the [**Rules**](https://dashboard.clerk.com/~/protect/rules) page under **Protect** in the Clerk Dashboard. If your app already renders `` as a combined [sign-in-or-up page](/docs/guides/development/custom-sign-in-or-up-page) and is in [**Open** access mode](/docs/guides/secure/restricting-access#open), it keeps working once you switch — there's no new prop and nothing to migrate. If you're building your own interface, or you want this behavior without turning strict protection on, the `signUpIfMissing` option does the same thing in a custom flow. Refer to the [sign-in-or-up custom flow guide](/docs/guides/development/custom-flows/authentication/sign-in-or-up#sign-in-or-up-with-signupifmissing). The [Account Portal](/docs/guides/account-portal/overview) hosts sign-in and sign-up on separate pages, so a sign-in-or-up experience there isn't available under any setting today. General support is on our roadmap. For now, render `` in your own app. --- ## Self-serve SSO for OIDC - URL: https://clerk.com/changelog/2026-07-30-self-serve-sso-oidc.md - Date: 2026-07-31 Your customers can now set up their own OIDC connections. [Self-serve SSO](/changelog/2026-06-26-self-serve-sso) lets you delegate enterprise SSO configuration to your customers' IT admins, without giving them Dashboard access. In addition to SAML, it now supports custom OpenID Connect (OIDC) providers. > \[!NOTE] > Self-serve SSO is only available for applications using [Clerk Organizations](/docs/guides/organizations/overview). ## How it works The **Security** tab in [``](/docs/reference/components/organization/organization-profile) now has an **OpenID Connect (OIDC)** group in the provider picker, alongside SAML. An admin with the `org:sys_entconns:manage` permission selects **OIDC Provider** and sets up the connection end-to-end: - **Domains**: Add one or more domains and verify ownership of each with a DNS `TXT` record. - **Connection**: Create an OIDC application in the identity provider using the authorized redirect URI Clerk displays, then supply the provider's endpoints — a discovery endpoint, or the authorization, token, and user info URLs — along with the client ID and client secret. Clerk reads `sub` and `email` from the ID token, and `given_name` and `family_name` when the provider sends them. - **Test**: Run a test sign-in to confirm the connection works end-to-end. - **Activate**: Turn the connection on once the test passes. The connection is scoped to the Organization it's configured in and behaves like any other enterprise connection once it's live: users with a matching email domain sign in through the configured provider. ## Get started Self-serve SSO is enabled per Organization. In the [Clerk Dashboard](https://dashboard.clerk.com/~/organizations), select an Organization, open its **Settings**, and turn on **Allow this organization to set up enterprise SSO** under **Organization permissions**. The Security tab then surfaces wherever your app renders ``. For setup details and requirements, refer to the [self-serve SSO documentation](/docs/guides/configure/auth-strategies/enterprise-connections/self-serve-sso). --- ## Hosted authentication for Expo, iOS, and Android - URL: https://clerk.com/changelog/2026-07-28-mobile-hosted-auth.md - Date: 2026-07-28 Clerk's mobile SDKs can now hand the entire sign-in and sign-up flow to [Account Portal](/docs/guides/account-portal/overview), Clerk's hosted authentication pages. A single method call opens the browser, the user authenticates on your Account Portal, and the created session is activated back in your app. Because the flow runs through Account Portal, every authentication method enabled on your instance works without building native UI for it: email codes, passwords, social providers, enterprise SSO, and MFA all come along automatically, styled with your Account Portal branding. ## Expo ```tsx import { useHostedAuth } from '@clerk/expo/hosted-auth' const { startHostedAuth } = useHostedAuth() await startHostedAuth() ``` ## iOS ```swift try await clerk.auth.startHostedAuth() ``` ## Android ```kotlin scope.launch { Clerk.auth.startHostedAuth() } ``` Hosted authentication is available in `@clerk/expo` 4.1.0, the Clerk iOS SDK 1.3.5, and the Clerk Android SDK 1.0.37. See the [mobile hosted authentication guide](/docs/guides/account-portal/hosted-auth) to get started. --- ## Composable UserProfile and OrganizationProfile components - URL: https://clerk.com/changelog/2026-07-27-composable-profile-components.md - Date: 2026-07-27 We’re shipping an experimental API that breaks `` and `` into composable building blocks. Instead of mounting the whole component, you can assemble a profile page from the exact panels and sections you want, in the order you want them. The building blocks live in the `@clerk/ui` package, which isn’t included with your Clerk SDK — install it as a direct dependency: ```bash {{ filename: 'terminal' }} npm install @clerk/ui ``` ## Render the built-in panels Wrap the building blocks in a provider and drop in a panel to render the same content Clerk renders today: ```tsx import { UserProfileProvider, UserProfileAccountPanel, UserProfileSecurityPanel, } from '@clerk/ui/experimental' export default function Page() { return ( ) } ``` ## Compose your own sections Pass sections as children to a panel to pick and reorder only the pieces you need: ```tsx import { UserProfileProvider, UserProfileAccountPanel, UserProfileProfileSection, UserProfileEmailSection, UserProfilePhoneSection, } from '@clerk/ui/experimental' export default function Page() { return ( ) } ``` The same pattern applies to organizations with `OrganizationProfileProvider`, its panels (`OrganizationProfileGeneralPanel`, `OrganizationProfileMembersPanel`, and more), and their sections. ## Experimental This API is exported from `@clerk/ui/experimental` and is not covered by semantic versioning. The set of components, their names, and their props may change in any release while we gather feedback. We’d love to hear how you’re using it. --- ## Connect your AI tools to Clerk MCP with one command - URL: https://clerk.com/changelog/2026-07-22-clerk-mcp.md - Date: 2026-07-22 [Clerk's MCP server](/docs/guides/ai/mcp/clerk-mcp-server) gives your AI agents up-to-date Clerk SDK snippets and implementation patterns. Until now, connecting it meant editing a different config file for every client. The latest [Clerk CLI](/cli) release adds a `clerk mcp` command group that handles the whole thing: ```bash {{ prompt: '$' }} clerk mcp install ``` ## Ten clients, one command `clerk mcp install` detects the AI clients on your machine and registers the Clerk MCP server in each one you pick from an interactive list. It supports Claude Code, Cursor, GitHub Copilot (VS Code), Windsurf, Gemini CLI, Codex, opencode, OpenClaw, Warp, and Hermes Agent. Entries are registered user-globally, so the server is available in every project. Where a client ships a usable non-interactive registration command (like `claude mcp add` or `codex mcp add`), Clerk delegates to it so the client keeps owning its config format, and writes config files directly for the rest. Re-running `install` always converges: whatever is already sitting under the entry name is replaced, so there's no conflict state to untangle. ```bash {{ prompt: '$' }} # Skip the prompt: target specific clients, or all of them clerk mcp install --client claude --client cursor clerk mcp install --all ``` `clerk mcp list` shows every Clerk entry the CLI has registered across your clients, and `clerk mcp uninstall` removes them, prompting only with the clients that actually have one. ## A built-in bridge replaces `npx mcp-remote` Instead of pointing each editor at a remote URL through `npx mcp-remote`, every client is configured to launch the same built-in bridge — `clerk mcp run` — expressed in that client's own config format (`{ "command": "clerk", "args": ["mcp", "run"] }` for most). `clerk mcp run` is a stdio↔Streamable-HTTP bridge built into the CLI, so there's no npx dependency, and updating the CLI updates the bridge everywhere at once with no re-install needed. ## `clerk doctor` checks your connection `clerk doctor` now probes your configured Clerk MCP server with a real `initialize` handshake, so you can tell the difference between "not installed", "installed but unreachable", and "working" at a glance. ## Built for agents Like every CLI command, `clerk mcp` respects the agent contract: non-TTY runs never prompt and emit JSON automatically, per-client failures are reported structurally in a `failures` array instead of aborting the run, and every registration-blocking error carries a stable `code` plus a `docsUrl` pointing at the manual setup instructions as a fallback. ## Get started Update to the latest CLI and connect your clients: ```bash {{ prompt: '$' }} clerk update clerk mcp install ``` See the [CLI docs](/docs/cli) for the full command reference, or the [Clerk MCP server docs](/docs/guides/ai/mcp/clerk-mcp-server) for manual per-client setup. --- ## Configurable default OAuth scopes - URL: https://clerk.com/changelog/2026-07-22-oauth-dcr-default-scopes.md - Date: 2026-07-22 You can now configure default OAuth scopes for dynamic client registration using the [**OAuth applications**](https://dashboard.clerk.com/~/oauth-applications) settings in the Clerk Dashboard, or the Backend API. This helps when OAuth clients such as ChatGPT or Claude don't include the `scope` parameter in their [registration request](https://www.rfc-editor.org/rfc/rfc7591.html#section-3.1). A client may then request more scopes than it was dynamically registered with, resulting in an `invalid_scope` error. Setting default scopes helps Clerk users smooth over this commonly reported error when popular clients authenticate with their MCP servers. Configurable default scopes give you some control over the access requested by clients that omit the parameter, which may vary per-client implementation. Clerk doesn't override a scope value that a client provides. See the [OAuth configuration guide](/docs/guides/configure/auth-strategies/oauth/how-clerk-implements-oauth#configure-default-scopes) for setup instructions. --- ## Deprecating CBC cipher suites - URL: https://clerk.com/changelog/2026-07-16-deprecating-cbc-cipher-suites.md - Date: 2026-07-16 Beginning **January 18, 2027**, Clerk will stop supporting [CBC-mode SSL/TLS cipher suites](/glossary/cipher-suite) on Clerk-managed subdomains, including `clerk.example.com` (Frontend API) and `accounts.example.com` (Account Portal). This is a breaking change for clients that can only negotiate a CBC cipher, but most applications will not be affected, since modern clients already negotiate stronger ciphers. The change rolls out as certificates are renewed. Clerk certificates are valid for 90 days, so every affected subdomain will have moved to the new ciphers within a few months. New applications default to the new configuration starting January 18, 2027. CBC-mode ciphers have a long history of practical attacks ([POODLE](https://en.wikipedia.org/wiki/POODLE), [BEAST](https://en.wikipedia.org/wiki/Transport_Layer_Security#BEAST_attack), and [Lucky Thirteen](https://en.wikipedia.org/wiki/Lucky_Thirteen_attack)) and have been deprecated by browsers, operating systems, and the broader security community. Modern connections use [AEAD](https://en.wikipedia.org/wiki/Authenticated_encryption) cipher suites such as AES-GCM and ChaCha20-Poly1305, which avoid the entire class of padding-related attacks. ## Affected cipher suites - `TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA` - `TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA` - `TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256` - `TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384` - `TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA` - `TLS_RSA_WITH_AES_128_CBC_SHA` - `TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA` - `TLS_RSA_WITH_AES_256_CBC_SHA` - `TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256` - `TLS_RSA_WITH_AES_128_CBC_SHA256` - `TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384` After a subdomain rotates, clients that can only negotiate one of these ciphers will fail the TLS handshake with it. Any reasonably modern client (current browsers, mobile operating systems, and server runtimes) already prefers AEAD ciphers and is unaffected. If you need continued CBC support, contact [support@clerk.com](mailto:support@clerk.com). --- ## Choose what SAML sends as a login hint - URL: https://clerk.com/changelog/2026-07-15-saml-login-hint.md - Date: 2026-07-15 You can now control the identifier Clerk sends to your identity provider (IdP) when a member starts a SAML sign-in. Configure the **Login hint** section on each SAML connection in the [Clerk Dashboard](https://dashboard.clerk.com/~/user-authentication/sso-connections): - **Email address** sends the member's email address. This is the default for named SAML providers. - **Custom attribute** sends the value of a custom attribute that you select on the connection. Use this when your IdP identifies members with an employee ID, username, or another value instead of their email address. - **Off** sends no login hint. Custom SAML connections don't send a login hint until you select **Email address** or **Custom attribute**. Existing named SAML connections keep their email-address behavior unless you change the setting. For setup steps and details about custom attributes, see [the SAML login hint documentation](/docs/guides/configure/auth-strategies/enterprise-connections#configure-a-saml-login-hint). --- ## CLI webhooks, impersonation, and a refreshed experience - URL: https://clerk.com/changelog/2026-07-09-clerk-cli-webhooks-and-impersonate.md - Date: 2026-07-09 When we [released the CLI](/changelog/2026-04-22-clerk-cli) and then shipped [`clerk deploy`](/changelog/2026-06-10-clerk-deploy), the goal was a single tool that both developers and agents could use to run Clerk end to end. CLI 2.0 pushes further into day-to-day workflows: testing webhooks and debugging as a specific user, all without leaving your terminal. ## Test webhooks locally with `clerk webhooks` A new command group gives you a self-contained, local webhooks toolkit — no linked project and no Platform API required: - **`clerk webhooks listen`**: opens a relay tunnel and forwards deliveries to your local handler. Pass `--token` to pin a stable, shareable URL you can reuse across restarts. - **`clerk webhooks verify`**: verifies a webhook signature offline (HMAC-SHA256), from a saved delivery or explicit header values — no network calls. - **`clerk webhooks token`**: generates a relay token you can pipe straight into `listen`. ```bash {{ prompt: '$' }} clerk webhooks listen --forward-to http://localhost:3000/api/webhooks ``` ## Debug as any user with `clerk impersonate` `clerk impersonate` (alias `clerk imp`) creates a short-lived sign-in URL that logs you in as another user, so you can reproduce a report from their exact session. Target a user by ID or email, add `--open` to launch the URL straight away, and every impersonation is stamped with your account for auditing. ```bash {{ prompt: '$' }} # Impersonate a user by email and open the sign-in URL clerk imp alice@example.com --open # Revoke a pending token when you're done clerk imp revoke act_29w9... ``` Run `clerk imp` with no arguments to pick a user interactively. ## A refreshed interactive experience Prompts, lists, and spinners have a new visual style, and interactive commands now end by clearly reflecting success, failure, or a paused cancellation — so it's always obvious how a run finished. ## Built for agents Every command in 2.0 respects the CLI's agent contract: stable error codes, `stdout` for data and `stderr` for UI, and no hidden interactive prompts in non-TTY contexts. `clerk webhooks token` prints a bare token to `stdout` so it pipes cleanly, and `clerk impersonate` resolves the target instance explicitly rather than silently defaulting. ## Get started Update to the latest CLI, then try any of the new commands: ```bash {{ prompt: '$' }} clerk webhooks listen --forward-to http://localhost:3000/api/webhooks ``` See the [CLI docs](/docs/cli) for the full command reference. --- ## Disable just-in-time provisioning for SAML connections - URL: https://clerk.com/changelog/2026-07-07-disable-jit-provisioning.md - Date: 2026-07-07 Just-in-time (JIT) provisioning can now be disabled per enterprise connection. By default, Clerk creates a user account the first time someone signs in through a SAML connection. With JIT provisioning disabled, sign-ins only succeed for users who already exist in your instance - anyone else is rejected instead of being auto-created. This is useful when your identity provider handles authentication but a separate system, such as Directory Sync (SCIM) or an internal admin flow, decides who gets an account. ## Disable JIT provisioning Open a SAML connection in the [Clerk Dashboard](https://dashboard.clerk.com/~/user-authentication/sso-connections) and turn off **Create users during sign-in** in the connection's settings. The same control is available on the Backend API as a `disable_jit` field when updating a SAML connection or enterprise connection. When JIT provisioning is disabled, a sign-in attempt by someone without an existing account fails with a `saml_jit_provisioning_disabled` error that includes the attempted email address, so blocked attempts are easy to diagnose. Existing users are unaffected and continue to sign in normally, including the first time they sign in through the SAML connection. ## Compatibility JIT provisioning remains enabled by default, so existing connections keep provisioning users exactly as before. Connections that previously had JIT provisioning disabled through the internal exception are migrated to the new setting automatically — their behavior is unchanged, it's just visible and editable in the Dashboard now. --- ## Clerk Billing now supports account credits - URL: https://clerk.com/changelog/2026-06-30-account-credits.md - Date: 2026-06-30 Starting today, you can add or remove account credits from Users and Organizations directly from the Clerk Dashboard and APIs. Sometimes you want to adjust what a customer owes without changing their subscription. Maybe you're offering a one-time discount, issuing a service credit, or resolving a billing issue. Account credits make these kinds of adjustments simple while keeping subscription pricing unchanged. Credits are stored on a customer's account and automatically applied toward future charges. If the available credit exceeds the amount of the current invoice, the remaining balance stays on the account and is automatically used for future recurring charges. ## Flexible account adjustments Account credits give you a straightforward way to make account-level billing adjustments without creating custom pricing or modifying Plans. For example, you might: - Offer a one-time courtesy credit after a service interruption. - Grant promotional credits to early customers. - Apply a manual discount for a specific customer. (Note: customers can use their credits however they would like to). - Resolve billing issues by crediting part or all of an upcoming invoice. Whenever a customer is billed, Clerk automatically applies any available credit balance before charging their payment method. Any unused credit remains on the account until it's fully consumed. ## Built directly into Clerk Billing Account credits can be managed from the Clerk Dashboard or through the Backend API, giving you the flexibility to automate credit adjustments or handle them manually. Each User or Organization displays its current credit balance, and every adjustment immediately updates the amount available for future billing. Every credit adjustment is recorded in a ledger, giving you a complete history of credits that were added or removed from an account. Whether you're issuing promotional credits automatically through your application or making manual adjustments from the Dashboard, you always have an audit trail of how a customer's balance changed over time. ## Get started with Account credits - Open a User or Organization in the Clerk Dashboard. - Open the **Actions** menu. - Select **Adjust credit balance**. - Enter the amount of credit to add or remove. - Save your changes. The updated balance will automatically be applied to the customer's next eligible charge, with any remaining credit carrying forward to future recurring invoices. --- ## Self-serve SSO - URL: https://clerk.com/changelog/2026-06-26-self-serve-sso.md - Date: 2026-06-26 By default, enterprise SSO connections are configured by your team in the Clerk Dashboard. For every customer that needs SSO, someone on your side creates the connection, exchanges metadata with the customer's IT admin, tests it, and activates it. As your enterprise motion scales, that becomes a bottleneck. Self-serve SSO lets you delegate that configuration to your customers' IT admins, without giving them Dashboard access. > \[!NOTE] > At launch, Self-serve SSO was only available for applications using [Clerk Organizations](/docs/guides/organizations/overview) and only supported SAML providers. > > As of July 31, 2026, Self-serve SSO also supports custom OIDC providers. [Learn more in the OIDC launch announcement](/changelog/2026-07-30-self-serve-sso-oidc). ## How it works When you enable self-serve SSO for an Organization, a **Security** tab appears in that Organization's [``](/docs/reference/components/organization/organization-profile). An admin with the `org:sys_entconns` permission can set up the connection end-to-end from there: - **Domains**: Add one or more domains and verify ownership of each with a DNS `TXT` record. - **Connection**: Pick an identity provider and supply its configuration, with setup instructions embedded inline. Okta, Google Workspace, Microsoft Entra ID, and custom SAML are supported. - **Test**: Run a test sign-in to confirm the connection works end-to-end. - **Activate**: Turn the connection on once the test passes. The connection is scoped to the Organization it's configured in and behaves like any other enterprise connection once it's live: users with a matching email domain sign in through the configured provider. ## Get started Self-serve SSO is available to applications using [Organizations](/docs/guides/organizations/overview) and is enabled per Organization. In the [Clerk Dashboard](https://dashboard.clerk.com/~/organizations), select an Organization, open its **Settings**, and turn on **Allow this organization to set up enterprise SSO** under **Organization permissions**. The Security tab then surfaces wherever your app renders ``. For setup details and requirements, refer to the [self-serve SSO documentation](/docs/guides/configure/auth-strategies/enterprise-connections/self-serve-sso). --- ## Customize your OAuth consent page - URL: https://clerk.com/changelog/2026-06-22-customize-oauth-consent.md - Date: 2026-06-22 OAuth consent is required when a user reviews an OAuth Client's request to access their data and possibly act on their behalf. It's a critical part of OAuth 2.0, MCP and many agentic AI integrations. Until now, that screen was hosted only on Clerk's Account Portal. You can now host it on a route in your own application and style it to match your product. ## What's new - **`` component** — a prebuilt consent UI available in `@clerk/nextjs`, `@clerk/react`, `@clerk/react-router`, `@clerk/tanstack-react-start`, `@clerk/astro`, `@clerk/vue`, and `@clerk/nuxt`. The component reads OAuth authorization parameters from the URL, loads consent metadata, renders requested scopes, and submits the user's allow or deny decision to Clerk. - **Dashboard path configuration** — set your OAuth consent location under **Configure → Paths** in the [Clerk Dashboard](https://dashboard.clerk.com/~/paths). - **Organization selection** — when an OAuth application requests the `user:org:read` scope, `` displays an organization selector so users can choose which org they're granting access on behalf of. For most applications, Clerk recommends using the default Account Portal consent page. If you need the consent screen to live inside your own product, use the prebuilt `` component on your domain — you control the route, layout, and styling, while Clerk keeps consent logic, scope rendering, and denial handling intact. Fully custom consent flows are also possible, but they should be reserved for cases where the prebuilt component cannot support a required layout or interaction. ## Get started Create a route that renders `` for signed-in users: ```tsx {{ filename: 'app/oauth-consent/page.tsx' }} import { OAuthConsent, Show } from '@clerk/nextjs' // Ensure this route does not display any other navigation export const metadata = { referrer: 'strict-origin-when-cross-origin', } export default function OAuthConsentPage() { return ( ) } ``` For visual changes only — colors, fonts, spacing — use the `appearance` prop instead of building a custom UI: ```tsx ``` Keep the consent route focused. If your app uses a shared layout with navigation or account menus, use a minimal layout for this route so users are not pulled away from the OAuth flow. ## Configure it in the Dashboard 1. Create and deploy your consent route (for example, `/oauth-consent`). 2. In the [Clerk Dashboard](https://dashboard.clerk.com/~/paths), open **Configure → Paths** and set the **OAuth consent** location to that route. For production instances, you will need a complete URL. In development instances, set a path relative to the Fallback development host. 3. If all paths have been customized, you have the option to disable the [Account Portal](https://dashboard.clerk.com/~/account-portal) 4. Confirm the consent screen is enabled for every [OAuth application](https://dashboard.clerk.com/~/oauth-applications) that will use the custom route. ## Security OAuth consent is a security boundary. A custom page can weaken it if it hides the requesting application, misstates scopes, buries the deny action, or auto-approves access. Do not use `appearance` overrides to hide scopes, redirect warnings, or the deny action. After shipping, monitor [Application Logs](/docs/guides/dashboard/logs/application-logs) for `oauth_authorization.granted` and `oauth_token.created` events. See our full [security checklist](/docs/guides/configure/auth-strategies/oauth/custom-consent-page#security-checklist) before going to production. ## Custom consent flows If `` cannot support your required layout, you can build a fully custom consent page using methods available in Clerk's React-based SDKs, but you are then responsible for maintaining it as a security-sensitive surface. See the [detailed guide on building a custom OAuth consent page](/docs/guides/configure/auth-strategies/oauth/custom-consent-page#build-a-custom-flow). ## Learn more See the complete reference to [customizing the OAuth consent page](/docs/guides/configure/auth-strategies/oauth/custom-consent-page) for framework-specific examples, dashboard configuration details, and custom flow requirements. --- ## Multi-value mapping for SAML custom attributes - URL: https://clerk.com/changelog/2026-06-12-multi-value-saml-attributes.md - Date: 2026-06-12 SAML custom attributes can now be mapped as multi-valued. When an identity provider sends an attribute with more than one value (common for `groups` or `roles` in Okta and Microsoft Entra ID), Clerk writes every value to the user's `publicMetadata` as an array. Previously, only the first value was kept. ## Enable multi-value attributes Open an enterprise connection in the [Clerk Dashboard](https://dashboard.clerk.com/~/user-authentication/sso-connections), edit a SAML custom attribute, and turn on **Allow multiple values**. Matching values are written to `publicMetadata` always as an array `[]`. If the provider doesn't send the attribute at all, the key isn't written. The same control is available on the Backend API as a `multi_valued` field on each custom attribute. ## Compatibility Multi-value mapping is off by default. Existing custom attributes are unchanged and continue to map the first value. No migration or reconfiguration is required. Refer to the [Multi-valued attributes documentation](/docs/guides/configure/auth-strategies/enterprise-connections/custom-attribute-mapping#multi-valued-attributes) for setup details and how the setting interacts with SCIM. --- ## clerk deploy: guided, resumable, agent-ready - URL: https://clerk.com/changelog/2026-06-10-clerk-deploy.md - Date: 2026-06-10 When we [released the CLI](/changelog/2026-04-22-clerk-cli), we said we were hard at work on deploy. It's ready for you to use today: `clerk deploy` is now available in the [Clerk CLI](/cli), taking your application from development to production with a single command. ![A clerk deploy session showing the plan and production domain prompt](./deploy-example.png) Run `clerk deploy` from a linked project and the CLI walks you through everything production needs: - **Production instance**: Creates a production instance from your development configuration and prompts for your production domain - **DNS records**: Displays the [CNAME records](/glossary#cname-custom-domains-auth) to add at your DNS provider, and can export them as a DNS zone file you can import at any compatible provider - **[OAuth](/glossary#oauth) credentials**: Detects the [social connections](/glossary#social-login) enabled in development and prompts for production Google and Apple credentials, including importing a Google Cloud Console JSON file or pointing at your Apple `.p8` key. Other providers are flagged for setup in the Clerk Dashboard - **Verification**: Checks DNS, SSL, and email DNS in one loop and reports exactly what's still pending ## Built for agents In a non-TTY context, or with `--mode agent`, `clerk deploy` emits a read-only JSON handoff describing the current deploy state instead of prompting. ```bash {{ prompt: '$' }} clerk deploy status --mode agent ``` ## Get started Update to the latest CLI, link your project if you haven't already, and deploy: ```bash {{ prompt: '$' }} clerk update clerk link clerk deploy ``` Read the [full documentation](/docs/cli) for all commands and options. --- ## Clerk Billing now supports plans with per-seat pricing - URL: https://clerk.com/changelog/2026-06-10-per-seat-plans.md - Date: 2026-06-10 Starting today, you can create Plans with per-seat pricing in Clerk Billing, allowing you to charge Organizations based on the number of members using your product. As your customers get larger, they're getting more value out of your product. A five-person team shouldn't necessarily pay the same amount as a fifty-person team. Per-seat pricing makes it easy to align subscription costs with organization size, allowing pricing to scale naturally as organizations grow. For example, you might create a Plan with a $12 monthly charge per member. Smaller organizations pay less, while larger organizations are charged proportionally to their team size. Per-seat pricing is deeply integrated with Clerk Organizations, allowing you to monetize Organization growth without building custom billing or seat management workflows. ## Billing that grows with Organizations When Organizations add new members, Clerk automatically handles seat provisioning behind the scenes. If an Organization exceeds its available seats when adding members, Clerk guides them through a checkout flow to purchase additional seats, ensuring billing stays aligned with membership. Additional seats purchased during an active billing period are prorated automatically, ensuring organizations only pay for the time those seats are in use. At the beginning of each billing period, Clerk automatically adjusts the subscription's seat quantity to match the Organization's current membership count. This ensures billing remains aligned with the provisioned members over time and prevents organizations from paying indefinitely for unfilled seats. Per-seat pricing can be combined with seat limits, allowing you to both charge per member and enforce a maximum Organization size. Per-seat pricing can also be combined with a fee for the Plan itself, a "base fee", to charge a minimum fee for access to the Plan's features. You can even set an "included" number of seats that come with the base fee; Organizations will only be charged per seat after these included seats are used. For example, a Plan can have: - A $20 per month base fee - An $8 per month per-seat fee - 2 included seats - A limit of 10 seats on the Plan | Organization size | Cost | Breakdown | | ----------------- | ---- | ------------------------------------------------------------------------ | | 1 | $20 | $20 for the base fee, no seats over the 2 included | | 3 | $28 | $20 for the base fee, two seats included, $8 for the 1 additional seat | | 10 | $84 | $20 for the base fee, two seats included, $64 for the 8 additional seats | An Organization on this Plan would not be able to invite an eleventh member without changing their Plan, and would be prompted to do so when they go to invite the member. ## A more capable Clerk Billing When we launched Clerk Billing a year ago, we only supported flat fee pricing for Plans. With the recent launch of seat limits and now per-seat pricing, we hope Clerk Billing can offer a compelling experience for businesses that use a seat-based pricing model. We're not done with Clerk Billing yet, and are continuously striving to offer more and more powerful tools to let you build the pricing model that will most accurately capture your product's value. We have a lot we're working on, and we can't wait to share it with you. ## Get started with seat-based billing - Navigate to the [**New Organization plan**](https://dashboard.clerk.com/~/billing/plans/new/org) page in the Clerk Dashboard. - Toggle on the **Seat-based** section. - If you'd like to set a limit, select **Custom limit** and enter the desired value. (You need the B2B Authentication add-on to set a limit greater than 20.) - If you'd like the Plan to allow an unlimited number of seats, select **Unlimited members**. (You need to have the B2B Authentication add-on to select this option.) - Toggle on the **Per-seat fee** section. - Enter the price per seat in the **Cost per member seat monthly** section. - If you'd like to include free seats in the plan, enter the desired value in the **Included seats** section. You can learn more about seat-based billing [in the docs](/docs/guides/billing/seat-based-plans). --- ## Prebuilt Organization components for iOS and Android - URL: https://clerk.com/changelog/2026-06-05-ios-android-organization-management.md - Date: 2026-06-05 Clerk's native mobile SDKs now include prebuilt Organization management UI for iOS and Android. These views cover account switching and Organization settings. ![The OrganizationSwitcherSheet showing Organization account switching options.](./organization-switcher-sheet.png) ![The OrganizationProfileView showing profile details, members, verified domains, and Organization actions.](./organization-profile-view.png) ## What's new - **[`OrganizationSwitcher`](/docs/reference/views/organization/organization-switcher)** renders the active Organization or personal account, then opens native controls for switching accounts, accepting invitations and suggestions, creating Organizations, and managing the active Organization. - **[`OrganizationListView`](/docs/reference/views/organization/organization-list-view)** provides a standalone account picker for selecting a personal account or Organization, including memberships, invitations, suggestions, and Organization creation when available. - **[`OrganizationProfileView`](/docs/reference/views/organization/organization-profile-view)** renders permission-gated Organization management for profile details, members, invitations, requests, verified domains, leaving Organizations, and deleting Organizations. --- ## Email Logs public beta - URL: https://clerk.com/changelog/2026-06-01-email-logs-public-beta.md - Date: 2026-06-01 Email Logs are now available in public beta for production instances. The new [**Email Logs**](https://dashboard.clerk.com/~/email-logs) page in the Clerk Dashboard gives you a reverse-chronological view of transactional email delivery events, so you can debug delivery issues without leaving the Dashboard. Use Email Logs to understand what happened to an email after Clerk sent it, including whether the receiving mail service accepted it, whether delivery was delayed or failed, and whether the user opened or clicked it. You can filter logs by recipient email address, IP address, message ID, time range, and event type. Select any log entry to view its details, including delivery status, response or bounce reason, related metadata, and the original provider payload when available. ## Get started Open [Email Logs](https://dashboard.clerk.com/~/email-logs) from the **Logs** section of the Clerk Dashboard. For workspaces using custom roles and permissions, grant the **Email logs** read permission to the roles that should have access. --- ## Largest organizations report - URL: https://clerk.com/changelog/2026-05-26-largest-organizations-report.md - Date: 2026-05-26 The Orgs tab of your Overview page now includes a report stack ranking the largest organizations in your instance by current member count. - **Top organizations at a glance**: See your biggest orgs in descending order with member counts, and a link to each organization's detail page. - **Visual size comparison**: Each org is rendered as a bar scaled to its member count, making it easy to see how your top orgs stack up against each other. - **Spot outliers and growth**: See how usage is distributed across your tenants and catch unusual growth patterns. Open the [Clerk Dashboard](https://dashboard.clerk.com) and head to the Overview page to view your largest organizations. Available now for all instances with organizations enabled. --- ## Flush elevation option for page-mounted components - URL: https://clerk.com/changelog/2026-05-22-flush-appearance-option.md - Date: 2026-05-22 A new `elevation` appearance option lets you control whether page-mounted Clerk components render inside a card (`raised`) or directly on the page (`flush`). The default is `raised`, preserving existing behavior. ```tsx ``` When set to `flush`, components drop their card background, border, and shadow, making it easier to embed sign-in, and sign-up components into your own layouts. Modals and popovers always use `raised` regardless of this setting. See the [appearance options documentation](/docs/nextjs/guides/customizing-clerk/appearance-prop/options) for more details. --- ## Groups and custom attributes mapping are now generally available - URL: https://clerk.com/changelog/2026-05-21-directory-sync-groups-attributes-ga.md - Date: 2026-05-21 Groups and custom attributes mapping are now generally available, completing the Directory Sync (SCIM) GA rollout that began with the [core provisioning release](/changelog/2026-04-16-directory-sync). Both features are enabled for all users with no extra configuration required. - **Groups mapping** assigns Clerk roles automatically based on IdP group membership. When a user is added to a group in your IdP, Clerk applies the mapped role. When they're removed, they fall back to the next mapped role. For users in multiple groups with different role mappings, a configurable precedence order controls which role wins. - **Custom attributes mapping** syncs additional user data from your IdP (such as `department`, `employee_id`, or `cost_center`) directly into `publicMetadata` on the Clerk user object. Attribute definitions are configured once at the enterprise connection level and shared across both your SSO connection (SAML or OIDC) and your Directory Sync connection, so the same attributes are available regardless of how a user authenticates or is provisioned. When Directory Sync is enabled, it becomes the exclusive source for those attribute values and they're read-only in Clerk until Directory Sync is disabled. ## Getting started To enable Directory Sync, navigate to an enterprise connection in the [Clerk Dashboard](https://dashboard.clerk.com/~/user-authentication/sso-connections), open the **Directory Sync** tab, and toggle it on. Clerk generates a SCIM base URL and bearer token to configure in your IdP. Refer to the [Directory Sync documentation](/docs/guides/configure/auth-strategies/enterprise-connections/directory-sync) for setup guides, the [Role mapping documentation](/docs/guides/configure/auth-strategies/enterprise-connections/directory-sync#role-mapping) for groups-to-role configuration, and the [Custom attribute mapping documentation](/docs/guides/configure/auth-strategies/enterprise-connections/custom-attribute-mapping) for details on the shared attribute pool. ## Pricing Directory Sync, including groups and custom attributes mapping, is included with your enterprise connection at no extra charge. Refer to the [pricing page](/pricing) for connection pricing details. --- ## Organizations support in OAuth Applications - URL: https://clerk.com/changelog/2026-05-14-oauth-organizations.md - Date: 2026-05-20 OAuth Applications now integrate with Clerk Organizations. When your instance has Organizations enabled, users going through the OAuth flow can select which organization they're acting on behalf of, and the OAuth client receives that selection as an `org_id` claim on the access token. ![An OAuth Consent screen shows a dropdown selection expanded with 3 organizations to choose from](./image.png) ## How it works We've added a new `user:org:read` scope to OAuth Applications. When a client requests this scope and the user grants it, the OAuth consent screen displays an organization selector. After consent, the access token issued to the client includes an `org_id` claim populated with the selected organization. If the consent screen is disabled for your OAuth Application, `org_id` is populated with the user's last active organization instead. For convenience, the userinfo endpoint also returns `org_name` and `org_slug` alongside `org_id`, so clients can display organization context without an extra lookup. ## Enabling it on an existing OAuth Application Updating an existing OAuth Application is as simple as enabling the new `user:org:read` scope in its settings on the [Clerk Dashboard](https://dashboard.clerk.com/~/oauth-applications). No other changes are required — once the scope is available, clients can request it on their next authorization request. To learn more, see our [OAuth Applications documentation](/docs/guides/configure/auth-strategies/oauth/how-clerk-implements-oauth#organizations-and-oauth). --- ## Improved observability with Application Logs - URL: https://clerk.com/changelog/2026-05-06-application-logs.md - Date: 2026-05-06 A new [**Logs**](https://dashboard.clerk.com/~/application-logs) page has been introduced into the Clerk Dashboard meant to give increased visibility into the Clerk-driven events across your applications. *Application Logs* track things like sign-ins, sign-ups, user updates, organization changes, billing events, [and many more](/docs/guides/dashboard/logs/application-logs) — enabling more detailed debugging and improved observability for your business. ## Filtering and search The logs page displays a reverse-chronological feed of events and you can narrow results using filters: - **Event type** — Filter by event type (e.g., `user.created`, `sign_in.completed`). Supports trailing wildcards (e.g., `sign_in.*`). - **Actor** — Filter by the user or API key that triggered the event. - **Subject** — Filter by the resource ID being acted upon (e.g., a user ID or organization ID). - **Trace ID** — Correlate events across systems using a distributed trace ID. - **Device** — Filter by device ID. - **Date range** — Scope results to a specific time window. Select any log entry to view its full details, including event metadata and a JSON payload containing additional information related to the event. ## Get started Application Logs are available for all plans with varying levels of retention; see our [pricing page](/pricing) for more details. You can access the [**Logs** view](https://dashboard.clerk.com/~/application-logs) today in the Clerk Dashboard or read the [full documentation](/docs/guides/dashboard/logs/application-logs) to learn more. ### Going forward App logs are just the start. We're hard at work on additional observability including Email, SMS, and Administrative logs for actions taken by your app's admins within the Clerk Dashboard and the new [Clerk CLI](/cli). Stay tuned for more. --- ## Clerk CLI - URL: https://clerk.com/changelog/2026-04-22-clerk-cli.md - Date: 2026-04-22 [Clerk CLI](/cli) is a (surprise, surprise) command-line tool for setting up and managing Clerk directly from your terminal or agentic harness. It's [open source](https://github.com/clerk/cli) and available for you to use today. The Clerk CLI gives both developers and agents a scriptable, terminal-based interface to Clerk so they can avoid click-ops and build faster. ## Key commands - `clerk init` — Detects your framework, scaffolds Clerk into your project, and gets auth ready to configure. This is the fastest way to start using Clerk in an existing or new project. - `clerk config` — Manage your application's settings directly from the command line. Choose sign-in methods, configure redirects, set session policies - everything you'd normally do in the dashboard, now in code. - `clerk api` — Interact with the Clerk API directly. Fetch users, organizations, sessions, and all other resources all through one command. ## Try it Use a script runner... ```bash {{ prompt: '$' }} bunx clerk init ``` ...or install the CLI globally and try it out today: ```bash {{ prompt: '$' }} bun add -g clerk clerk init ``` ```bash {{ prompt: '$' }} npm install -g clerk clerk init ``` ```bash {{ prompt: '$' }} pnpm install -g clerk clerk init ``` ```bash {{ prompt: '$' }} yarn global add clerk clerk init ``` ```bash {{ prompt: '$' }} brew install clerk/stable/clerk clerk init ``` ```bash {{ prompt: '$' }} curl -fsSL https://clerk.com/install | bash clerk init ``` Read the [full documentation](/docs/cli) or run `clerk --help` to see the full list of commands and options to get started. ## What's next? This is the first release of the Clerk CLI and we're working on adding more commands and features along the way to make it even more powerful. For example, we're hard at work on `clerk deploy` — a single command to validate your auth setup and push it live. Deploy will handle syncing your local configuration to production, so you can go from development to launch without switching contexts. --- ## API Keys General Availability - URL: https://clerk.com/changelog/2026-04-17-api-keys-ga.md - Date: 2026-04-17 API keys are now generally available as of April 6th. Part of the [machine authentication](/docs/machine-auth/overview) suite, API keys let your users create credentials that delegate access to your application's API on their behalf. ## Pricing Billing is now active. Each month includes a free allocation: - 1,000 key creations, then `$0.001` per creation - 100,000 key verifications, then `$0.00001` per verification ## Get Started - [API keys guide](/docs/guides/development/machine-auth/api-keys): Complete walkthrough of enabling and using API keys - [Backend SDK reference](/docs/reference/backend/api-keys/list): Full API for creating, listing, verifying, and revoking keys - [Dashboard](https://dashboard.clerk.com/~/platform/api-keys): Enable API keys for your application --- ## Directory Sync (SCIM) is now generally available - URL: https://clerk.com/changelog/2026-04-16-directory-sync.md - Date: 2026-04-16 Directory Sync (SCIM) is now generally available and enabled for all users. When users are added, updated, or removed in your identity provider, those changes are automatically reflected in Clerk, without any manual account management. The following enhancements to Directory Sync are in public beta: - **Custom attribute mapping** lets you sync additional user data from your IdP (such as `department`, `employee_id`, or `cost_center`) directly into `publicMetadata` on the Clerk user object. Attribute definitions are configured once at the enterprise connection level and shared across both your SSO connection (SAML or OIDC) and your Directory Sync connection, so the same attributes are available regardless of how a user authenticates or is provisioned. When Directory Sync is enabled, it becomes the exclusive source for those attribute values and they're read-only in Clerk until Directory Sync is disabled. - **Groups to role mapping** lets you automatically assign Clerk roles based on IdP group membership. When a user is added to a group in your IdP, Clerk assigns the mapped role. When they're removed, they fall back to the next mapped role. If a user belongs to multiple groups with different role mappings, you can configure a precedence order to control which role takes effect. ## Getting started To enable Directory Sync, navigate to an enterprise connection in the [Clerk Dashboard](https://dashboard.clerk.com/~/user-authentication/sso-connections), open the **Directory Sync** tab, and toggle it on. Clerk generates a SCIM base URL and bearer token to configure in your IdP. Refer to the [Directory Sync documentation](/docs/guides/configure/auth-strategies/enterprise-connections/directory-sync) for setup guides for Okta and Microsoft Entra ID, and the [Custom Attribute Mapping documentation](/docs/guides/configure/auth-strategies/enterprise-connections/custom-attribute-mapping) for details on the shared attribute pool. ## Compatibility note Our implementation follows the SCIM 2.0 protocol. However, your identity provider (and how you configure it) may not match our implementation completely. If you run into any compatibility issues, please report them to [team-orgs@clerk.dev](mailto:team-orgs@clerk.dev). We have a team standing by and will work to get compatibility resolved quickly. ## Pricing Directory Sync is included with your enterprise connection at no extra charge. Refer to the [pricing page](/pricing) for connection pricing details. --- ## Theme Expo native components from a JSON file - URL: https://clerk.com/changelog/2026-04-08-expo-native-component-theming.md - Date: 2026-04-16 You can now customize the look and feel of `@clerk/expo`'s native components (``, ``, ``) on both iOS and Android by pointing the `@clerk/expo` config plugin at a JSON theme file. ```json {{ filename: 'app.json' }} { "expo": { "plugins": [["@clerk/expo", { "theme": "./clerk-theme.json" }]] } } ``` ```json {{ filename: 'clerk-theme.json' }} { "colors": { "primary": "#6C47FF", "background": "#FFFFFF", "foreground": "#0F172A", "border": "#E2E8F0" }, "darkColors": { "primary": "#8B6FFF", "background": "#0B0B0F", "foreground": "#FFFFFF" }, "design": { "borderRadius": 12, "fontFamily": "Inter" } } ``` The schema supports: - **`colors`** — 15 semantic tokens (`primary`, `background`, `input`, `danger`, `success`, `warning`, `foreground`, `mutedForeground`, `primaryForeground`, `inputForeground`, `neutral`, `border`, `ring`, `muted`, `shadow`) as 6- or 8-digit hex strings. - **`darkColors`** — same shape as `colors`, applied automatically when the device is in dark mode. Set `"userInterfaceStyle": "automatic"` in your `app.json` to let the system switch modes, or pin to `"light"` / `"dark"` to always use one palette. - **`design.borderRadius`** — number, applied across components on both platforms. - **`design.fontFamily`** — string, iOS only. The font must be bundled with your iOS app. The JSON is validated at prebuild — invalid hex colors or value types fail the build with a clear error. iOS embeds the parsed theme in `Info.plist`; Android copies it to `android/app/src/main/assets/clerk_theme.json`. Both are picked up by the native SDKs automatically. See the [theming reference](/docs/reference/expo/native-components/theming) for the full schema and examples. --- ## Infinite scrolling in Overview tables - URL: https://clerk.com/changelog/2026-04-15-infinite-scroll-overview-tables.md - Date: 2026-04-15 The Overview page now includes infinite scrolling across all supported table variants, so you can keep exploring data without stopping to change pages. This applies to the **Users** and **Organizations** views, along with the **Waitlist mode** overview, making it easier to browse large datasets in one continuous flow. Open the [Clerk Dashboard](https://dashboard.clerk.com) and scroll through the Overview tables to see the new experience. --- ## Filter test users in Overview analytics - URL: https://clerk.com/changelog/2026-04-14-filter-test-users-overview.md - Date: 2026-04-14 The Overview page now includes a **Filter test users** setting for the **Users** view. User analytics previously showed combined regular and test user data. Now, when the toggle is enabled, test users are excluded from all Overview charts and metrics. Test users are defined as having: - `+clerk_test` in the email identifier - `+15555550100` as the phone Open the [Clerk Dashboard](https://dashboard.clerk.com) and use the Overview settings menu in the users view to try it. --- ## Annual-only plans for Clerk Billing - URL: https://clerk.com/changelog/2026-04-13-annual-only-plans.md - Date: 2026-04-13 Clerk Billing now has support for annual-only subscriptions. Previously, all plans renewed monthly with an option to subscribe on an annual basis. Now, you can configure plans to support annual-only billing. To enable support for annual-only plans, visit your applications [Updates](https://dashboard.clerk.com/~/updates) page to opt-in to annual-only plans. > \[!IMPORTANT] > Opting into annual-only plans will result in the `fee` property of plans potentially being `null`. Please ensure any logic your application has that interacts with the `fee` property is updated to account for `null` values. To configure a plan for annual-only billing, enable only the "Annual base fee" option in the plan settings. ![Screenshot of the Pricing details section of the plan creation screen, showing the annual base fee toggle in the on position](./plan-form.png) --- ## Preview Custom Session Claims - URL: https://clerk.com/changelog/2026-04-09-preview-session-claims.md - Date: 2026-04-09 When customizing session tokens, you can now preview the resulting claims before saving your changes. Select a user to generate claims based on the current template. This lets you verify that custom claims, template expressions, and organization data produce exactly the claims you expect. Previously, saving a template then inspecting a real session token was required to check the template is correct. Preview lets you ensure expected behavior before impacting real users. ![Preview of custom session claims](./image.png) --- ## Restrict end users from changing their identifiers - URL: https://clerk.com/changelog/2026-04-06-restrict-changes-user-attributes.md - Date: 2026-04-06 You can now prevent end users from adding new or modifying existing email addresses, phone numbers, or usernames after they have signed up through the new **Restrict changes** toggle in the Clerk Dashboard. Navigate to the [**User & authentication**](https://dashboard.clerk.com/~/user-authentication/user-and-authentication) page to enable. ![Clerk Dashboard restrict changes in email address after sign up](./immutable_email_dashboard.png) Enabling this feature gives you the ability to have maximal control over the exact identifiers your end users can use to sign in to your application. If you'd like to control which identifiers are allowed at sign-up rather than locking them afterwards, see [restrictions](/docs/guides/secure/restricting-access) for allowlists, blocklists, and disposable email blocking. With this setting enabled, your end users will still be able to view their identifiers in their User Profile, but will not be able to add, remove, or modify the respective identifier. For email addresses, this restriction extends to social connections: End users are prohibited from connecting an OAuth account that would otherwise add a new email address to their account. Of course, you still have the ability to modify their end users' identifiers at any time on the **Users** page of the [Clerk Dashboard](https://dashboard.clerk.com) or using our [Backend API](/docs/reference/backend-api/tag/email-addresses). If you would like to have support for restricting end users from changing other attributes than email address, phone number, or username, please reach out to us to share this feedback. --- ## Clerk Billing now supports plans with seat limits - URL: https://clerk.com/changelog/2026-04-02-seat-limits.md - Date: 2026-04-02 Starting today, membership limits on organizations can be granted directly by subscribing to a Clerk Billing plan, allowing organizations to purchase a higher membership limit in a self-serve fashion. This makes it possible to target plans to organizations of specific size. For example, you may let organizations use your most affordable plan for up to ten seats, but require them to upgrade to a more expensive plan to get unlimited seats. ![A pricing table for 3 different plans, with different seat limits on each plan](./pricing-table.png) Seat limits are enforced automatically through the integration of Clerk's Billing and B2B Authentication products. When an organization hits its seat limit, Clerk will prevent adding additional members and guide users toward upgrading. ![A disabled invitation button with a message indicating the user needs to upgrade their plan.](./invite.png) ## More seat-based features to come This release is our first step towards seat-based billing for Clerk Billing. We know that many use cases require organizations to be able to purchase a specific number of seats specified at checkout at a per-seat cost; we hope to have more to say on that functionality in the near future. We're excited to ship this first step into seat-based billing and to expand on it. ## How to create a seat-limited plan - Navigate to the [New Organization plan](https://dashboard.clerk.com/~/billing/plans/new/org) page in your instance's settings. - Toggle on the Seat-based section. - If you'd like the plan to convey an unlimited number of seats, leave Unlimited members selected. (You need to have the B2B Authentication add-on to select this option.) - If you'd like to set a limit, select Custom limit and enter the limit. --- ## Overview for waitlist mode - URL: https://clerk.com/changelog/2026-03-27-waitlist-overview.md - Date: 2026-03-27 This new section brings the most relevant waitlist information into one place, so you can understand sign-up access without jumping between pages. This makes it easier to see how many users are waiting for access, how many have already been invited, and which recent entries may need follow-up. ### Features - **Waitlist counts**: Track how many users are on the waitlist, how many have been invited, and how many have been accepted. - **Recent entries**: Review recent waitlist activity directly from the Overview page, *including a new infinite scroll table for large waitlists*. - **Faster follow-up**: Jump from the overview to the full waitlist view when you need to take action. Open the Overview page for your production instance *in waitlist mode* in the [Clerk Dashboard](https://dashboard.clerk.com) to see the new experience. --- ## Clerk is now available in Stripe Projects - URL: https://clerk.com/changelog/2026-03-26-clerk-stripe-projects.md - Date: 2026-03-26 You can now add authentication and user management to your app through [Stripe Projects](https://projects.dev). Available in developer preview, this CLI-based workflow lets teams and AI agents provision Clerk directly from the terminal. Using the Stripe CLI, you can: - Connect an existing Clerk account or have one created for you - Provision a new Clerk application with both development and production credentials - Manage authentication keys, rotate secrets, and access your Clerk dashboard — all from Stripe To get started, install the Stripe Projects plugin for Stripe's CLI and initialize your project: ```bash stripe plugin install projects stripe projects init my-app stripe projects add clerk ``` Select Clerk to add authentication and start building, or visit the [documentation](/docs) to learn more. --- ## Organization activity report - URL: https://clerk.com/changelog/2026-03-16-organization-activity.md - Date: 2026-03-16 The organization activity report shows daily member engagement levels for each org, helping you understand how teams are using your product. - **Visualize engagement** - Each day in the report is color-coded by the percentage of total organization members who were active, making it easy to spot trends and patterns. - **Navigate by year** - Use the year selector to browse activity across different years. - **Hover for details** - Tooltips show the percentage of org members who were active on each day. *Note: Activity data is available starting from January 2026.* To view the activity report, open any organization's profile page from the [Organizations](https://dashboard.clerk.com/~/organizations) list in your Clerk Dashboard. Keep an eye out for continued improvements to the organization profile page. --- ## Create and manage enterprise connections through Clerk's API - URL: https://clerk.com/changelog/2026-03-09-bapi-enterprise-connections.md - Date: 2026-03-09 You can now fully manage both SAML and OIDC enterprise connections via the Clerk Backend API. Previously, you could only manage SAML connections via the API. ## What's new The following endpoints are now available on Clerk's backend API: | Method | Path | Description | | -------- | ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | | `POST` | `/v1/enterprise_connections` | Create an enterprise connection. Accepts `provider`, `domains`, `name` and `organization_id` as params | | `GET` | `/v1/enterprise_connections` | List enterprise connections. Query: `organization_id` (optional), pagination. | | `GET` | `/v1/enterprise_connections/{enterpriseConnectionID}` | Get a single enterprise connection. | | `PATCH` | `/v1/enterprise_connections/{enterpriseConnectionID}` | Update an enterprise connection. | | `DELETE` | `/v1/enterprise_connections/{enterpriseConnectionID}` | Delete an enterprise connection. | If you currently use the [`/saml_connections`](https://clerk.com/docs/reference/backend-api/tag/saml-connections) endpoint, we recommend migrating to the new [`/enterprise_connections`](https://clerk.com/docs/reference/backend-api/tag/enterprise-connections) endpoint. This unified API allows you to manage both SAML and OIDC connections, and will serve as the primary interface moving forward. Support for the legacy SAML endpoint may be phased out in the future. ## Getting started Visit the [API reference](https://clerk.com/docs/reference/backend-api/tag/enterprise-connections) for detailed documentation on request parameters and response formats. --- ## Native React Native components, Google Sign-In, and Core 3 - URL: https://clerk.com/changelog/2026-03-09-expo-native-components.md - Date: 2026-03-09 `@clerk/expo` 3.1 brings native UI components powered by SwiftUI (iOS) and Jetpack Compose (Android), native Google Sign-In, and the new Core-3 Signal API. This is a major version bump that requires Expo SDK 53+. ## Native React Native components Three prebuilt native components are now available from `@clerk/expo/native`: - **``** renders the full sign-in/sign-up UI natively, with support for `signIn`, `signUp`, and `signInOrUp` modes. Session sync to the JS SDK happens automatically. - **``** displays the user's avatar and opens the native profile modal on tap. It fills its parent container, so the parent controls the size and shape. - **``** renders the profile management UI inline. For modal presentation, use the new `useUserProfileModal()` hook. All components use hook-based state management rather than callbacks. React to auth state changes with `useAuth()` in a `useEffect`: ```tsx import { AuthView, UserButton } from '@clerk/expo/native' import { useAuth, useUserProfileModal } from '@clerk/expo' function App() { const { isSignedIn } = useAuth() const { presentUserProfile } = useUserProfileModal() if (!isSignedIn) { return } return ( <> Manage Profile ) } ``` These components require the `@clerk/expo` Expo config plugin, which automatically adds the [clerk-ios](https://github.com/clerk/clerk-ios) and [clerk-android](https://github.com/clerk/clerk-android) native SDKs to your project. See the [native components overview](/docs/reference/expo/native-components/overview) for setup and usage. ## Native Google Sign-In Google Sign-In now uses platform-native APIs instead of browser-based OAuth: - **iOS**: ASAuthorization (system credential picker) - **Android**: Credential Manager (one-tap / passkey-ready) This is exposed via the `NativeClerkGoogleSignIn` TurboModule spec and integrated into the `@clerk/expo` config plugin. No extra packages are needed beyond configuring your Google OAuth credentials in the Clerk Dashboard. ## Core-3 Signal APIs `@clerk/expo` 3.1 ships with the [Core-3 Signal API](/docs/guides/development/upgrading/upgrade-guides/core-3), which replaces the legacy `setActive()` pattern with reactive hooks: ```tsx // Core 3 const { signIn } = useSignIn() await signIn.create({ identifier: email }) await signIn.password({ password }) if (signIn.status === 'complete') { await signIn.finalize({ navigate: () => router.push('/') }) } ``` Key changes from Core 2: - `signIn.password()`, `signIn.emailCode.sendCode()` replace `signIn.attemptFirstFactor()` - `signIn.finalize()` replaces `setActive({ session: signIn.createdSessionId })` - Error handling via `errors.fields.identifier?.message` instead of try/catch See the [Expo quickstart](/docs/quickstarts/expo) and [Core-3 upgrade guide](/docs/guides/development/upgrading/upgrade-guides/core-3) for migration details. ## New hooks Three new hooks are exported from `@clerk/expo`: | Hook | Description | | ----------------------- | --------------------------------------------------------------------------------------------- | | `useUserProfileModal()` | Present the native profile modal imperatively. Returns `{ presentUserProfile, isAvailable }`. | | `useNativeSession()` | Access native SDK session state: `isSignedIn`, `sessionId`, `user`, `refresh()`. | | `useNativeAuthEvents()` | Listen for auth state changes (`signedIn`, `signedOut`) from native components. | ## Get started Follow the [Expo quickstart](/docs/quickstarts/expo) to set up a new project with native components, or check the [native components reference](/docs/reference/expo/native-components/overview) for the full API. The [clerk-expo-quickstart](https://github.com/clerk/clerk-expo-quickstart) repo has three example apps: JS-only, JS with native sign-in, and full native components. --- ## X social connection improvements - URL: https://clerk.com/changelog/2026-03-06-x-social-connection-improvements.md - Date: 2026-03-06 Users who sign in with X/Twitter now get their email address returned as part of the authentication flow. Previously, they were prompted to enter it manually as an extra step for.' Additionally, Clerk development instances can now enable the X/Twitter connection with zero additional config for easier testing. To add X/Twitter v2 as a social connection in your application, see the [X/Twitter guide](/docs/guides/configure/auth-strategies/social-connections/x-twitter). --- ## JWT format support for M2M tokens - URL: https://clerk.com/changelog/2026-02-24-m2m-jwt-tokens.md - Date: 2026-03-05 ## Why JWT? JWT M2M tokens offer several advantages over opaque tokens: - **Networkless verification** — JWTs can be verified locally using your instance's public key, without making a network request to Clerk's servers - **No verification cost** — Opaque token verification costs `$0.00001` per request, while JWT verification is free since it happens locally - **Self-contained** — All necessary information (machine ID, claims, expiration) is embedded in the token itself - **Lower latency** — Local verification is significantly faster than a network round-trip ## When to use opaque tokens Opaque tokens remain valuable for security-sensitive scenarios: - **Instant revocation** — Opaque tokens can be invalidated immediately, while JWTs remain valid until they expire - **Maximum security** — Opaque tokens do not contain any embedded information. Server-side verification is required to access payload data. ## Getting Started **Dashboard** To generate your M2M token format: 1. Navigate to [Machines](https://dashboard.clerk.com/~/machines/configure) in the Clerk Dashboard 2. Select the machine you want to generate the token for. 3. Select **Generate token** 4. Toggle **Generate token as JWT** 5. Select **Create** **SDK** ```javascript // Create a JWT token on Machine A const m2mToken = await clerkClient.m2m.createToken({ tokenFormat: 'jwt', }) // Send authenticated request to Machine B await fetch('', { headers: { Authorization: `Bearer ${m2mToken.token}`, }, }) // Verify the token on Machine B — no network request needed const verified = await clerkClient.m2m.verify({ token }) ``` ### Pricing We will begin charging for M2M token usage starting March 16, 2026. The pricing will be: - `$0.001` per token creation - `$0.00001` per token verification (opaque tokens only) For more details, see the [M2M tokens documentation](/docs/machine-auth/m2m-tokens) and [token formats documentation](/docs/guides/development/machine-auth/token-formats). --- ## Chrome Extension JavaScript SDK support - URL: https://clerk.com/changelog/2026-03-04-chrome-extension-js-quickstart.md - Date: 2026-03-04 The `@clerk/chrome-extension` SDK now fully supports vanilla JavaScript (non-React) usage through `createClerkClient()` imported from `@clerk/chrome-extension/client`. A new [Chrome Extension JS Quickstart](/docs/getting-started/quickstart/chrome-extension-js) guide is available to help you get started. ## `createClerkClient()` for vanilla JS Use `createClerkClient()` from `@clerk/chrome-extension/client` to initialize Clerk in a popup or side panel without React: ```ts {{ filename: 'src/popup.ts' }} import { createClerkClient } from '@clerk/chrome-extension/client' const clerk = createClerkClient({ publishableKey: process.env.CLERK_PUBLISHABLE_KEY, }) await clerk.load({ allowedRedirectProtocols: ['chrome-extension:'], }) ``` ## `background` option for `createClerkClient()` Whether you're using React or vanilla JS, `createClerkClient()` from `@clerk/chrome-extension/client` now accepts a `background: true` option for use in background service workers. This replaces the separate `@clerk/chrome-extension/background` import. ```ts {{ filename: 'src/background/index.ts' }} import { createClerkClient } from '@clerk/chrome-extension/client' async function getToken() { const clerk = await createClerkClient({ publishableKey: process.env.CLERK_PUBLISHABLE_KEY, background: true, }) if (!clerk.session) { return null } return await clerk.session?.getToken() } ``` ## Deprecation: `@clerk/chrome-extension/background` Importing `createClerkClient` from `@clerk/chrome-extension/background` is now deprecated. Both React and vanilla JS extensions should update to import from `@clerk/chrome-extension/client` with the `background: true` option instead. --- ## Core 3 - URL: https://clerk.com/changelog/2026-03-03-core-3.md - Date: 2026-03-03 > \[!NOTE] > **Editor's note (August 2026):** Keyless mode has been removed. For supported frameworks, the current no-account flow is `clerk init`, which provisions an accountless application and writes development keys for you. For other frameworks, the CLI applies the supported setup and guides you through the remaining steps, which may include adding API keys. We're excited to announce the latest major release of Clerk's SDKs, Core 3. With the release, [we're investing in better customization primitives and agent-friendly APIs](/blog/2026-03-03-clerk-for-the-ai-era). Highlights include: - [**Improved customization APIs**](#improved-customization-apis): New hooks for building custom sign in, sign up, and checkout flows. - [**Theme editor and interactive docs**](#theme-editor-and-interactive-docs): Customize components visually and preview props live in the docs. - [**Agent-optimized onboarding**](#agent-optimized-onboarding-for-more-frameworks): Keyless mode for more SDKs: TanStack Start, Astro, and React Router. - [**Modern React support**](#modern-react-support): Improved support for apps that use concurrent rendering features. - [**Performance improvements**](#performance-improvements): Smaller bundles, faster token fetching, better offline handling. ## Upgrade today We've built an upgrade CLI that scans your codebase and applies codemods for most breaking changes. If you've used our upgrade tool before, the process is the same. ```bash npx @clerk/upgrade ``` Core 3 requires **Node.js 20.9.0+**. For the full list of changes, upgrade prompts, and step-by-step instructions, see the [Core 3 upgrade guide](/docs/guides/development/upgrading/upgrade-guides/core-3). > \[!NOTE] > If you need to reference the previous documentation, the [Core 2 docs](/docs/core-2) are still available. ## Improved customization APIs We've redesigned the APIs for the `useSignIn`, `useSignUp` and `useCheckout` hooks, and introduced a new `useWaitlist` hook. These refreshed APIs make building custom auth UIs easier for humans and agents. Previously, you needed to maintain your own state for attempt status, loading states, and error parsing. Now, it's all exposed from the hooks: ```javascript // signIn is stateful, updates will trigger re-renders const { signIn, fetchStatus, errors } = useSignIn() // Step methods map directly to the flow await signIn.password({ emailAddress, password }) await signIn.emailCode.sendCode() await signIn.emailCode.verifyCode({ code }) // Read the resource's status directly signIn.status // 'needs_first_factor' | 'needs_second_factor' | 'complete' // Built-in fetch state fetchStatus // 'idle' | 'fetching' // Structured field-level errors errors.fields.identifier // "Couldn't find your account" errors.fields.password // "Password is incorrect" ``` The same structure applies whether you're building a sign up form, a waitlist, or a checkout flow, so you don't need to learn a different API for each one. The hooks are designed to work with any component library, whether you're using shadcn/ui, Radix, or your own components. We've also rewritten all of our [custom flow documentation](/docs/guides/development/custom-flows/overview) to use the new hooks. ## Theme editor and interactive docs We've launched a [theme editor](https://clerk.com/components/theme-editor) that lets you visually customize Clerk's prebuilt components and copy the resulting `appearance` prop configuration into your app. You can adjust colors, spacing, typography, and borders, and see the changes in real time. Give it a whirl and share your custom themes with us! Our component documentation is now interactive too. You can tweak props, see live previews, and copy working code directly from the docs. ## Agent-optimized onboarding for more frameworks Keyless mode, the ability to try Clerk without creating an account or configuring API keys, now works with **TanStack Start**, **Astro**, and **React Router**. You can go from `pnpm install` to a working auth setup without leaving your editor. Great for agents! ## Modern React support Clerk now works correctly when your app is using React's concurrent features, including transitions, Suspense, and streaming SSR. Previously, Clerk's auth state synchronization could conflict with concurrent rendering, leading to stale state during `useTransition` navigations or hydration mismatches with streaming. Core 3 reworks how Clerk manages auth state internally to resolve these issues. No code changes are needed on your end. ## Performance improvements - **Smaller bundles**: React is now shared across all framework SDKs instead of being bundled separately with Clerk's components. This saves roughly \~50KB gzipped (the size of `react` + `react-dom`) for apps using components and framework-specific packages like `@clerk/nextjs` or `@clerk/tanstack-react-start`. - **Faster satellite domains**: Previously, satellite domains triggered a Handshake redirect to the primary domain on every first page load, even for anonymous visitors. Core 3 introduces a `satelliteAutoSync` option (defaults to `false`) that skips the redirect when no session cookies exist. The handshake now only fires after an explicit sign in action, eliminating the unnecessary redirect for most satellite traffic. - **Better offline handling**: `getToken()` previously returned `null` both when the user was signed out and when the device was offline. The latter was unintentional. It now throws a `ClerkOfflineError` when the network is unavailable, so you can more reliably handle being offline in your application. - **Optimized token fetching**: `getToken()` now proactively refreshes session tokens in the background before they expire, so your app never has to wait for a token refresh mid-request. This eliminates intermittent blocking delays in apps that make frequent API calls, like AI chat apps with sequential requests. ## Other updates - **Simplified package names**: `@clerk/clerk-react` is now `@clerk/react`. `@clerk/clerk-expo` is now `@clerk/expo`. The upgrade CLI handles the rename. - **Unified `` component**: ``, ``, and `` are replaced by a single `` component. Use `when="signed-in"`, `when="signed-out"`, or pass a condition callback for authorization checks. In certain scenarios, these components still expose the content they are wrapping in your source code. We picked `Show` as the new name to make it clear that this utility should be only be used to control visibility. [Learn more](/docs/react/reference/components/control/show). ```jsx {{ prettier: false }} // Previously // Previously has({ role: 'admin' })}> ``` - **Automatic light/dark theme**: Previously, you had to manually switch Clerk's component theme depending on the theme of your application. Now, Clerk's components automatically match your app's color scheme if it supports light and dark mode. No additional configuration needed. [Learn more](/docs/react/guides/customizing-clerk/appearance-prop/themes#default-theme). - **Automatic Vite env detection**: Clerk detects environment variables in Vite-based projects automatically. No more manually passing `VITE_CLERK_PUBLISHABLE_KEY`. [Learn more](/docs/guides/development/clerk-environment-variables). - **Portal provider**: New `UNSAFE_PortalProvider` component lets you specify a custom container for Clerk's portaled UI elements (popovers, modals, tooltips). This solves a common issue when using Clerk components inside libraries like Radix Dialog or React Aria, where portaled elements would render to `document.body` and end up behind the dialog. [Learn more](/docs/reference/components/utilities/portal-provider). - **Frontend API proxy helper**: `clerkMiddleware` in Next.js and Express now supports proxying requests to Clerk's Frontend API. Previously, you had to implement this yourself following the guide in our docs. Enable it with `frontendApiProxy: { enabled: true }` in your middleware config. [Learn more](/docs/guides/dashboard/dns-domains/proxy-fapi). - **Types subpath exports**: You can now import Clerk types directly from any SDK package (e.g. `import type { UserResource } from '@clerk/react/types'`) instead of installing the separate `@clerk/types` package. `@clerk/types` has been deprecated. - **Next.js cache components support**: Baseline support for Next.js's cache components. If you're using cache components, `ClerkProvider` should be placed inside `` rather than wrapping ``. - **Component changelog**: A new centralized [component changelog](/docs/reference/components/changelog) tracks visual and behavioral updates to prebuilt components, independent of SDK releases. ## Deprecations - **Clerk Elements**: Deprecated in favor of the redesigned hooks, which cover the same custom UI use cases with less complexity. - **`@clerk/types`**: As mentioned above, the dedicated types package has been deprecated in favor of exposing types through existing SDKs. - For additional deprecations and breaking changes, see the [upgrade guide](/docs/guides/development/upgrading/upgrade-guides/core-3). If you run into issues upgrading, reach out on [Discord](https://clerk.com/discord) or contact [support](https://clerk.com/contact/support). We're here to help. Happy building! --- ## Organization retention report - URL: https://clerk.com/changelog/2026-02-24-organization-retention.md - Date: 2026-02-24 Understand how well your application retains organizations with the new organization retention report. Clerk automatically tracks how many organizations remain active after creation, enabling you to visualize how your organization retention is trending versus industry benchmarks. ### Features - Change the interval to see how your organization cohorts retain over the first 30 days, 8 weeks, and 3 months. - Visualize how your retention is changing over time by comparing the last three or six cohorts. - Set a goal shape to measure how your retention is improving towards industry benchmarks. - View recent cohorts in progress, or toggle off 'show incomplete period' to see only cohorts with complete data. --- ## Require multi-factor authentication (MFA) on mobile - URL: https://clerk.com/changelog/2026-02-23-force-mfa-mobile.md - Date: 2026-02-23 You can now require multi-factor authentication (MFA) across your iOS and Android authentication flows with a single toggle. This applies to both new users during sign-up and existing users when they sign in, ensuring MFA is completed before access is granted. ## What's new Requiring multi-factor authentication (MFA) now works end-to-end in prebuilt authentication flows for iOS and Android. If a session is created in a pending state with a `setup-mfa` task, the SDK automatically routes users to the dedicated MFA setup flow instead of completing sign-in. Users can set up one of your enabled MFA methods, including Authenticator app (TOTP) and SMS verification code. ## Getting started To require MFA in your mobile application: 1. Navigate to [Multi-factor](https://dashboard.clerk.com/~/user-authentication/multi-factor) in the Clerk Dashboard. 2. Enable one or more MFA strategies (Authenticator app or SMS verification code). 3. Turn on **Require multi-factor authentication**. Once enabled, new users are prompted to set up MFA during sign-up, and existing users without MFA are prompted the next time they sign in. To learn more, visit the [setup MFA guide](https://clerk.com/docs/guides/configure/auth-strategies/sign-up-sign-in-options#multi-factor-authentication). --- ## Test enterprise connections with shareable links - URL: https://clerk.com/changelog/2026-02-23-test-enterprise-connections.md - Date: 2026-02-23 ## What's new - **Shareable test URLs** — From any enterprise connection (SAML or OIDC) in the Dashboard, use **Copy Test URL** to generate a one-time link. Share it with your customer or IT team so they can run a sign-in attempt against your connection. - **Test logs** — Results of each test URL run (success or failure and details), so you can get more information for troubleshooting. ## Getting started In the [Clerk Dashboard](https://dashboard.clerk.com), go to **User authentication** → **SSO connections**, open an enterprise connection, and complete the connection setup. Then use **Copy Test URL** to create and copy a test link. Share it with your customer to run a test sign-in; the attempt will appear under **Test logs**. --- ## Clerk Convex integration for Swift and Kotlin - URL: https://clerk.com/changelog/2026-02-20-clerk-convex-mobile-integrations.md - Date: 2026-02-20 These libraries connect Clerk authentication with Convex clients, keeping auth state in sync without requiring custom token handling. For integration and configuration details, refer to the following repositories: - [clerk-convex-swift](https://github.com/clerk/clerk-convex-swift) - [clerk-convex-kotlin](https://github.com/clerk/clerk-convex-kotlin) Each repository includes example apps and setup instructions. --- ## Require multi-factor authentication (MFA) - URL: https://clerk.com/changelog/2026-02-20-require-mfa.md - Date: 2026-02-20 Securing your user base even more just got a lot easier. You can now require multi-factor authentication (MFA) across your entire application with a single toggle. This ensures that every user, whether they are signing up for the first time or returning to an existing account, adds a critical layer of protection before they can access your application. ## What's new The require multi-factor authentication (MFA) setting eliminates the "opt-in" gap. Previously, users had to manually choose to secure their accounts. Now you can make it a requirement for entry. If a user signs-in or signs-up without multi-factor authentication (MFA) enabled, they’ll be guided through the setup flow before proceeding. This works seamlessly with Clerk’s prebuilt components. Users can choose from the available application MFA methods, including Authenticator application (TOTP) and SMS verification code. ## Getting started To require multi-factor authentication (MFA) across your application: 1. Ensure your Clerk SDKs meet the minimum required versions. Refer to the [setup-mfa session task guide](https://clerk.com/docs/reference/components/authentication/task-setup-mfa) for version requirements. 2. Navigate to [Multi-factor](https://dashboard.clerk.com/~/user-authentication/multi-factor) in the Clerk Dashboard 3. Enable one or more MFA strategies (Authenticator application or SMS verification code). 4. Turn on **Require multi-factor authentication** Once enabled, new users will be prompted to set up MFA during sign-up, and existing users without MFA will be prompted the next time they sign-in. To learn more, visit the [setup MFA guide](https://clerk.com/docs/guides/configure/auth-strategies/sign-up-sign-in-options#multi-factor-authentication). --- ## Improved visibility into Stripe account status - URL: https://clerk.com/changelog/2026-02-11-account-detection.md - Date: 2026-02-11 - **Proactive alerts are now available.** A warning icon and banner appear when Stripe reports outstanding account requirements. - **Issues can be resolved directly from the Dashboard.** Clicking the warning banner opens Stripe so you can complete required items. - **Warnings are visible in key billing areas.** They appear in the **Billing** tab and in **Billing settings** under the **Configure** section. ![Warning banner shown in Billing tab](./warning-banner.png) ![Warning icon indicator](./warning-icon.png) - **Early resolution helps prevent payment interruptions** for Clerk Billing. --- ## Share Dashboard Analytics - URL: https://clerk.com/changelog/2026-02-11-export-dashboard-analytics.md - Date: 2026-02-11 Communicating your growth is crucial for building confidence in your product. That's why we've added export capabilities to every chart in the Clerk dashboard, making it easier than ever to share insights with your team, stakeholders, or potential customers. - Export any chart from your dashboard as a high-quality PNG image - Copy charts directly to your clipboard for quick sharing - Export any chart type: line charts, bar charts, and more You can also customize the way your charts look when exported: 1. Set the desired date range and interval in your Clerk dashboard, including whether to show the incomplete period or not 2. Click the share button on any report to view a preview of the export 3. Toggle the y-axis display, show or hide growth rate total, include or exclude churned user data and more 4. All exports maintain your dashboard's light or dark mode theme and application branding --- ## iOS and Android SDKs v1 - URL: https://clerk.com/changelog/2026-02-10-ios-android-sdk-v1.md - Date: 2026-02-10 Clerk's iOS and Android SDKs are now at v1, focused on a better developer experience and a simplified API across both platforms. The biggest change is a unified entry point: all auth methods now live under `.auth` in each SDK, so everything related to authentication is in one place — with simpler, easier-to-use APIs throughout. If you're upgrading from v0, follow the migration guides: [iOS v1 migration guide](/docs/guides/development/upgrading/upgrade-guides/ios-v1) and [Android v1 migration guide](/docs/guides/development/upgrading/upgrade-guides/android-v1). ## What's new in iOS Some highlights: - **Unified auth entry point:** All auth flows live under `clerk.auth`, so sign-in, sign-up, and sign-out share one consistent surface. ```swift var signIn = try await Clerk.shared.auth.signInWithEmailCode( emailAddress: "newuser@clerk.com" ) ``` ```swift struct ContentView: View { @Environment(Clerk.self) private var clerk var body: some View { Button("Send code") { Task { await sendEmailCode() } } } private func sendEmailCode() async { do { var signIn = try await clerk.auth.signInWithEmailCode( emailAddress: "newuser@clerk.com" ) } catch { // Handle error } } } ``` - **Import only what you need:** v1 splits the iOS SDK into `ClerkKit` (core APIs) and `ClerkKitUI` (prebuilt views), so you only import what you use. ```swift import ClerkKit import ClerkKitUI ``` - **Simpler, more flexible configuration:** Configure Clerk once at launch with `Clerk.configure(...)`. ```swift Clerk.configure(publishableKey: "YOUR_PUBLISHABLE_KEY") ``` - **More modern SwiftUI wiring:** Inject `Clerk.shared` directly into the environment instead of the old custom key, and read it with `@Environment(Clerk.self)`. ```swift ContentView() .environment(Clerk.shared) ``` ```swift @Environment(Clerk.self) private var clerk ``` Check out the [iOS docs](/docs/ios/reference/native-mobile/overview) for full details. ## What's new in Android Some highlights: - **Unified auth entry point:** All auth flows live under `Clerk.auth`, so sign-in, sign-up, and sign-out stay in one place. ```kotlin val signIn = Clerk.auth.signInWithOtp { email = "newuser@clerk.com" } ``` ```kotlin @Composable fun SignInView() { val scope = rememberCoroutineScope() Button(onClick = { scope.launch { sendEmailCode() } }) { Text("Send code") } } private suspend fun sendEmailCode() { Clerk.auth.signInWithOtp { email = "newuser@clerk.com" } .onSuccess { signIn -> // Continue the flow } .onFailure { error -> // Handle error } } ``` - **Clearer auth state naming:** `signIn` and `signUp` state are now `currentSignIn` and `currentSignUp` to avoid method-name confusion. - **Builder pattern for auth methods:** Auth flows adopt builders for cleaner call sites and more explicit parameter grouping, including MFA steps. Check out the [Android docs](/docs/android/reference/native-mobile/overview) for full details. ## Get started v1 makes it easier to build consistent native experiences across iOS and Android. Follow the platform quickstarts to get set up: [iOS quickstart](/docs/quickstarts/ios) and [Android quickstart](/docs/quickstarts/android). If you're upgrading, use the migration guides above to update imports, config, and auth flow calls. Need help? Reach us on [Clerk Discord](https://clerk.com/discord) or explore the source on GitHub: [clerk-ios](https://github.com/clerk/clerk-ios) and [clerk-android](https://github.com/clerk/clerk-android). --- ## New plans, more value - URL: https://clerk.com/changelog/2026-02-05-new-plans-more-value.md - Date: 2026-02-05 Today, we're excited to share our first major pricing update since November 2023. As our products have evolved over the years, we've heard that our pricing no longer felt quite right. This update reflects the feedback, frustrations, and suggestions we've heard from many of you. Our goal is simple: **make authentication essentials more affordable, while focusing our fees on differentiated features and areas with real operational cost.** Let's dive into some specifics. ### The vast majority of customers will pay less, or receive more features for the same price We're improving affordability across nearly every dimension, so both our smallest and largest customers are set to benefit: - **50,000 Monthly Retained Users are now free in every application**, up from 10,000 - **Unlimited applications are now included in every plan**, eliminating the need to upgrade each application individually - **The Enhanced Authentication Add-on has been eliminated**, and most of its features are now included in our Pro Plan (starting from $20/mo). This includes: - Multi-factor authentication - Satellite domains - Simultaneous sessions - **5 impersonations per month are now free**, to allow trying the feature before purchasing the Enhanced Administration Add-on - **Automatic volume discounts** will now be applied as usage grows - **Annual billing is now available** for an additional discount Alongside these changes, we've also reduced the complexity of our plans to ensure you're never surprised by which features are included or omitted. ### Some customers will see price increases We're making three changes that will increase costs for a minority of our customers. Those changes are: 1. **Using four or more Clerk Dashboard seats now requires a Business Plan (starting from $250/mo).** We love building a dashboard that goes beyond authentication and helps teams operate and scale their business. This change will allow us to continue improving the dashboard for more teammates in more roles. 2. **Enterprise Connections (SAML and OIDC) are now metered within the Pro Plan, instead of unlimited under the former Enhanced Authentication Add-on.** Under the new pricing, applications with three or more Enterprise Connections will see increased costs. These costs will support continued investment in Enterprise Connections, including our upcoming support for SCIM and self-serve configuration. 3. **Access to SOC 2 and HIPAA artifacts now requires a Business Plan.** We gate access to audit artifacts because they involve ongoing third-party audits and real operational overhead. Importantly, the underlying security controls are the same for all customers, regardless of plan. ### Rollout Our new plans are available starting today, and the full details are available on our [pricing page](https://clerk.com/pricing). We encourage customers to switch as soon as possible. If paid customers do not select a new plan before their billing period beginning in April, Clerk will automatically migrate them to a new plan. We hope to avoid automatic migrations, though, and will be sending multiple reminders before they occur. If you have any questions or concerns, or if your business requires a custom plan, please don't hesitate to [contact us](https://clerk.com/contact). ### Thank you We love making our pricing even more competitive, and it's only possible because tens of thousands of customers like you have entrusted Clerk as their authentication provider. We look forward to the years ahead as we'll continue to innovate not just on authentication, but all of customer management. --- ## User activity report - URL: https://clerk.com/changelog/2026-01-30-user-activity.md - Date: 2026-01-30 See how many days a user logs in to your app over the course of a year to get an at-a-glance visualization of their activity within your product. - **Spot engagement patterns** - See which users are active daily versus those who haven't returned in weeks. - **Navigate by year** - Use the year selector to view activity from any year since the user was created. - **Hover for details** - Tooltips on each day show the exact date and whether the user was active. To view the activity graph, open any user's profile page from the [Users](https://dashboard.clerk.com/~/users) list in your Clerk Dashboard. Keep an eye out for continued improvements and higher data fidelity in this report. --- ## Clerk Skills for AI Agents - URL: https://clerk.com/changelog/2026-01-29-clerk-skills.md - Date: 2026-01-29 We're launching Clerk Skills, installable packages built on the [Agent Skills](https://agentskills.io) specification that give AI coding agents specialized knowledge about Clerk authentication. Once installed, your agent can help you add auth to any framework, build custom sign-in flows, sync users to your database, and more. Install all skills with a single command: ```bash npx skills add clerk/skills ``` Once installed, you can ask your AI assistant questions like: - "Add Clerk auth to my Next.js app" - "Build a custom sign-in form with email and password" - "Set up organizations for my B2B SaaS" - "Add Playwright tests for authentication" - "Sync Clerk users to my Prisma database" Skills work with most agents including Claude Code, Cursor, Windsurf, GitHub Copilot, Codex, and Gemini CLI. To see all available skills and installation options, head to the [Skills documentation](/docs/guides/ai/skills). --- ## Custom plans and prices - URL: https://clerk.com/changelog/2026-01-26-billing-custom-plans-and-prices.md - Date: 2026-01-26 You can now transition active subscriptions between different billing plans right from the dashboard or backend API. Switch a customer's subscription from one price to another while keeping their billing smooth — whether you're upgrading them from free to paid or moving between paid tiers. ## What's new This subscription item management feature lets you easily change a customer's active subscription item to a new pricing plan. It makes essential Billing workflows simple: - **Promotional offers** - Apply special pricing to existing subscribers - **Tiered upgrades and downgrades** - Move customers between different paid plans based on their needs or usage - **Plan migrations** - Transition customers to new pricing structures as your product evolves When you create a price transition, we handle all the timing and billing logic for you: **Free-to-paid transitions** depend on the customer's current subscription state: - **New to paid**: When transitioning a customer from free to a paid plan with no other active subscription, the paid plan activates immediately and the customer is charged right away - Example: Moving a customer on the free plan to Pro ($50/month). Pro activates immediately, customer charged $50. - **Free to paid with active subscription**: When transitioning from free to paid but the customer has another active subscription, the paid plan is scheduled as *upcoming* to avoid billing conflicts - Example: Customer on free plan with an active Pro subscription through March 20. Switching the free plan to Enterprise sets Enterprise as *upcoming* until March 20. **Paid-to-paid transitions** schedule the new plan to avoid billing overlap: - **Switching between paid plans**: When a customer already has an active paid subscription, the new plan is scheduled to start when their current billing period ends - Example: Upgrading a customer from Basic ($20/month, paid through Feb 15) to Enterprise ($35/month) on Jan 15 - Basic remains active through Feb 15 (already paid for) - Enterprise becomes *upcoming* and activates Feb 15 (customer charged then) - Prevents double-billing the customer for overlapping periods **Paid-to-free transitions** schedule the free plan as *upcoming*, allowing the customer's current paid subscription to run through its paid period before automatically activating the free plan. ## Getting started To change the price or plan of your subscriptions: 1. Navigate to [Subscriptions](https://dashboard.clerk.com/~/billing/subscriptions) in the Clerk dashboard 2. Choose the subscription item you want to update 3. Click the three dots menu 4. Update the price or plan as needed ![Custom plans and prices](./custom-plans-prices.png) ## Create custom prices If you can't find a price that satisfies your needs from the existing options, you can create a new price by clicking "Create new price" and use it right away for your subscription transitions. ## Paid plans without charging We're currently working on a feature that will allow you to assign paid plans to customers without billing them. This capability will be valuable for several scenarios: - **Gifting subscriptions** - Give users complimentary access to premium features - **Internal team access** - Let your team use paid features in production without extra billing - **Migration help** - Support customers who've already paid on other platforms --- ## Automatically create first organization with smart naming - URL: https://clerk.com/changelog/2026-01-22-default-organization-naming.md - Date: 2026-01-22 You can now automatically create a user's first organization with intelligent name suggestions. Clerk will detect the organization name from the user's email domain (e.g., `alex@clerk.com` → "Clerk") or personalize it based on member details, eliminating the manual setup step for first-time users. This feature works best for applications with required organization membership where the creation step adds unnecessary friction. ## What's new **Create first organization automatically** removes friction during onboarding by automatically creating a user's first organization. When enabled, users are added to their first organization without seeing the creation flow. **Default naming rules** intelligently suggest the first organization's name using: - Email domain detection - Automatically populates the organization name, slug, and logo from the user's email domain (e.g., `alex@stripe.com` → "Stripe" with logo) - Member personalization - Creates personalized names using variables like `user.first_name`, `user.last_name`, `user.full_name`, or `user.username` (e.g., `{{user.first_name}}'s organization` → "Alex's organization") - Fallback name - Provides a default when other rules don't apply Default naming rules are required to enable automatic organization creation. You can disable individual rules to skip them in the detection order. ## Getting started Visit the [Organizations configuration documentation](https://clerk.com/docs/guides/organizations/configure#default-naming-rules) to learn how to enable automatic organization creation and configure default naming rules. Configure these settings in the Clerk Dashboard under [Organizations Settings](https://dashboard.clerk.com/~/organizations-settings). --- ## User retention report - URL: https://clerk.com/changelog/2026-01-21-user-retention.md - Date: 2026-01-21 Understand how sticky your product is with the new user retention report. Clerk automatically tracks how often users are coming back to your application after sign up, enabling you to visualize how your retention is trending versus industry benchmarks. ### Features - Change the interval to see how your user cohorts retain over the first 30 days, 8 weeks, and 3 months. - Visualize how your retention is changing over time by comparing the last three or six cohorts. - Set a goal shape to measure how your retention is improving towards industry benchmarks. - View recent cohorts in progress, or toggle off 'show incomplete period' to see only cohorts with complete data. --- ## Clerk MCP Server - URL: https://clerk.com/changelog/2026-01-20-clerk-mcp-server.md - Date: 2026-01-20 We're launching the Clerk MCP server in public beta — a [Model Context Protocol](https://modelcontextprotocol.io/introduction) server that helps AI coding assistants like Claude, Cursor, and GitHub Copilot provide accurate SDK snippets and implementation patterns when working with Clerk. Your agent can use Clerk's MCP server to pull up-to-date implementation guidance and best practices. Once connected, you can ask your AI assistant questions like: - "How do I implement authentication hooks in Next.js?" - "Set up a B2B SaaS with organizations and role-based permissions" - "Create a waitlist flow for my app" - "Protect API routes with Clerk" To see complete setup instructions and learn more about the Clerk MCP server, head to the [documentation](/docs/guides/ai/mcp/clerk-mcp-server). We'd love to get your feedback as you try out the Clerk MCP server. Reach out through [our feedback portal](https://feedback.clerk.com) or join the discussion in our [Discord community](https://clerk.com/discord). --- ## Sign-in with Solana - URL: https://clerk.com/changelog/2026-01-13.md - Date: 2026-01-13 We're excited to announce the launch of our new [Solana](https://solana.com/solana-wallets) authentication strategy, which makes it easy for developers to integrate Solana wallet sign-ins into their applications. ## Getting Started - Enable Solana as a Web3 authentication strategy in the [Clerk Dashboard](https://dashboard.clerk.com/~/user-authentication/web3) - Use the `` and `` components to allow users to authenticate with their Solana wallets - See our [Solana authentication documentation](/docs/guides/configure/auth-strategies/web3/solana) for detailed setup instructions and code examples --- ## Control available roles per organization with Role Sets - URL: https://clerk.com/changelog/2026-01-12-organization-role-sets.md - Date: 2026-01-12 You can now control which roles are available to each organization using Role Sets. Assign different Role Sets to different organizations based on subscription tiers, customer cohorts, or business needs — if a role isn't in an organization's Role Set, members can't be assigned that role. ## What's new Role Sets allow you to define separate collections of roles and permissions across organizations. This enables advanced use cases like: - Creating different role hierarchies for different teams or departments - Isolating permissions across multiple products or services within one organization - Building flexible multi-tenant architectures with customizable access patterns - Supporting complex organizational structures with varying authorization needs Use Role Sets when different Organizations need different available Roles. This works well for: - **Different pricing tiers** - Your Free plan offers only `admin` and `member`, Pro adds `moderator` and `analyst`, and Enterprise adds `security_admin` and `compliance_officer`. - **Different customer cohorts** - Small practices get `physician` and `nurse`, while large hospitals also get `department_head` and `specialist`. All cohorts share `admin` and `member`, but get additional Roles specific to their size. When you modify a Role Set, the changes are automatically applied to all Organizations using it. This makes it easy to roll out new Roles across multiple Organizations at once. Each instance gets one role set by default at no additional cost. Additional role sets require the [Enhanced Organizations add-on](/pricing#organizations). ## Getting started Visit the [Role Sets documentation](https://clerk.com/docs/guides/organizations/control-access/role-sets) to learn how to create and manage Role Sets for your organizations. You can also manage Role Sets through the Clerk Dashboard or programmatically via the Backend API. Visit the [Role Sets documentation](https://clerk.com/docs/guides/organizations/control-access/role-sets) for detailed guides, or see the [Backend API reference](https://clerk.com/docs/reference/backend-api) for API details. --- ## Member role can no longer manage secret keys within the Clerk Dashboard - URL: https://clerk.com/changelog/2026-01-09-secret-key-management-restricted-to-admins.md - Date: 2026-01-09 In an ongoing effort to improve the security of your Clerk instances, starting today, only users of your Clerk workspace who are *Admin* roles will be able to manage secret keys on the Instance / API Keys page. The *Member* role can no longer reveal, create, or delete secret keys. *Member* role can still list all Secret keys and view non-sensitive details such as name, creation date and last-used date. --- ## JWT format support for OAuth access tokens - URL: https://clerk.com/changelog/2026-01-08-jwt-oauth-access-tokens.md - Date: 2026-01-08 JWTs are now the default for newly created applications, while existing applications continue using opaque tokens unless changed. ![JWT format support for OAuth access tokens](./jwt-toggle.png) ## Why JWT? JWT access tokens offer several advantages: - **Networkless verification** — JWTs can be verified locally using your instance's public key, without making a network request to Clerk's servers - **Self-contained** — All necessary information (user ID, scopes, expiration) is embedded in the token itself - **Better compatibility** — Many third-party tools and libraries expect JWT tokens ## When to use opaque tokens Opaque tokens remain valuable for security-sensitive scenarios: - **Instant revocation** — Opaque tokens can be invalidated immediately, while JWTs remain valid until they expire ## How to configure To change your OAuth access token format: 1. Navigate to [OAuth applications](https://dashboard.clerk.com/~/oauth-applications) in the Clerk Dashboard 2. Select the **Settings** tab 3. Under **Access token format**, select **JWT access tokens** or **Opaque access tokens** 4. Save your changes Clerk's SDKs automatically handle verification for both token formats — no code changes are required when switching between them. For manual verification of JWT tokens outside of Clerk's SDKs, use the same approach as [session token verification](/docs/guides/sessions/manual-jwt-verification) with your instance's public key. For more details on the differences between token formats, see the [token formats documentation](/docs/guides/development/machine-auth/token-formats). --- ## Hide Incomplete Periods - URL: https://clerk.com/changelog/2026-01-06-hide-incomplete-periods.md - Date: 2026-01-06 By default, your most recent time period (today, this week, or this month, depending on your selected interval) is shown even if the data is incomplete. Uncheck "Show incomplete period" to show only past complete periods. This filtering applies to all analytics reports on the Overview page. ![Show incomplete period - default view with checkbox checked](./show-incomplete.png) --- ## Manually force password resets - URL: https://clerk.com/changelog/2025-12-19-force-password-reset.md - Date: 2025-12-19 ![Reset password session task](./image.png) As an initial action, we’re introducing the ability to set passwords as compromised, with the option to immediately sign out all active sessions for the affected user. This triggers a reset password session task, requiring the user to set a new password on their next sign-in. Additional actions will be introduced in the future. ## How to force password resets for an entire instance If you need to protect all users at once—such as during a suspected platform-wide security incident—you can require a password reset for every account in your instance. This is currently done by setting all existing passwords as compromised, which will trigger a reset password session task for affected users. Each user will be required to set a new password the next time they sign-in. 1. Navigate to **Configure > Instance Settings > Security Measures** in your Clerk Dashboard. 2. Select **Set all passwords as compromised**. ## How to force a password reset for a specific user When only a single account is at risk, you can require a password reset for that user alone. This action triggers a reset password session task for the user, ensuring they must change their password before continuing. 1. Navigate to the **User Details** page for the user. 2. In the **Password** section, under the actions dropdown, select **Set password as compromised**. ## Getting started All new instances have password reset session task enabled by default. Existing instances must manually opt-in via the **[Reset password session task update](https://dashboard.clerk.com/~/updates)** on the **Updates** page. If you’re using custom authentication flows, make sure your application handles: - [The **Reset password session task**](/docs/js-frontend/reference/components/authentication/task-reset-password) - [The associated **password compromised error**](/docs/guides/development/custom-flows/error-handling#password-compromised) --- ## Organization filters - URL: https://clerk.com/changelog/2025-12-17-organization-filters.md - Date: 2025-12-17 You can now filter organizations in the Clerk Dashboard by name, slug, or creation date. These filters work alongside the existing search functionality to help you locate specific organizations faster. Whether you need to find organizations by their display name, unique slug identifier, or when they were created, the new filter menu provides quick access to refine your organization list. To use the filters, click the filter icon next to the search bar on the [Organizations page](https://dashboard.clerk.com/~/organizations) in your application instance. --- ## Organization Reports - URL: https://clerk.com/changelog/2025-12-15-organization-reports.md - Date: 2025-12-15 ![Organization Reports](./organization-reports.png) We're excited to announce new organization reports in the Clerk Dashboard. You can now monitor how many organizations are being created by day, week, and month. You can also track your total organization count at a glance. These new reports provide quick insights into organization creation patterns, making it easier to monitor growth and identify trends in your organization adoption. --- ## API Keys Public Beta - URL: https://clerk.com/changelog/2025-12-11-api-keys-public-beta.md - Date: 2025-12-11 API keys are now available for authorization, with management built-in to the prebuilt components. This feature is part of the [machine authentication](/docs/machine-auth/overview) suite. ## Zero-Code UI Components When you enable API keys in the [Clerk Dashboard](https://dashboard.clerk.com/~/platform/api-keys), an **API Keys** tab appears in your `` and `` components. Users can then create, view, and revoke their API keys. You can also use the [standalone `` component](/docs/reference/components/api-keys) anywhere in your application: ```tsx import { APIKeys } from '@clerk/nextjs' export default function Page() { return } ``` ## Backend SDK Integration You can also create and manage API keys programmatically using the [Backend SDK](/docs/reference/backend/api-keys/create), with control over scopes, claims, and expiration: ```ts const apiKey = await clerkClient.apiKeys.create({ name: 'Production API Key', subject: 'user_xxx', // or 'org_xxx' for organization keys scopes: ['read:data', 'write:data'], secondsUntilExpiration: 86400, // optional: expires in 24 hours }) // Store apiKey.secret immediately - it's only shown once! ``` ## Verify API Keys in Your Routes Use the `auth()` helper to verify API keys in your backend. An example of this using Next.js is shown below: ```tsx import { auth } from '@clerk/nextjs/server' import { NextResponse } from 'next/server' export async function GET() { const { isAuthenticated, userId, scopes } = await auth({ acceptsToken: 'api_key', }) if (!isAuthenticated) { return NextResponse.json({ error: 'Unauthorized' }, { status: 401 }) } // Check scopes for fine-grained access control if (!scopes?.includes('read:data')) { return NextResponse.json({ error: 'Missing required scope' }, { status: 403 }) } return NextResponse.json({ userId }) } ``` ## Key Features - **User & Organization scoped** — Keys maintain identity context, always tied to a user or organization - **Instant revocation** — API keys use [opaque tokens](/glossary#opaque-token) (not JWTs), enabling immediate invalidation - **Scopes** — Define exactly what each key can access - **Custom claims** — Store additional metadata on keys (backend SDK only) - **Optional expiration** — Set TTL or keep keys long-lived ## Pricing API keys are **free to use during the beta period**. After general availability, they'll move to a simple usage-based pricing model: - `$0.001` per key creation - `$0.00001` per key verification Billing isn't live yet — we'll provide at least **30 days' notice** before billing begins. We'll also provide usage stats and monitoring in the Dashboard before then, so you'll have complete visibility over your usage and costs. ## Get Started Today Ready to let your users create API keys? Check out these resources: - [API keys guide](/docs/guides/development/machine-auth/api-keys) — Complete walkthrough of enabling and using API keys - [Backend SDK reference](/docs/reference/backend/api-keys/list) — Full API for creating, listing, verifying, and revoking keys - [Dashboard](https://dashboard.clerk.com/~/api-keys) — Enable API keys for your application - [Tutorial](/blog/add-api-key-support-to-your-saas-with-clerk) — Build a SaaS application with Clerk and API keys, step by step We'd love to hear your feedback as you try out API keys. Your input during the beta period will help us refine the feature. Have questions or suggestions? Reach out through [our feedback portal](https://feedback.clerk.com) or join the discussion in our [Discord community](https://clerk.com/discord). --- ## Prebuilt Android Components - URL: https://clerk.com/changelog/2025-12-10-android-ui-components.md - Date: 2025-12-10 We're excited to introduce prebuilt UI views that make it incredibly easy to add authentication flows to your Android applications. These new Android views provide complete authentication experiences out of the box, eliminating the need to build custom sign-in and user management interfaces from scratch. With just a few lines of code, you can now add authentication and user management to your Android app that matches Material Design standards and includes advanced features like multi-factor authentication, social sign-in, and comprehensive user profile management. ## AuthView - Complete Authentication Flow The `AuthView` provides a comprehensive authentication experience supporting both sign-in and sign-up flows, multi-factor authentication, password reset, account recovery and more. ![The AuthView renders a comprehensive authentication interface that handles both user sign-in and sign-up flows.](./android-auth-view.png) ```kotlin {{ filename: 'HomeView.kt' }} import androidx.compose.runtime.Composable import androidx.compose.ui.Modifier import androidx.compose.ui.Alignment import androidx.compose.ui.layout.fillMaxSize import androidx.lifecycle.compose.collectAsStateWithLifecycle import com.clerk.api.Clerk import com.clerk.ui.auth.AuthView import com.clerk.ui.userbutton.UserButton @Composable fun HomeView() { val user by Clerk.userFlow.collectAsStateWithLifecycle() Box( modifier = Modifier.fillMaxSize(), contentAlignment = Alignment.Center, ) { if (user != null) { UserButton() } else { AuthView() } } } ``` ## UserButton - Profile Access Made Simple The `UserButton` displays the current user's profile image in a circular button and opens the full user profile when tapped. ![The UserButton is a circular button that displays the signed-in user's profile image.](./android-user-button.png) ```kotlin {{ filename: 'HomeView.kt' }} import androidx.compose.material3.TopAppBar import com.clerk.ui.userbutton.UserButton TopAppBar(title = {}, actions = { UserButton() }) ``` ## UserProfileView - Comprehensive Account Management The `UserProfileView` provides a complete interface for users to manage their accounts, including personal information, security settings, account switching, and sign-out functionality. ![The UserProfileView renders a comprehensive user profile interface that displays user information and provides account management options.](./android-user-profile-view-light.png) ```kotlin {{ filename: 'ProfileView.kt' }} import androidx.compose.runtime.Composable import androidx.compose.ui.Modifier import androidx.compose.ui.Alignment import androidx.compose.ui.layout.fillMaxSize import androidx.lifecycle.compose.collectAsStateWithLifecycle import com.clerk.api.Clerk import com.clerk.ui.userprofile.UserProfileView @Composable fun ProfileView() { val user by Clerk.userFlow.collectAsStateWithLifecycle() Box( modifier = Modifier.fillMaxSize(), contentAlignment = Alignment.Center, ) { if (user != null) { UserProfileView() } } } ``` ## ClerkTheme - Customization The new theming system allows you to customize the appearance of all Clerk views to match your app's design. ```swift {{ filename: 'MyApplication.kt' }} import android.app.Application import androidx.compose.ui.graphics.Color import com.clerk.ui.theme.ClerkTheme import com.clerk.ui.theme.ClerkColors import com.clerk.api.Clerk class MyApplication : Application() { override fun onCreate() { super.onCreate() Clerk.initialize( this, key, options = ClerkConfigurationOptions(enableDebugMode = true), theme = ClerkTheme(colors = ClerkColors(primary = Color.Red)), ) } } ``` ### Light and Dark Mode Support All Clerk Android views automatically support both light and dark mode appearance, adapting seamlessly to the user's system preferences. ![Light Mode](./android-user-profile-view-light.png) ![Dark Mode](./android-user-profile-view-dark.png) ### Breaking changes The Clerk Android SDK has been split into two packages: - `com.clerk:clerk-api` - The core Clerk SDK for authentication and user management. (This was previously called `com.clerk:clerk-android`) - `com.clerk:clerk-ui` - The Clerk UI components for authentication and user management. The `com.clerk:clerk-ui` pulls the `com.clerk:clerk-api` package as a dependency, so you only need to add the `com.clerk:clerk-ui` package to your dependencies if you're using the Clerk UI components. ## Getting Started To get started follow the [Quickstart Guide](/docs/android/getting-started/quickstart) and see the views docs: - [AuthView](/docs/android/reference/views/authentication/auth-view) - [UserButton](/docs/android/reference/views/user/user-button) - [UserProfileView](/docs/android/reference/views/user/user-profile-view) - [ClerkTheme](/docs/android/guides/customizing-clerk/clerk-theme) ## Feedback We're excited to see what you build with these new views! Share your feedback and join the conversation in our [Discord community](https://clerk.com/discord). --- ## Debug logs for enterprise connections - URL: https://clerk.com/changelog/2025-12-08-debug-logs-for-enterprise-connections.md - Date: 2025-12-08 When configuring SAML or OIDC connections, you can now view detailed error logs directly in the Dashboard. Each error log includes the error code, message, and actionable guidance on how to resolve the issue. For more information on common SSO errors, check out our [documentation](/docs/guides/organizations/add-members/sso#common-sso-setup-errors). --- ## Vercel SSO Provider - URL: https://clerk.com/changelog/2025-12-04-vercel-sso-provider.md - Date: 2025-12-04 [Vercel](https://vercel.com/) is now available as a built-in SSO provider, allowing users to sign in to your application using their Vercel accounts. Visit the [setup guide](/docs/guides/configure/auth-strategies/social-connections/vercel) to configure Sign in with Vercel for your application. --- ## Enable organizations from your app during development - URL: https://clerk.com/changelog/2025-11-24-enable-organizations-prompt.md - Date: 2025-11-24 ![Prompt to enable organizations feature in development](./prompt.png) When you first use organization components or hooks in a development instance, Clerk will automatically prompt you to enable Organizations. The prompt includes a toggle to allow personal accounts and a link to the Dashboard for advanced configuration. This reduces friction when building B2B applications — no more context switching between your code editor and the Dashboard just to enable a feature. --- ## Manage organization roles and permissions through Clerk's API - URL: https://clerk.com/changelog/2025-11-24-organization-roles-and-permission-bapi-management.md - Date: 2025-11-24 You can now completely manage permissions and roles through the Clerk Backend API. Build sophisticated access control systems tailored to your application's needs — whether you're syncing roles from external systems, automating permission assignments, or creating custom admin interfaces. ## What's new The following endpoints are now available on Clerk's backend API: **Organization Permissions** | Endpoint | Description | | ----------------------------------------------------- | -------------------------------------------------- | | `GET /v1/organization_permissions` | List all permissions with pagination and filtering | | `POST /v1/organization_permissions` | Create a new permission | | `GET /v1/organization_permissions/{permission_id}` | Retrieve a specific permission | | `PATCH /v1/organization_permissions/{permission_id}` | Update a permission | | `DELETE /v1/organization_permissions/{permission_id}` | Delete a permission | **Organization Roles** | Endpoint | Description | | ----------------------------------------- | ------------------------ | | `GET /v1/organization_roles` | List all roles | | `POST /v1/organization_roles` | Create a new role | | `GET /v1/organization_roles/{role_id}` | Retrieve a specific role | | `PATCH /v1/organization_roles/{role_id}` | Update a role | | `DELETE /v1/organization_roles/{role_id}` | Delete a role | **Role Permissions** | Endpoint | Description | | --------------------------------------------------------------------- | ------------------------------- | | `POST /v1/organization_roles/{role_id}/permissions/{permission_id}` | Assign a permission to a role | | `DELETE /v1/organization_roles/{role_id}/permissions/{permission_id}` | Remove a permission from a role | ## Getting started Visit the [API reference](https://clerk.com/docs/reference/backend-api) for detailed documentation on request parameters and response formats. --- ## Use existing Stripe account for Clerk Billing - URL: https://clerk.com/changelog/2025-11-14-clerk-billing-existing-stripe-accounts.md - Date: 2025-11-14 You can now link and use an existing Stripe account for Clerk Billing, as long as the account is not associated with another platform. Head to your [billing settings](https://dashboard.clerk.com/~/billing/settings) in the Clerk Dashboard to get started today. --- ## Introducing Client Trust: Clerk’s free credential stuffing killer - URL: https://clerk.com/changelog/2025-11-14-client-trust-credential-stuffing-killer.md - Date: 2025-11-14 > \[!NOTE] > Client Trust is now called **Device Trust**. This post is kept as originally published; see the [Device Trust guide](/docs/guides/secure/device-trust) for current documentation. Last Friday, Troy Hunt shared that [625 million never-before-leaked passwords](https://www.troyhunt.com/2-billion-email-addresses-were-exposed-and-we-indexed-them-all-in-have-i-been-pwned/) had been added to Have I Been Pwned, the password leak detection service. The update brought relief to our team at Clerk, which had been fighting [credential stuffing attacks](/glossary/credential-stuffing) for the two weeks prior. Attackers were attempting to test millions of stolen passwords in quick bursts, with seemingly endless rotating IPs and TLS fingerprints to slip past rate limiters. While we were able to mitigate the vast majority of the attack, leaks of this scale mean that even 99.9% effectiveness isn’t enough. So we decided to kill credential stuffing for good, with a mechanism we’re calling Client Trust. ## Introducing Client Trust **Client Trust** is Clerk’s new defense against credential stuffing. It works by treating every new device as untrusted until the user has signed in on it. ![Client Trust Flow](./ClientTrustFlow.png) Here’s what that means in practice: 1. If a user enters a **valid password** 2. and **hasn’t enabled two-factor authentication** 3. and is signing in from a **new client (device)** Then Clerk will **automatically require a second factor,** with either a one-time passcode or a magic link, depending on the application’s settings. That’s it. No extra configuration and no guesswork. Just automatic protection from day one. ## Security that adapts to reality We know that developers don’t want to choose between user experience and security. Client Trust is designed to make that trade-off obsolete. It’s invisible when it should be, and decisive when it must be. No more leaked-password panics. No more hoping users turned on 2FA. With Client Trust, your users are protected even when their password is included in a 0-day credential leak. ## Free for everyone Client Trust is included in all Clerk plans, and automatically enabled for new applications. Existing applications must enable the update manually from the [Updates page of the dashboard](https://dashboard.clerk.com/~/updates). For most customers, it’s available as one-click update. --- ## Update billing plan prices - URL: https://clerk.com/changelog/2025-11-13-billing-plan-price-updates.md - Date: 2025-11-13 ## What changed? Previously, when a billing plan had active paid subscriptions, the price fields in the dashboard were disabled and couldn't be modified. This was a protective measure to prevent accidental changes that could affect existing subscribers. With this update, you now have full control over your plan pricing, regardless of subscription status. ## How pricing updates work When you update the price of a plan with active subscriptions: - **Existing subscriptions** continue at their current price - **New subscriptions** use the updated pricing immediately We're working on additional functionality that will give you even more control over pricing updates. In a future release, you'll be able to automatically transition existing subscriptions to updated pricing at their next billing date. ## How to update plan prices To update pricing for an active plan: 1. Navigate to [Subscription plans](https://dashboard.clerk.com/~/billing/plans) in your Clerk dashboard 2. Select the plan you want to modify 3. Update the price fields 4. Save your changes --- ## Native Sign in with Apple for Expo - URL: https://clerk.com/changelog/2025-11-13-native-sign-in-with-apple-expo.md - Date: 2025-11-13 Clerk's Expo SDK now includes native Sign in with Apple support, allowing iOS users to authenticate using their Apple ID directly within your Expo applications. This integration provides a streamlined, privacy-focused authentication method that meets Apple's requirements for apps offering third-party sign-in options. ## Native integration benefits Unlike web-based OAuth flows, the native Sign in with Apple implementation offers: - **Faster authentication** - No browser redirects or context switching - **Better user experience** - Native iOS UI that users recognize and trust - **Privacy features** - Support for Apple's Hide My Email functionality - **App Store compliance** - Meets Apple's guidelines for apps with social login ## Getting started To enable Sign in with Apple in your Expo app, configure the OAuth provider in your Clerk Dashboard and add the authentication strategy to your sign-in flow. The SDK handles the native integration automatically on iOS devices, falling back to web-based flows on other platforms For detailed setup instructions and implementation guidance, check out the [Expo OAuth documentation](/docs/references/expo/overview) or the [Integration Guide](/docs/expo/guides/configure/auth-strategies/sign-in-with-apple) --- ## PKCE support for custom OAuth providers - URL: https://clerk.com/changelog/2025-11-12-pkce-support-custom-oauth.md - Date: 2025-11-12 ![PKCE toggle in custom OAuth provider settings](./pkce-toggle.png) You can now enable PKCE (Proof Key for Code Exchange) when configuring custom OIDC providers and custom social connections. This enhancement provides better security for applications that cannot securely store client secrets. ## What is PKCE? PKCE is a security extension to the OAuth 2.0 Authorization Code flow. It was originally designed for public clients like mobile and native applications, but is now recommended for all OAuth 2.0 clients as a best practice. Instead of relying on a static client secret, PKCE creates a cryptographically random secret for each authorization request. This means even if an authorization code is intercepted, it cannot be exchanged for tokens without the original secret. ## When to use PKCE Enable PKCE for: - **Native and mobile apps** - These applications cannot securely store client secrets since their code can be reverse-engineered - **Single-page applications (SPAs)** - Modern best practice recommends PKCE for browser-based apps - **Any public client** - Applications where the source code is accessible to end users ## How to enable To enable PKCE for your custom OAuth provider: 1. Navigate to [SSO connections](https://dashboard.clerk.com/~/user-authentication/sso-connections) in your Clerk Dashboard 2. Select your custom OIDC provider or custom social connection 3. Enable the **Use PKCE** toggle in the Connection tab 4. Save your changes Once enabled, Clerk will automatically use the Authorization Code with PKCE flow for authentication with that provider. --- ## API Version 2025-11-10 - URL: https://clerk.com/changelog/2025-11-10-billing-new-api-version.md - Date: 2025-11-10 ### What’s New #### Billing API Redesign - Introduces a new `/billing` path to replace the legacy `/commerce` endpoints for all billing-related functionality. - Billing amounts are now represented using structured **Fee objects** instead of top-level fields. - More details: [Guide to Upgrading Your API Version](https://clerk.com/docs/guides/development/upgrading/upgrade-guides/2025-11-10) ### Overview of Breaking Changes More details can be found in the upgrade guide linked above. | Area | Description | Migration Notes | | --------------- | --------------------------------------------------------- | ---------------------------------------------------------------------------- | | Field Rename | `payment_source` → `payment_method` | Update all integrations and payload references to use `payment_method`. | | Payload Change | Removed top-level `amounts` fields in the `plans` payload | All amount-related info is now structured via associated **Fee** objects. | | Endpoint Change | `/commerce/*` endpoints have been renamed | Use `/billing` endpoints instead. `/commerce` will be removed **over time**. | > \[!NOTE] > We strongly recommend upgrading to version `2025-11-10` as soon as possible to ensure new billing features work as expected. > To see which SDK versions support it, [click here](https://clerk.com/docs/guides/development/upgrading/versioning#2025-11-10). --- ## Filter growth charts by churned users and organizations - URL: https://clerk.com/changelog/2025-11-07-overview-analytics-filter-by-growth-or-churn.md - Date: 2025-11-07 Hovering or selecting the positive segment will now show you only the active users or organizations for that period as well. By further combining the New, Retained, and Reactivated filters with the positive or negative segments, you can isolate growth or churn trends and see exactly who is using - or not using - your application. Head to the [Overview page](https://dashboard.clerk.com/~) of your production instance to begin exploring your user base's activity. --- ## Command menu - URL: https://clerk.com/changelog/2025-11-06-command-menu.md - Date: 2025-11-06 The command menu is now live in the Clerk Dashboard. Navigate anywhere with just a few keystrokes, whether you're jumping between workspaces, searching our docs, or finding a specific setting you've never configured before. ## Contextual and AI-powered As your dashboard grows with more workspaces, applications, and settings, finding what you need shouldn't get harder. The command menu unifies your entire dashboard: workspaces, applications, instances, documentation, and settings pages, all in one place. Know the name of the workspace you want to jump to? Search for it. Don't remember how to use one of our hooks? Search our docs and jump in. When you don't know the exact name or where something lives, AI steps in. The command menu understands what you're looking for, even when you describe it in plain language. Don't know where SMS MFA settings live? Type "enable SMS MFA" and it takes you there. Need to change your domain but can't remember if there's even a domains page? Just describe what you need, and the command menu finds it. It uses your dashboard context to understand what you're trying to do and takes you there. ## Get started Open the command menu with `⌘+K` (Mac) or `Ctrl+K` (Windows/Linux) inside any application in the [Clerk Dashboard](https://dashboard.clerk.com). --- ## Start free trials without payment methods - URL: https://clerk.com/changelog/2025-10-30-start-free-trials-without-payment-methods.md - Date: 2025-10-30 Previously, all free trials required a payment method upfront. Now there's a simple toggle in your billing settings that lets you decide what works best for your business. ## Remove Friction, Keep Control By disabling the payment method requirement, this lets users begin their trial instantly, skipping payment details. When enabled, you keep the previous behavior where payment methods are required upfront — useful for preventing trial abuse and ensuring smooth transitions to paid subscriptions. ## Easy Configuration Head to your [billing settings](https://dashboard.clerk.com/~/billing/settings) in the Clerk Dashboard to find the new toggle. ## Get Started - Configure free trials in the [Clerk Dashboard](https://dashboard.clerk.com/~/billing/plans) - Check out the [free trials documentation](/docs/billing/free-trials) --- ## Organization Growth Analytics - URL: https://clerk.com/changelog/2025-10-29-organization-growth.md - Date: 2025-10-29 We're excited to announce that the Clerk Dashboard now includes comprehensive organization growth tracking. Just as you've been able to monitor user growth with detailed retention and churn metrics, you can now access the same level of insight for your organizations. ## Organization Growth Chart The new organization growth chart provides detailed breakdowns of your organization activity over time, tracking new, reactivated, retained, and churned organizations across each period > \[!NOTE] > An organization is considered active when 2 or more of its members have signed in during the selected time period. ![Org Growth Chart](./org-chart.png) ## Flexible Filtering Organization growth data includes flexible time-based filtering options. You can analyze your data across different time periods to see daily active organizations, weekly active organizations, or monthly active organizations based on which interval you select. Customize date ranges to gain deeper insights into your organization adoption patterns and behavior over time. ## Organization Cohort Table Below the growth chart, you'll find a detailed organization cohort table that provides a granular look at individual organizations, their status, member counts, and creation dates. You can click directly on any segment of the chart above to filter the cohort table and view the specific organizations that make up that data point, making it easy to identify trends and investigate specific cohorts in detail. ![Org Cohort Table](./org-cohort.png) This update brings parity between user and organization analytics, giving you a complete picture of growth across your application. Stay tuned for more planned improvements to organization insights! --- ## LLM Leaderboard - URL: https://clerk.com/changelog/2025-10-28-llm-leaderboard.md - Date: 2025-10-28 ![LLM Leaderboard](./llm-leaderboard.jpg) Clerk has launched the [**LLM Leaderboard**][llm-leaderboard], a transparent benchmark showing how different large language models (LLMs) perform when writing Clerk-specific code. As more developers use AI assistants to build their applications, having clear, objective data on which LLMs are best at writing Clerk integrations helps developers choose the right AI tool for their projects. ## How It Works The leaderboard evaluates LLMs based on their ability to generate working Clerk integration code from simple, real-world prompts. Each model is tested using the same criteria and scenarios to ensure fair comparison. Current tests focus on **Next.js integrations**, with plans to expand to additional frameworks and use cases over time. ## View the Results Check out the [LLM Leaderboard][llm-leaderboard] to see the latest performance scores across popular models. ## Get Involved The eval suite is open source. To learn about the testing methodology, report issues, or if you want to contribute, visit the [GitHub repository][github-repo]. If you want to get involved or provide feedback on how Clerk works with AI tooling, [get in touch](mailto:ai@clerk.dev) with us. [github-repo]: https://github.com/clerk/clerk-evals [llm-leaderboard]: /llm-leaderboard --- ## M2M Tokens General Availability - URL: https://clerk.com/changelog/2025-10-14-m2m-ga.md - Date: 2025-10-14 We're thrilled to announce that the M2M Tokens feature has graduated from beta and is now **Generally Available (GA)**! After months of real-world testing and feedback, the APIs are stable, performance has been refined, and M2M tokens are ready to power your production-grade backend services. M2M tokens enable secure communication between your backend systems — from microservices and background workers to distributed systems — all with a straightforward and highly configurable authentication model. ## What's New **Stable APIs for Production:** M2M tokens are now officially supported for production workloads. You can confidently build and deploy systems using the M2M API without worrying about breaking changes. **Usage Charts in the Dashboard:** Track your M2M token activity directly from the [Clerk Dashboard](https://dashboard.clerk.com/~/machines/logs). You can now monitor token creation and verification trends at a glance, helping you stay in control of your usage. ![Usage Charts in Dashboard](./usage-charts.jpg) **Pricing Reminder:** As shared during the beta, M2M tokens will use a simple usage-based pricing model: - `$0.001` per token creation - `$0.00001` per token verification (for opaque tokens) Billing isn't live yet — we'll provide at least **30 days' notice** before billing begins. We recommend familiarizing yourself with your usage via the new usage charts before billing starts to avoid any surprises. ## What's Next We're still just getting started with machine authentication. Next, we're working on M2M tokens as JWTs, allowing verification to happen locally — no network calls required. This will make M2M authentication even faster and more flexible across your infrastructure. ## Get Started Today Ready to secure your backend service communication? Check out these resources to get started: - 📖 [M2M tokens guide](/docs/machine-auth/m2m-tokens) - Complete walkthrough of creating machines and using tokens - 💻 [Example repository](https://github.com/clerk/m2m-example) - See M2M tokens in action with two simple Express apps - 🛠️ [Machines Dashboard](https://dashboard.clerk.com/~/machines/configure) - Start creating your machine configurations We're grateful for all the feedback that shaped M2M through its beta period — and we can't wait to see what you build next. Have questions or suggestions? Reach out through [our feedback portal](https://feedback.clerk.com) or join the discussion in our [Discord community](https://clerk.com/discord). --- ## Infra Changelog - Oct 9, 2025 - URL: https://clerk.com/changelog/2025-10-09-infra-changelog.md - Date: 2025-10-09 *This post is part of a regular series where Clerk shares details about ongoing infrastructure improvements. These updates happen continually behind the scenes, and will not impact end-users beyond improving reliability and performance.* *For previous updates, see [Infra Changelog – Sep 25, 2025](https://clerk.com/changelog/2025-09-25-infra-changelog).* ## Changes since last update ### In-network database migration to minimize latency A migration of our Cloud SQL database within GCP’s network was completed to minimize latency between Cloud Run and Cloud SQL. It was performed by GCP to reverse a prior migration that had increased network latency. Although the first migration was unnoticed except by our latency monitoring, the reversal was coincident with a “[connectivity issue](https://clerk.com/cloud-sql-issue-2025-09-29.png)” that lasted 11 minutes. Thankfully, our session failover mechanism succeeded and prevented active users from being signed out. However, new sign ups, sign ins, and other account changes failed during this time. We are awaiting a full root cause analysis from GCP to determine if the two events were related. We will share the analysis when it becomes available. Once connectivity was restored, we verified that latency improved as expected. ### Convert high-update workload to append-only We had a particular high-update table that created undue stress on the database in periods of high activity. We’ve replaced that high-update workload with an append-only workload. The change was carried out over the course of a week, where we incrementally enabled dual writes until we reached 100% of traffic, then leveraged dual reads over several days to ensure consistent behavior. Finally, we removed dual writes and now only leverage the append-only workload. ### Direct queuing of background jobs We leverage PubSub for background jobs. Many jobs require transactional guarantees, which we achieve by writing the job details to the database within a transaction. Others don’t, like non-essential jobs for analytics and telemetry. Previously, all jobs were written to the database, regardless of if they required a transactional guarantee. Going forward, jobs that don’t require transactional guarantees will be queued directly to reduce the database load. ### Database tuning We’ve continued efforts to tune autovacuum and fillfactor settings. Though this is an ongoing effort that is never truly “done,” we feel we’ve made the major adjustments necessary to take advantage of our recently upgraded database specs. ### Query and index tuning This is a regular activity that will likely be in every update, but it is still included in the interest of completeness. This time, the biggest improvement came from replacing a DISTINCT with an alternate strategy. ## In progress ### Blue/green database upgrade automation We’re building an automated mechanism for blue/green database upgrades, which we’ll leverage for version upgrades and settings changes that typically require minutes of downtime. With automation, we expect these upgrades to complete in a few seconds maximum, and are exploring solutions to minimize request failures during that window. ### Application-to-database “chattiness” optimizations We’ve started focusing more on and reducing the overall number of queries per request, by either changing our application logic or leveraging database functions to perform multiple queries at once. These changes will make us more resilient to future database VM migrations within the network, which are typically done administratively by GCP and out of our control. Our intention is to support up to 2ms of network latency between our compute and the database without a noticeable impact on user experience. ### Reduce session API requests *(Promoted to in progress)* We’ve discovered a bug in our session refresh logic that causes individual devices to send more refreshes than necessary. We believe resolving this bug can significantly reduce our request volume. ### Improved monitoring We’re re-analyzing all of our recent degradation and outage incidents and improving our monitoring suite. So far, we’re optimistic that we can achieve earlier notice of potential issues by tuning our existing monitors and adding new ones. ## Planned ### Database connection pooler and major version upgrade *(Unchanged since last update)* Clerk has historically only used a client-side database pooler inside our Cloud Run containers. Though we’ve known this is non-optimal, we did this because Google did not offer managed database pooler, and we were skeptical of putting a self-hosted service in the middle of two managed services (Cloud Run and Cloud SQL). In March, Google released a managed connection pooler in Preview, and it reached General Availability this week. However, using the connection pooler will require a major database version upgrade, and in our particular case, a network infrastructure upgrade. We are collaborating with Google to determine how we can achieve both upgrades safely and without downtime. Simultaneously, we are investigating other database and connection pooler solutions that can run within our VPC. We plan to leverage our blue/green automation for these upgrades. ### Further session API isolation *(Unchanged since last update)* Currently, the session API must failover to a replica during primary database downtime, which is not ideal since the primary database is still impacted by other workloads. We are pursuing solutions that would lead to a session-specific database. ### Additional service isolation *(Unchanged since last update)* While working to isolate our Session API, we’ve already developed a handful of techniques that can be re-used to isolate other services. When done, we’d like isolated workloads for each of our product areas: - Session - Sign up - Sign in - User account management (profile fields) - Organizations - Billing - Fraud ### Additional staged rollout mechanisms Today, our staged rollout mechanisms usually target all traffic in increasing percentages. We intend to build more targeted rollout mechanisms, for example by customer cohort or products used. --- ## Clerk Leap Integration - URL: https://clerk.com/changelog/2025-10-08-clerk-leap-integration.md - Date: 2025-10-08 Clerk is now available as an authentication provider for [Leap](https://leap.new), an AI developer agent. To get started, builders can prompt Leap to create a new application with Clerk for authentication. Behind the scenes, Leap will provision a Clerk application on your behalf so you can start building immediately. When you're ready to configure your application, you can claim the generated application via the Clerk dashboard. To learn more about Leap's Clerk integration, [visit the Leap documentation](https://docs.leap.new/tutorials/authentication). ## Clerk + AI builders: better together Clerk is an excellent companion to generative AI tools, like Leap. With drop-in authentication and billing primitives, you can build and ship real-world applications faster, not just prototypes. Focus on iterating and building out your application with battle-tested primitives from Clerk. If you're building AI tools and interested in integrating with Clerk, [get in touch](mailto:ai@clerk.dev) with us to learn more. --- ## Organization slugs disabled by default - URL: https://clerk.com/changelog/2025-10-07-enable-organization-slugs.md - Date: 2025-10-07 Starting today for new applications, when you enable our Organizations featureset, organization slugs will be disabled by default. Previously, you needed to pass a `hideSlug` prop to organization components to hide the slug field, requiring manual configuration. Now, when disabled, the slug field won't be displayed in organization components by default. ## Opt-in to Organization Slugs If you'd still like slugs to exist alongside Organizations in your application, toggle "Enable organization slugs" in [Organization settings](https://dashboard.clerk.com/~/organizations-settings). --- ## Infra Changelog - Sep 25, 2025 - URL: https://clerk.com/changelog/2025-09-25-infra-changelog.md - Date: 2025-09-25 *Starting with this post, we will regularly share details about ongoing infrastructure improvements. These updates happen continually behind the scenes, and will not impact end-users beyond improving reliability and performance.* ## Released this week ### Isolated compute for our Session API Following the incident [on June 26](https://clerk.com/blog/postmortem-jun-26-2025-service-outage), we began isolating our session API infrastructure from the rest of our frontend-facing API, which includes workloads like sign ups, sign ins, user profiles. To keep our session API running during an incident, we require access to session-relevant storage and compute during that downtime. We started with storage, which was the more challenging of the two workstreams. Thankfully, this was released ahead of the incident last week, and helped reduce the blast radius. When queries against our primary database failed, our new “outage resiliency” mechanism kicked in and started working off a read replica to serve session tokens instead. Here’s a chart of the tokens served: ![Outage resilience spike](./outage-resilience-spike.png) Unfortunately, this chart does not reflect the full volume of session tokens that were requested during the incident, since many failed because our compute was exhausted. Here’s what happened: - Clerk uses Google Cloud Run with auto-scaling for compute. It serves all requests for sessions, sign ups, sign ins, organizations, and billing. - When the database failed, session requests continued to succeed because of our failover mechanism, but non-session requests got stuck behind query timeouts, and overall request latency increased. - Increased request latency triggered auto-scaling of Cloud Run until the configured maximum containers was hit. During this autoscaling, the session requests continued to succeed. - Once the maximum was hit, throughput for our frontend API Cloud Run service dropped sharply, and session requests were no longer reliably being served. The solution to this is to serve session requests from a separate Cloud Run service than the rest of our frontend API. That way, session requests can retain high throughput against the read replica during a primary database incident, while the rest of the of the frontend API can wait for the primary database to recover. We’ve built this so our session API compute is always on and handling all session requests, so we do not need to wait for a failover of Cloud Run. Here are charts showing our request volume move to the new Cloud Run service for our session API after release: *Frontend API requests - now with session requests removed:* ![Frontend API decrease](./frontend-api-decrease.png) *Session API requests running independently:* ![Session API start](./session-api-up.png) ### Database tuning Following the auto-upgrade last week, it was expected that we’d need to retune our database in response to its improved overall performance. Below is the improvement to average query latency after a process of reindexing and adjusting our auto-vacuum settings: **September 18: First full stable day** - P50: 40μs - P95: 115μs - P99: 703μs **September 24: Yesterday** - P50: 40μs (no change) - P95: 96μs (16% improvement) - P99: 584μs (17% improvement) ## In progress ### Reducing latency between our compute and our database Working with GCP support, we learned that there is an opportunity to reduce the network latency between Cloud Run and Cloud SQL, to improve our overall request latency. We expect this to be completed within the next week. ### Continued database tuning We have more database tuning ahead. We expect modest additional improvements as we continue to monitor auto-vacuum settings, and begin adjusting fillfactor settings. ## Planned ### Where possible, convert high-write workloads from update to append-only Our original architecture depended on frequent updates, which has become burdensome on our database as we’ve scaled. Where possible, we plan to reduce our use of this pattern, and instead rely on append-only tables. In the process, we may opt to move these workloads to a time-series database like ClickHouse. ### Reduce session API requests We’ve discovered a bug in our session refresh logic that causes individual devices to send more refreshes than necessary. We believe resolving this bug can significantly reduce our request volume. ### Further session API isolation Currently, the session API must failover to a replica during primary database downtime, which is not ideal since the primary database is still impacted by other workloads. We are pursuing solutions that would lead to a session-specific database. ### Additional service isolation While working to isolate our Session API, we’ve already developed a handful of techniques that can be re-used to isolate other services. When done, we’d like isolated workloads for each of our product areas: - Session - Sign up - Sign in - User account management (profile fields) - Organizations - Billing - Fraud ### Database restart resilience Over the last few years, one of the benefits of Cloud SQL has been that it can achieve most database upgrades with only a few seconds of downtime. Clerk has application logic to ensure that requests in these few seconds are retried and unnoticeable to users. But now, Clerk is rapidly approaching the point where we need to execute operations that require longer primary database downtime. We require additional application logic to handle writes during this downtime without impacting users. ### Database connection pooler and major version upgrade Clerk has historically only used a client-side database pooler inside our Cloud Run containers. Though we’ve known this is non-optimal, we did this because Google did not offer a managed database connection pooler, and we were skeptical of putting a self-hosted service in between two managed services (Cloud Run and Cloud SQL). In March, Google released a managed connection pooler in Preview, and it reached General Availability this week. However, using the connection pooler will require a major database version upgrade, and in our particular case, a network infrastructure upgrade. We are collaborating with Google to determine how we can achieve both upgrades safely and without downtime. Simultaneously, we are investigating other database and connection pooler solutions that can run within our VPC. --- ## SAML ForceAuthn - URL: https://clerk.com/changelog/2025-09-23-saml-forceauthn.md - Date: 2025-09-23 For users with SAML integrations, the Clerk dashboard now supports configuring the `ForceAuthn` on a per-connection basis. This is especially important on shared or multi-user devices where a previous user may still have an active SSO session at the Identity Provider (IdP). When `ForceAuthn` is enabled, Clerk includes the `ForceAuthn=true` parameter on the SAML AuthnRequest so the IdP will ignore any existing SSO session and require the user to re‑authenticate (password, MFA, etc.). This prevents the next person on the same machine from silently inheriting access due to someone else’s logged-in IdP session. ### Expectations Existing SAML connections are unchanged—`ForceAuthn` remains off by default to preserve current sign‑in behavior. If you enable it, users will be prompted to re‑authenticate at the IdP on every SSO sign‑in for that connection. ### How to enable In the Clerk Dashboard, navigate to the [SSO Connections](https://dashboard.clerk.com/~/user-authentication/sso-connections) page 1. Select your SAML connection 2. Select the `Advanced` tab 3. Enable *Force authentication* 4. Save --- ## Last-used sign-in method badge - URL: https://clerk.com/changelog/2025-09-12-last-used-sign-in.md - Date: 2025-09-12 The sign-in experience now includes a helpful badge that displays on the last-used sign-in method, making it easier for users to quickly identify and select their previously used authentication option. The badge appears automatically based on the user's sign-in history and requires no additional configuration from developers on new applications. Existing applications can opt-in to this feature for their instances via the [Clerk Dashboard](https://dashboard.clerk.com). --- ## Android SDK General Availability - URL: https://clerk.com/changelog/2025-09-11-android-sdk-ga.md - Date: 2025-09-11 Today marks a significant milestone in our commitment to providing exceptional authentication experiences across all platforms. After a successful beta, we're thrilled to announce that the Clerk Android SDK is now generally available! The Clerk Android SDK addresses the need for first-class native authentication head-on. Built from the ground up with Kotlin and following Android's latest development standards, it provides the robust, idiomatic experience that Android developers expect while maintaining the simplicity and power that define all Clerk products. Let's explore what makes this release special. ## Organization support A new feature in this release is organization support. This allows you to create and manage organizations within your Android application. ```kotlin scope.launch { Organization.create(name = "My Organization") .onSuccess { organization -> // Organization created successfully } .onError { error -> // Error creating organization } } ``` ## Jetpack Compose The Clerk Android SDK was built with Jetpack Compose in mind, allowing you to harness its declarative approach to user interfaces on all Android platforms. ```kotlin {{ filename: 'MainActivity.kt' }} @Composable fun MainActivity() { Column { if(Clerk.user != null) { Text("Hello, ${Clerk.user.id}") } else { Text("You are signed out") } } } ``` ## Coroutines The Clerk Android SDK makes use of the latest in coroutines, allowing your code to be as readable and expressive as possible. ```kotlin // Create a new sign up scope.launch { val signUp = SignUp.create(SignUp.CreateParams.Standard(emailAddress = "newuser@clerk.com", password = "••••••••••")) // Send an email with a one time code // to verify the user's email signUp.prepareVerification(SignUp.PrepareVerificationParams.EmailCode) } ``` ## Social Connections (OAuth) Authenticate with your favorite social providers in just a few lines of code. ```kotlin scope.launch { SignIn.authenticateWithRedirect(SignIn.AuthenticateWithRedirectParams.OAuth(provider = OAuthProvider.GOOGLE)) } ``` ## Session Management Let the Clerk Android SDK take care of managing your user's authentication state so you can get back to building your app. ```kotlin {{ filename: 'MainActivity.kt' }} @Composable fun MainActivity() { Column { if(Clerk.session != null) { Text(Clerk.session.id) } else { Text("No session") } } ``` ## Migration from Beta For existing beta users, simply update your SDK version to `0.1.10` to access all GA features and improvements. ## Getting Started Ready to integrate production-ready authentication into your Android app? Check out our comprehensive resources: - [Android SDK Documentation](/docs/references/android/overview) - Complete API reference and guides - [Quickstart Guide](/docs/quickstarts/android) - Get up and running in minutes ## Looking Forward The general availability of our Android SDK represents more than just a product milestone - it demonstrates our ongoing commitment to providing world-class authentication solutions across every platform where your users engage with your applications. We're incredibly grateful to our beta community whose feedback was instrumental in shaping this release. As we continue expanding platform support and adding new authentication capabilities, the Android SDK will evolve alongside our broader ecosystem. Expect regular updates with new features, performance improvements, and expanded integration options. Have questions about the GA release, or need help with migration or implementation? Our support team is ready to help, and our Discord community is more active than ever with developers sharing experiences and best practices. The full SDK source code remains available on GitHub, where you can contribute, report issues, or simply explore how we've built this authentication solution for the Android ecosystem. --- ## Fetch user subscription - URL: https://clerk.com/changelog/2025-09-03-billing-bapi-user-subscription.md - Date: 2025-09-03 Developers can now fetch a user's subscription directly from our [Backend API](/docs/reference/backend-api/tag/billing/get/users/%7Buser_id%7D/billing/subscription) via `GET /user/:user_id/billing/subscription`. ### Usage with Next.js ```ts import { clerkClient, auth } from '@clerk/nextjs/server' export async function getUserSubscription() { const { userId } = await auth.protect() const client = await clerkClient() return client.billing.getUserBillingSubscription(userId) } ``` For more information and SDK availability, check out the [documentation](/docs/references/backend/billing/get-user-billing-subscription). --- ## Free trials for subscriptions - URL: https://clerk.com/changelog/2025-09-02-free-trials.md - Date: 2025-09-02 Free trials are a great way to get your users to their "a-ha!" moment and increase conversions, and Clerk Billing makes them easy to setup and use. #### Straightforward Configuration Enable free trials for any plan in the [Clerk Dashboard](https://dashboard.clerk.com/~/billing/plans) and choose the duration of the trial. Or you can roll out the same free trials configuration for many plans at once. Existing users will see no change to their subscriptions, but any new signups will get your configured free trial before their card is charged. Change your configuration at any time, and it will take effect for any new signups after that point. #### Easy to Manage You can cancel your users' free trials at any point from the [Clerk Dashboard](https://dashboard.clerk.com/~/billing/subscriptions), or opt to have their subscription end when the free trial ends. You can also extend the free trial of any user at any time during their trial. #### Best Practices Built-In Free trials automatically use industry best practices without any configuration. Users will be required to enter a credit card before starting their trial, mitigating abuse and ensuring when their trial ends they transition smoothly to a paid subscription. And users that have already paid you or already had a free trial are ineligible to start a new one. ### Get Started Today Ready to increase your conversions? Get started with free trials: - See the [docs](/docs/billing/free-trials) for more information on free trials. - Check out our [announcement blog post](/blog/introducing-free-trials-in-clerk-billing). - Enable free trials on your first plan in the [Clerk Dashboard](https://dashboard.clerk.com/~/billing/plans) We're working to make Clerk Billing the best way to charge (and not charge) your users. Have any questions or suggestions? Reach out through [our feedback portal](https://feedback.clerk.com) or join the discussion in [our Discord community](https://clerk.com/discord). --- ## Sign-in with Base - URL: https://clerk.com/changelog/2025-08-29-base-authentication.md - Date: 2025-08-29 We’re excited to announce that Clerk has integrated [Base Account](https://www.base.org/build/base-account). Base is an on-chain stack incubated by Coinbase that makes building, earning, and owning simple and accessible. Now, anyone can "Sign-in with Base" and their account details will follow them into Clerk. Smart wallet technology makes sign-in fast. By combining Base’s open-internet foundation with Clerk’s developer-first authentication, we make it simple for builders and users to connect in one secure and seamless flow. ![SignIn with Base and UserProfile with Base connection](./ui.png) To get started, enable Base in your [Clerk Dashboard](https://dashboard.clerk.com/~/user-authentication/web3). Check out our [Base integration documentation](/docs/authentication/web3/base) for detailed setup instructions and examples. --- ## Fetch organization subscription - URL: https://clerk.com/changelog/2025-08-28-billing-bapi-org-subscription.md - Date: 2025-08-28 Developers can now fetch an organization's subscription directly from our [Backend API](/docs/reference/backend-api/tag/billing/get/organizations/%7Borganization_id%7D/billing/subscription) via `GET /organization/:org_id/billing/subscription`. ### Usage with Next.js ```ts import { clerkClient } from '@clerk/nextjs/server' export async function getOrganizationSubscription() { const client = await clerkClient() return client.billing.getOrganizationBillingSubscription('org_xxxxx') } ``` For more information and SDK availability, check out the [documentation](/docs/references/backend/billing/get-organization-billing-subscription). --- ## "Personal Accounts" disabled by default - URL: https://clerk.com/changelog/2025-08-22-personal-accounts-disabled.md - Date: 2025-08-22 Starting today for new applications, when you enable our Organizations featureset, your users will be required to create or join an organization. Previously, we defaulted to allowing a "Personal Account" which caused many of you building B2B applications to add workarounds to force organization membership. We had it backwards. And if you're using Clerk components, this just works. Users are immediately prompted upon sign-up or sign-in. ## Opt-in to Personal Accounts If you'd still like Personal Accounts to exist alongside Organizations in for your application, thats still possible. Simply toggle "Enable Personal Account" at the moment you enable organization or in the [Organization settings](https://dashboard.clerk.com/~/organizations-settings) in the Clerk Dashboard. ## Migration considerations Due to the way this could change some of the way your application handles sessions, this functionality is only available for newly created applications. If you're running an existing application and want to adopt the new default, please [contact our support team](https://clerk.com/contact/support) to discuss a migration strategy. ## Learn more For detailed implementation guides and examples, check out our [documentation on organization-based authentication](/docs/authentication/configuration/session-tasks). --- ## User cohorts in growth charts - URL: https://clerk.com/changelog/2025-08-20-dashboard-user-cohorts.md - Date: 2025-08-20 We recently shipped an updated growth chart in the Clerk Dashboard, giving better insight into your application’s growth—including detailed statuses like *new*, *reactivated*, *retained*, and even *churned* users. Our latest upgrade goes a step further and now shows you exactly which users are part of those cohorts, enabling even more visibility into your application's growth and performance over time. ![Example screenshot of chart and user cohort table](./user-cohorts.png) > Note: The table of recent sign-ups has been replaced with user cohorts, providing a clearer and more detailed view of your users' activity. Clerk is determined to become the best place for founders and builders to observe and understand their users. Head to the [Overview section](https://dashboard.clerk.com/~) of the Clerk Dashboard to see it in action, and stay tuned for more. --- ## Production Testing Tokens - URL: https://clerk.com/changelog/2025-08-19-production-testing-tokens.md - Date: 2025-08-19 Testing Tokens allow your automated tests to bypass Clerk's bot protections that might otherwise be triggered when interacting with Clerk-powered applications via automated browser agents. Previously, Testing Tokens were only for testing against Clerk development instances. With this update, Testing Tokens are now supported by Clerk production instances, allowing you to write tests against your production environment. To make testing authenticated pages easier, the existing `signIn` test helper now allows authenticating a user directly by email address. ```ts import { signIn } from '@clerk/testing/playwright' test('sign in', async ({ page }) => { await signIn({ emailAddress: process.env.TEST_USER_EMAIL, page }) // Navigate to a protected page for additional testing await page.goto('/protected') }) ``` To learn more about Testing Tokens, visit the [documentation](/docs/testing/overview#testing-tokens). --- ## M2M Tokens Public Beta - URL: https://clerk.com/changelog/2025-08-15-m2m-beta.md - Date: 2025-08-15 M2M tokens are designed specifically for **authenticating requests between different machines within your backend infrastructure**. Whether you're building microservices, background workers, or distributed systems, M2M tokens provide a secure way for your services to communicate with each other. This is distinct from our other machine authentication offerings: - **Looking for OAuth access tokens?** Check out our [OAuth scoped access guide](/docs/oauth/scoped-access) - **Need API keys for your users?** This feature is coming soon - [get notified when it's available](https://feedback.clerk.com/roadmap?id=beee0250-bfd3-4207-9865-2bebd1c49078) ### Configure Machine Communication with Ease Create and configure machines directly from the [Clerk Dashboard](https://dashboard.clerk.com/~/machines/configure) or via [our API](/docs/reference/backend-api/tag/machines/post/machines) or SDKs. You have complete control over which machines can communicate with each other, allowing you to implement the principle of least privilege across your infrastructure. Tokens can be customized with: - **Custom claims** to pass additional context between services - **Configurable expiration times** for enhanced security - **Instant revocation** when you need to immediately cut off access ### Simple Integration Creating and verifying M2M tokens is straightforward with our SDKs: ```javascript // Create a token on Machine A const m2mToken = await clerkClient.m2m.createToken() // Send authenticated request to Machine B await fetch('', { headers: { Authorization: `Bearer ${m2mToken.token}`, }, }) // Verify the token on Machine B const verified = await clerkClient.m2m.verifyToken({ token }) ``` ### Pricing M2M tokens are **free to use during the beta period**. After general availability, they'll move to a simple usage-based pricing model. The pricing will be: - `$0.001` per token creation - `$0.00001` per token verification (for opaque tokens) We'll provide usage stats, monitoring, and rate limiting in the Dashboard before the beta period ends, so you'll have complete visibility and control over your usage and costs. We're also planning to add support for JWT tokens before the beta period ends, which will only incur charges for creation, not verification. ### Get Started Today Ready to secure your backend service communication? Check out our resources to get started: - 📖 [M2M tokens guide](/docs/machine-auth/m2m-tokens) - Complete walkthrough of creating machines and using tokens - 💻 [Example repository](https://github.com/clerk/m2m-example) - See M2M tokens in action with two simple Express apps - 🛠️ [Machines Dashboard](https://dashboard.clerk.com/~/machines/configure) - Start creating your machine configurations We'd love to hear your feedback as you try out M2M tokens. Your input during the beta period will help us refine the feature and ensure it meets your needs. Have questions or suggestions? Reach out through [our feedback portal](https://feedback.clerk.com) or join the discussion in our [Discord community](https://clerk.com/discord). --- ## shadcn/ui registry support - URL: https://clerk.com/changelog/2025-08-13-shadcn-registry.md - Date: 2025-08-13 ![Clerk sign-up page using shadcn/ui registry](./sign-up-page.png) Clerk components are now available through the Clerk component registry, which is fully compatible with the [shadcn/ui CLI](https://ui.shadcn.com/docs/cli). This integration brings the familiar `shadcn add` workflow to Clerk, making it easier than ever to add authentication to your Next.js applications with pre-configured components that match your shadcn/ui theme. ## What's included The Clerk component registry includes everything you need to get started with Clerk authentication in a Next.js project: - **Complete quickstart setup** - Layout, sign-in/up pages, middleware, and components - **Individual components** - `ClerkProvider`, authentication pages, and middleware - **Pre-configured theming** - Automatic shadcn/ui theme integration - **Environment variables** - Automatic setup for required Clerk configuration ## Quick Start Add Clerk to your project with the quickstart block: ```npm npx shadcn@latest add https://clerk.com/r/nextjs-quickstart.json ``` This single command will install: - App layout with `ClerkProvider` and theme integration - Sign-in and sign-up pages with catch-all routes - Clerk middleware for route protection - Header component with authentication buttons - Theme provider for dark/light mode support ## Individual Components Prefer to install components individually? You can add specific pieces as needed. ### Authentication Pages ```npm npx shadcn@latest add https://clerk.com/r/nextjs-sign-in-page.json ``` ```npm npx shadcn@latest add https://clerk.com/r/nextjs-sign-up-page.json ``` ### `ClerkProvider` Component ```npm npx shadcn@latest add https://clerk.com/r/nextjs-clerk-provider.json ``` ### Clerk Middleware ```npm npx shadcn@latest add https://clerk.com/r/nextjs-middleware.json ``` To learn more about the available pages, components, and files, see the [Next.js shadcn/ui registry documentation](/docs/references/nextjs/shadcn). ## What's Next This initial release focuses on Next.js support. We're actively working on expanding the Clerk component registry to include components for other popular frameworks and meta-frameworks in the future. If you're interested in support for a specific framework, please [let us know](https://clerk.com/contact/support) which one you'd like to see next! --- ## Enabled ability to fetch billing plans - URL: https://clerk.com/changelog/2025-08-11-billing-bapi-plans.md - Date: 2025-08-11 We're excited to announce a new feature: you can now fetch all billing plans for your application directly from our [Backend API](/docs/reference/backend-api/tag/commerce/get/commerce/plans) via `GET /v1/commerce/plans`. This gives you full flexibility to display your pricing plans however you'd like, whether it's a custom pricing page or a plan comparison chart tailed to your users. ### Usage with Next.js ```ts import { clerkClient } from '@clerk/nextjs/server' export async function getPricingTable() { const client = await clerkClient() return client.billing.getPlanList() } ``` To demonstrate what's possible in the latest Next.js versions we've put together an example that utilizes this new endpoint and renders a ["cached" pricing table](https://nextjs.org/docs/app/api-reference/config/next-config-js/cacheComponents) that is SEO-friendly and revalidates on demand. Checkout the [GitHub repo](https://github.com/clerk/cached-pricing-table) or execute the command below to clone it. ```sh git clone https://github.com/clerk/cached-pricing-table.git ``` --- ## Changes to allowlist and blocklist on sign in - URL: https://clerk.com/changelog/2025-08-08-allowlist-blocklist-on-sign-in.md - Date: 2025-08-08 ![Allowlist and blocklist on sign in screenshot](./dashboard-allowlist-blocklist.png) For new applications created after **August 5, 2025**, the allowlist and blocklist will only apply to sign ups. Previously, these lists affected both sign ups and sign ins. For existing applications, your settings remain unchanged, but you can opt in to the new behavior anytime from the [Clerk Dashboard](https://dashboard.clerk.com/~/user-authentication/restrictions) under Settings > User & Authentication > Restrictions. ## Why the change? The allowlist and blocklist are designed to control who can create accounts, not manage existing users. Because blocking sign ins does not affect existing sessions, it was a half-measure to blocking access and often caused confusion. It also made challenging to block access to identifiers moving forward, without affecting existing accounts. If you need to completely revoke a user's access, you should use the ban feature instead, which will immediately end their active sessions and prevent them from signing in again. --- ## Android SDK Beta - URL: https://clerk.com/changelog/2025-08-07-android-sdk-beta.md - Date: 2025-08-07 In a world where users prefer different devices and often switch between them, having a consistent and convenient authentication experience across platforms is more important than ever. Our [Expo SDK](/docs/quickstarts/expo) has long enabled the creation of universal applications for Android, iOS, and the web using a single React codebase. However, we recognize that some customers prefer native SDKs for optimized performance, direct access to platform-specific features, and seamless integration with other native components. That's why we’re excited to introduce Clerk Android (Beta)! The Clerk Android SDK is a toolkit designed to integrate Clerk’s authentication and user management services with applications made for the Android ecosystem. Built with Kotlin, the SDK adheres to modern standards, delivering the idiomatic and consistent developer experience you expect from Clerk. Clerk Android is launching in beta today, with support for building fully custom sign-up and sign-in flows for Android devices. Along with the release, we're also sharing [reference documentation](/docs/references/android/overview) and a [quickstart](/docs/quickstarts/android) to get you started. Now, on to some highlights of the Clerk Android SDK... ## Jetpack Compose The Clerk Android SDK was built with Jetpack Compose in mind, allowing you to harness it's declarative approach to user interface on all Android platforms. ```kotlin {{ filename: 'MainActivity.kt' }} @Composable fun MainActivity() { Column { if(Clerk.user != null) { Text("Hello, ${Clerk.user.id}") } else { Text("You are signed out") } } } ``` ## Coroutines The Clerk Android SDK makes use of the latest in coroutines, allowing your code to be as readable and expressive as possible. ```kotlin // Create a new sign up scope.launch { val signUp = SignUp.create(SignUp.CreateParams.Standard(emailAddress = "newuser@clerk.com", password = "••••••••••")) // Send an email with a one time code // to verify the user's email signUp.prepareVerification(SignUp.PrepareVerificationParams.EmailCode) } ``` ## Social Connections (OAuth) Authenticate with your favorite social providers in just a few lines of code. ```kotlin scope.launch { SignIn.authenticateWithRedirect(SignIn.AuthenticateWithRedirectParams.OAuth(provider = OAuthProvider.GOOGLE)) } ``` ## Session Management Let the Clerk Android SDK take care of managing your user's authentication state so you can get back to building your app. ```kotlin {{ filename: 'MainActivity.kt' }} @Composable fun MainActivity() { Column { if(Clerk.session != null) { Text(Clerk.session.id) } else { Text("No session") } } ``` ## Building towards GA As an official Clerk SDK, you can expect responsive support, even while in beta. Your [feedback](https://clerk.com/contact/support) is critical during this testing period to ensure Clerk Android is the best it can be. If you have questions or want to talk to other users who are trying out the beta, join the [Clerk Discord](https://clerk.com/discord) community. Please note the SDK is currently in beta. Certain features - notably pre-built components, organizations, and magic links - are not yet implemented, but we're working on it. The full SDK is available on [GitHub](https://github.com/clerk/clerk-android). The API will likely undergo breaking changes until the 1.0.0 release. --- ## Prebuilt iOS Views - URL: https://clerk.com/changelog/2025-08-07-ios-components.md - Date: 2025-08-07 We're excited to introduce prebuilt UI views that make it incredibly easy to add authentication flows to your iOS applications. These new SwiftUI views provide complete authentication experiences out of the box, eliminating the need to build custom sign-in and user management interfaces from scratch. With just a few lines of code, you can now add authentication and user management to your iOS app that matches iOS design standards and includes advanced features like multi-factor authentication, social sign-in, and comprehensive user profile management. ## AuthView - Complete Authentication Flow The `AuthView` provides a comprehensive authentication experience supporting both sign-in and sign-up flows, multi-factor authentication, password reset, account recovery and more. ![The AuthView renders a comprehensive authentication interface that handles both user sign-in and sign-up flows.](./ios-auth-view.png) ```swift {{ filename: 'HomeView.swift' }} import SwiftUI import Clerk struct HomeView: View { @Environment(\.clerk) private var clerk @State private var authIsPresented = false var body: some View { ZStack { if clerk.user != nil { UserButton() .frame(width: 36, height: 36) } else { Button("Sign in") { authIsPresented = true } } } .sheet(isPresented: $authIsPresented) { AuthView() } } } ``` ## UserButton - Profile Access Made Simple The `UserButton` displays the current user's profile image in a circular button and opens the full user profile when tapped. ![The UserButton is a circular button that displays the signed-in user's profile image.](./ios-user-button.png) ```swift {{ filename: 'HomeView.swift' }} .toolbar { ToolbarItem(placement: .navigationBarTrailing) { if clerk.user != nil { UserButton() .frame(width: 36, height: 36) } } } ``` ## UserProfileView - Comprehensive Account Management The `UserProfileView` provides a complete interface for users to manage their accounts, including personal information, security settings, account switching, and sign-out functionality. ![The UserProfileView renders a comprehensive user profile interface that displays user information and provides account management options.](./ios-user-profile-view.png) ```swift {{ filename: 'ProfileView.swift' }} import SwiftUI import Clerk struct ProfileView: View { @Environment(\.clerk) private var clerk var body: some View { if clerk.user != nil { UserProfileView(isDismissible: false) } } } ``` ## ClerkTheme - Customization The new theming system allows you to customize the appearance of all Clerk views to match your app's design. ```swift {{ filename: 'App.swift' }} import SwiftUI import Clerk @main struct MyApp: App { var body: some Scene { WindowGroup { ContentView() .environment(\.clerkTheme, customTheme) } } } let customTheme = ClerkTheme( colors: .init( primary: Color(.brandPrimary) ), fonts: .init( fontFamily: "Avenir" ), design: .init( borderRadius: 12 ) ) ``` ### Light and Dark Mode Support All Clerk iOS views automatically support both light and dark mode appearance, adapting seamlessly to the user's system preferences. ![Light Mode](./ios-user-profile-view.png) ![Dark Mode](./ios-user-profile-view-dark.png) ## Getting Started To get started follow the [Quickstart Guide](/docs/quickstarts/ios) and see the views docs: - [AuthView](/docs/ios/reference/views/authentication/auth-view) - [UserButton](/docs/ios/reference/views/user/user-button) - [UserProfileView](/docs/ios/reference/views/user/user-profile-view) - [ClerkTheme](/docs/ios/guides/customizing-clerk/clerk-theme) **Note:** Prebuilt iOS views are available on iOS platforms only (iOS, iPadOS, macCatalyst). ## Feedback We're excited to see what you build with these new views! Share your feedback and join the conversation in our [Discord community](https://clerk.com/discord). --- ## Verified domains in Dashboard and in Backend API - URL: https://clerk.com/changelog/2025-08-07-verified-domains-dashboard-backend-api.md - Date: 2025-08-07 Now you can see all the organization domains your organizations have set up, visit the Dashboard and head to the [Verified Domains tab](https://dashboard.clerk.com/~/organizations?organizations_tab=verified-domains) in the *Organization* section of the Dashboard. ![Verified domains tab](./verified-domains-tab.png) Additionally, you can access this data via [Organization Domains](/docs/reference/backend-api/tag/organization-domains/get/organizations/%7Borganization_id%7D/domains#tag/organization-domains/get/organizations/%7Borganization_id%7D/domains) in the Clerk Backend API. --- ## Protection against user enumeration - URL: https://clerk.com/changelog/2025-08-07-enumeration-protections.md - Date: 2025-08-07 At Clerk, our priority is to provide customers with safe, secure, and easy-to-deploy tools for user management and authentication. When it comes to authentication, each stage of the sign in or sign up flow is designed to minimize friction and get people using your application. For example, if a user attempts to sign in with an identifier that does not match an existing account on your Clerk application, we inform the user that this identifier doesn't match an existing account. This immediate feedback fits the expectations of ordinary users, who may not remember how or whether they have signed up for your application. Some of our customers also have a need to protect against [user enumeration](/glossary#user-enumeration) – when a malicious actor takes advantage of the fact that the error message discloses whether an account exists for a given identifier (like an email or phone number) to create a list of all of the accounts that exist within an application. We already offer all our customers protection against such attacks using a variety of rate limiting techniques. However, some customers would prefer to remove the ability to determine whether an account exists entirely. Some examples of apps that might fall in this category are financial institutions concerned about targeted phishing attacks, or any website for which an existing account being associated with a given email or phone number is intended to be private to that user, such as perhaps a dating app. To accommodate these needs, we are excited to announce that a set of enhanced protections against user enumeration attacks can now be enabled in the [Clerk Dashboard](https://dashboard.clerk.com), under the **Attack Protection** page. ![Clerk Dashboard Enumeration Protection feature](./user_enumeration.png) With **Enumeration Protection** enabled, users attempting to sign in or sign up will no longer receive feedback that reveals if their identifier matches an existing account. Instead, they will be advanced to the next stage of the sign in or sign up flow, but attempts to complete the sign in or sign up will be rejected if the account does not exist, in the same way they would be if the credential in the next step, for example, a password, was incorrect. This makes it such that Clerk's response is the same whether or not a user account already exists, enhancing your application's protection against user enumeration attacks. User security is our priority, and we are happy to bring these opt-in, enhanced protections against user enumeration attacks to our customers who need them. --- ## Build custom flows with React and Clerk Billing - URL: https://clerk.com/changelog/2025-08-06-billing-apis-custom-flows.md - Date: 2025-08-06 Building on our recent [billing button components](/changelog/2025-07-24-billing-buttons), we're introducing a set of React hooks that enable you to build fully custom billing flows. These hooks provide direct access to billing data and functionality, giving you complete control over the user experience. ## Control the checkout flow You can now build your own checkout flow with Clerk Billing for both users and organizations. Leverage the [`useCheckout()`](/docs/hooks/use-checkout) hook to create a custom checkout experience. Choose between prompting users to enter their payment details or pay with a saved payment method. Below you can see a simple example of a custom checkout flow that is using the [``](/docs/hooks/use-payment-element) component where users can enter their payment details. ```tsx 'use client' import { CheckoutProvider, useCheckout, PaymentElementProvider, PaymentElement, usePaymentElement, } from '@clerk/nextjs/experimental' export default function CheckoutPage() { return ( ) } function CustomCheckout() { const { checkout } = useCheckout() const { plan } = checkout return (
Subscribe to {plan.name}
) } function PaymentSection() { const { checkout } = useCheckout() const { isConfirming, confirm } = checkout const { isFormReady, submit } = usePaymentElement() const isButtonDisabled = !isFormReady || isConfirming const subscribe = async () => { const { data } = await submit() await confirm(data) } return ( <> Loading payment element...} /> ) } ``` To enable users to pay with a saved payment method, you can use the [`usePaymentMethods()`](/docs/hooks/use-payment-methods) hook to display a list of saved payment methods. ```tsx import { usePaymentMethods } from '@clerk/nextjs/experimental' function PaymentMethodSelector() { const { data: methods, isLoading } = usePaymentMethods() return (

Select Payment Method

{methods?.map((method) => ( ))}
) } ``` ## Design your own pricing table [`usePlans()`](/docs/hooks/use-plans) fetches your instance's configured plans, perfect for building custom pricing tables or plan selection interfaces. ```tsx import { usePlans } from '@clerk/nextjs/experimental' function CustomPricingTable() { const { data: plans, isLoading } = usePlans({ for: 'user', pageSize: 10, }) if (isLoading) return
Loading plans...
return (
{plans?.map((plan) => (

{plan.name}

{plan.description}

{plan.currency} {plan.amountFormatted}/month

    {plan.features.map((feature) => (
  • {feature.name}
  • ))}
))}
) } ``` ## Display subscription details ![Usage of the useSubscription hook](./example-use-subscription.png) Access current subscription details to build custom account management interfaces and display billing status. ```tsx import { useSubscription } from '@clerk/nextjs/experimental' function SubscriptionStatus() { const { data: subscription, isLoading } = useSubscription() if (!subscription) return
No active subscription
return (

Current Plan: {subscription.plan.name}

Status: {subscription.status}

Next billing: {subscription.nextPayment.date.toLocaleDateString()}

) } ``` ## Complete Control Over Billing For detailed documentation, visit: - [`usePlans()`](/docs/hooks/use-plans) - [`usePaymentMethods()`](/docs/hooks/use-payment-methods) - [`useSubscription()`](/docs/hooks/use-subscription) - [`useCheckout()`](/docs/hooks/use-checkout) - [`usePaymentElement()`](/docs/hooks/use-payment-element) For advanced usage examples, visit: - [Checkout with a new payment method](/docs/custom-flows/checkout-new-payment-method) - [Checkout with an existing payment method](/docs/custom-flows/checkout-existing-payment-method) - [Add a new payment method](/docs/custom-flows/add-new-payment-method) > \[!NOTE] > These hooks are currently exported as `experimental` while we continue to refine the API based on developer feedback. --- ## Organization permissions are now unlimited - URL: https://clerk.com/changelog/2025-08-06-remove-permission-limits.md - Date: 2025-08-06 Previously, organizations were limited to a maximum of 50 permissions, which could be restrictive for complex applications requiring granular access control. This limitation often forced developers to consolidate permissions or find workarounds when building sophisticated authorization systems. **Organizations can now have unlimited permissions**, giving you complete flexibility to model your application's access control exactly as needed. Whether you're building a complex enterprise application with hundreds of different resource types or a multi-tenant SaaS with intricate permission structures, you're no longer constrained by arbitrary limits. --- ## Improved resilience with automatic regional failover - URL: https://clerk.com/changelog/2025-08-04-regional-failover.md - Date: 2025-08-04 We’ve made significant improvements to Clerk’s infrastructure to better withstand outages and regional disruptions. As part of our ongoing commitment to reliability and in response to the [June 26th service outage](/blog/postmortem-jun-26-2025-service-outage), we’ve implemented automatic regional failover for critical parts of our system. This enhancement ensures that, in the event of a major disruption in one region, traffic is rerouted to healthy infrastructure in real time, without any manual intervention. This change reduces the risk of widespread service impact during provider-level incidents and brings us closer to our long-term goal of platform-level fault tolerance. We’re not stopping here. We’re actively working on improving the resilience of stateful systems and are exploring strategies for increased redundancy across providers. Our goal is simple: to keep Clerk highly available and dependable even when the unexpected happens. --- ## MCP Server Support for Express - URL: https://clerk.com/changelog/2025-07-29-express-mcp.md - Date: 2025-07-29 We're excited to announce server-side support for the [Model Context Protocol](https://modelcontextprotocol.io/introduction) (MCP) in Express.js applications using Clerk authentication. This enables your users to securely grant AI applications like Claude, Cursor, and others access to their data within your app. ## Getting Started Setting up an MCP server in your Express app is straightforward with [Clerk's modern OAuth provider implementation](/changelog/2025-06-13-oauth-improvements). Here's the entire implementation, within a single file in about 50 lines of code: ```tsx import 'dotenv/config' import { clerkClient, clerkMiddleware } from '@clerk/express' import { mcpAuthClerk, protectedResourceHandlerClerk, streamableHttpHandler, authServerMetadataHandlerClerk, } from '@clerk/mcp-tools/express' import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js' import cors from 'cors' import express from 'express' const app = express() app.use(cors({ exposedHeaders: ['WWW-Authenticate'] })) app.use(clerkMiddleware()) app.use(express.json()) const server = new McpServer({ name: 'test-server', version: '0.0.1', }) server.tool( 'get_clerk_user_data', 'Gets data about the Clerk user that authorized this request', {}, async (_, { authInfo }) => { const userId = authInfo!.extra!.userId! as string const userData = await clerkClient.users.getUser(userId) return { content: [{ type: 'text', text: JSON.stringify(userData) }], } }, ) app.post('/mcp', mcpAuthClerk, streamableHttpHandler(server)) app.get( '/.well-known/oauth-protected-resource/mcp', protectedResourceHandlerClerk({ scopes_supported: ['email', 'profile'] }), ) app.get('/.well-known/oauth-authorization-server', authServerMetadataHandlerClerk) app.listen(3000, () => { console.log('Server running on port 3000') }) ``` A full reference implementation is available and open source [on GitHub](https://github.com/clerk/mcp-express-example) if you'd like to test it out. > \[!NOTE] > OAuth tokens are machine tokens. Machine token usage is free during our public beta period but will be subject to pricing once generally available. Pricing is expected to be competitive and below market averages. ## Connecting AI Tools Once your MCP server is running, connecting it to AI tools is straightforward. For example, with Cursor, you can add this configuration: ```json { "mcpServers": { "clerk-mcp-example": { "url": "http://localhost:3000/mcp" } } } ``` That's it — no `stdio` tools, command execution, or additional software installation required. Just provide the URL and authentication is handled automatically through the MCP protocol. For a complete guide on testing your MCP server with various AI clients, check out our [MCP client integration guide](/docs/mcp/connect-mcp-client). ## What's Next Clerk's [OAuth provider](/changelog/2025-06-13-oauth-improvements) offers support for the MCP protocol with any framework, but MCP is still a new standard, it's changing quickly, and support and implementation can vary across different clients and frameworks, which often makes implementation tricky. For this reason, we are creating end-to-end working examples and [helpful utilities](https://github.com/clerk/mcp-tools) for each framework that we plan to steadily release over time. We recently released [an MCP implementation for Next.js](/changelog/2025-06-25-mcp-server-nextjs), and we will continue to roll out examples and guides for other frameworks in the coming months. We're excited to see what new AI-powered experiences you'll build with MCP and Clerk. If you have feedback or questions, we'd love to hear from you! --- ## New simple theme for easier customization - URL: https://clerk.com/changelog/2025-07-29-theme-simple.md - Date: 2025-07-29 You can now opt into a simpler theme for customizing Clerk components. This theme is a stripped down version of the default Clerk theme that removes advanced styling techniques, making it easier to apply your own custom styles without complex overrides. To use the simple theme, set `theme` to `simple`: ```tsx {{ mark: ['simple'] }} ``` To learn more about themes and how to customize Clerk components, check out our [theme documentation](/docs/customization/themes). --- ## End billing subscriptions immediately with the new End button - URL: https://clerk.com/changelog/2025-07-23-end-subscription-button.md - Date: 2025-07-28 We've added a new **End** button to subscription management in the Clerk Dashboard, giving you the ability to immediately end subscriptions and revoke user access to features. Previously, you could only **Cancel** subscriptions, which would stop recurring charges but allow users to retain access until the end of their current billing cycle. The new **End** button goes further by immediately terminating the subscription and revoking access to all associated features. This is particularly useful when processing refunds - you can immediately remove access to prevent further usage after issuing a refund. You can find the **End** button alongside the existing **Cancel** button in the subscription details page of any user or organization in the [Clerk Dashboard](https://dashboard.clerk.com). The **Cancel** button remains available for standard subscription cancellations where you want to honor the user's paid period. At the moment, ending a subscription is only available in the Dashboard but we'll be supporting this via the Backend API in the future. --- ## Workspace level settings in the Dashboard - URL: https://clerk.com/changelog/2025-07-25-workspace-level-settings-dashboard.md - Date: 2025-07-25 Workspace level settings like your [Settings](https://dashboard.clerk.com/settings), [Billing](https://dashboard.clerk.com/billing), and [Team Members](https://dashboard.clerk.com/team) have a new location in the Clerk Dashboard. Rather than managing them from the "Manage" button under the organization switcher and inside of a modal, you can find these settings whenever you navigate outside of the context of a single application. Stay tuned for even more improvements to these sections over the coming weeks. --- ## Button components for Clerk Billing - URL: https://clerk.com/changelog/2025-07-24-billing-buttons.md - Date: 2025-07-24 Previously, you could only access these experiences through ``, `` and `` components, but now you can use these new buttons to access them in a more flexible way. ## `` The `` component provides a simple way to initiate checkout flows in your application. It handles the entire checkout process either for users or organizations. ```tsx import { CheckoutButton } from '@clerk/nextjs/experimental' export default function CheckoutPage() { return ( ) } ``` ## `` The `` component allows users to view detailed information about a specific plan, including pricing, features, and other plan-specific details. ```tsx import { PlanDetailsButton } from '@clerk/nextjs/experimental' export default function AccountPage() { return ( ) } ``` ## `` The `` component allows users to view and manage their subscription details, whether for their personal account or organization. ```tsx import { SubscriptionDetailsButton } from '@clerk/nextjs/experimental' export default function BillingPage() { return ( ) } ``` For more detailed information about these components, check out our documentation: - [CheckoutButton](/docs/components/checkout-button) - [PlanDetailsButton](/docs/components/plan-details-button) - [SubscriptionDetailsButton](/docs/components/subscription-details-button) > \[!NOTE] > These components are currently exported as `experimental` while we harden the API. --- ## shadcn/ui theme compatibility - URL: https://clerk.com/changelog/2025-07-23-shadcn-theme.md - Date: 2025-07-23 Clerk components now support a dedicated shadcn/ui theme that automatically matches your application's existing shadcn/ui theme configuration. Built on the new [CSS variables support](/changelog/2025-07-15-clerk-css-variables-support), this theme ensures Clerk's authentication UI feels native to your shadcn/ui-based applications. ## Installation To install the shadcn theme, run the following command to install the `@clerk/themes` package: ```bash {{ filename: 'terminal' }} npm install @clerk/themes ``` ```bash {{ filename: 'terminal' }} yarn add @clerk/themes ``` ```bash {{ filename: 'terminal' }} pnpm add @clerk/themes ``` ```bash {{ filename: 'terminal' }} bun add @clerk/themes ``` Then pass the shadcn theme to the ClerkProvider component as the `baseTheme` property: ```tsx {{ filename: 'app/layout.tsx', mark: ['shadcn'] }} import { shadcn } from '@clerk/themes' export default function RootLayout({ children, }: Readonly<{ children: React.ReactNode }>) { return ( {children} ) } ``` For more information on Clerk themes, see the [themes documentation](/docs/customization/themes#shadcn). --- ## Dark Mode for the Clerk Dashboard - URL: https://clerk.com/changelog/2025-07-22-dashboard-dark-mode.md - Date: 2025-07-22 Experience the [Clerk Dashboard](https://dashboard.clerk.com) in Dark Mode. Your eyes will thank you. To set your preference, head to your avatar icon in the top-right of the dashboard, select "Manage Account" and then head to the Preferences tab. --- ## Clerk CSS variables support - URL: https://clerk.com/changelog/2025-07-15-clerk-css-variables-support.md - Date: 2025-07-15 Following last week's update that enabled [CSS variables in Clerk's appearance system](/changelog/2025-07-08-css-variables-support), you can now customize the theme of Clerk components by defining Clerk CSS variables in your application's stylesheets, no CSS-in-JS required! Define Clerk variables through CSS variables like so: ```css {{ filename: 'styles.css', mark: ['--clerk-color-primary'] }} :root { --clerk-color-primary: #6d47ff; /* colorPrimary */ } ``` For more details on the supported variables, see the [variables properties](/docs/customization/variables#properties) documentation. Included in this release, we've also taken the opportunity to improve the naming of our variables and add additional variables to make theming more flexible. ## Deprecated variables The following properties are deprecated as of **July 15th, 2025** and will be removed in the next major version of Clerk. We recommend migrating to the new properties as soon as possible. | Deprecated | New | | ------------------------------ | ------------------------ | | `colorText` | `colorForeground` | | `colorTextOnPrimaryBackground` | `colorPrimaryForeground` | | `colorTextSecondary` | `colorMutedForeground` | | `spacingUnit` | `spacing` | | `colorInputText` | `colorInputForeground` | | `colorInputBackground` | `colorInput` | ## New variables | Variable | Description | | -------------------- | ------------------------------------------------------------------------------ | | `colorRing` | The color of the ring when an interactive element is focused. | | `colorMuted` | The background color for elements of lower importance, eg: a muted background. | | `colorShadow` | The base shadow color used in the components. | | `colorBorder` | The base border color used in the components. | | `colorModalBackdrop` | The background color of the modal backdrop. | For more details, including important details about browser compatibility considerations, see the [Clerk CSS variables](/docs/customization/variables#using-css-variables) documentation. --- ## Clerk is now available on the Vercel Marketplace - URL: https://clerk.com/changelog/2025-07-14-vercel-marketplace-integration.md - Date: 2025-07-14 Clerk is now available on the [Vercel Marketplace](https://vercel.com/marketplace/clerk) in its new *Authentication* category. With one-click setup, automatic environment variable sync, and unified billing through Vercel, it's easier than ever to integrate Clerk into your Vercel projects. With the marketplace integration you can: - Leverage all of Clerk's existing features, such as Organizations and Clerk Billing - Create a Clerk account and spin up Clerk applications directly from the Vercel dashboard - Sync your Clerk API keys into your Vercel project's environment variables - Manage billing through your existing Vercel account Get started with [Clerk on the Vercel Marketplace](https://vercel.com/marketplace/clerk). > \[!TIP] > Deploy an example Next.js application and install the Clerk integration with our template. --- ## Organization Invitation Sorting - URL: https://clerk.com/changelog/2025-07-11-org-invitation-sorting.md - Date: 2025-07-11 We’ve added support for ordering organization invitations when listing them via the `/organizations/{organization_id}/invitations` endpoint, allowing sorting by creation date or email address in ascending or descending order using the new optional `order_by` parameter. ## Ordering Options - `+created_at` - Sort by creation date in ascending order - `-created_at` - Sort by creation date in descending order (default) - `+email_address` - Sort by email address in ascending order - `-email_address` - Sort by email address in descending order For more information, see our [Backend API documentation](https://clerk.com/docs/reference/backend-api/tag/Organization-Invitations#operation/ListOrganizationInvitations). --- ## Introducing top-level Features. Plus redesigned Roles & Permissions - URL: https://clerk.com/changelog/2025-07-10-top-level-features-plus-roles-and-permissions.md - Date: 2025-07-10 We’re excited to introduce a new top-level **Feature** construct for your applications. Features are utilized inside of our Billing product, like inside your `` implementations, as well as within your app's roles & permissions where you can easily attach permissions to features for authorization checks using our [`has()`, `protect()`, and `` helpers](/blog/introducing-authorization). ![Introducing top-level Features. Plus redesigned Roles & Permissions feature showcase](./feature-edit-page.png) As part of this update, we’ve also redesigned the **Roles & Permissions** page in the [Clerk Dashboard](https://dashboard.clerk.com), making it easier to manage user roles and their associated system or feature permissions. ![Introducing top-level Features. Plus redesigned Roles & Permissions feature showcase](./role-edit-page.png) Manage your app’s feature definitions in the [Feature Management](https://dashboard.clerk.com/~/features) section of the Dashboard starting today, or as part of your [Roles & Permissions](https://dashboard.clerk.com/~/organizations-settings/roles) configuration. --- ## New dashboard users now onboarded as organizations - URL: https://clerk.com/changelog/2025-07-10-new-account-structure.md - Date: 2025-07-10 Previously, new users on the Clerk Dashboard started with "personal accounts." This meant that to add collaborators, you first had to convert your account to an Organization. Since **July 4th**, all new Dashboard users have been automatically set up with an organization, allowing you to invite team members and collaborate immediately. For existing users, we will automatically migrate your personal account and all its resources to an organization in the coming days. **No action is required on your part**—all your applications and settings will remain unchanged. This change only affects Clerk Dashboard users and has no impact on your applications or its users. --- ## CVE-2025-53548 - URL: https://clerk.com/changelog/2025-07-09-cve-2025-53548.md - Date: 2025-07-09 ## Summary A vulnerability affecting **`@clerk/backend` >= 2.0.0 \< 2.4.0** was recently reported to the Clerk team and resolved. The vulnerability was discovered in the `verifyWebhook()` helper, which is used to verify incoming Clerk webhooks, and it allowed improperly signed webhook events to be accepted as legitimate. **Potentially impacted customers have already been notified via email. If your application does not use `verifyWebhook()` you are not impacted.** ## Impact Applications that use the `verifyWebhook()` helper to verify incoming Clerk webhooks are susceptible to accepting improperly signed webhook events. ## Patches - `@clerk/backend`: the helper has been patched as of `2.4.0` - `@clerk/astro`: the helper has been patched as of `2.10.2` - `@clerk/express`: the helper has been patched as of `1.7.4` - `@clerk/fastify`: the helper has been patched as of `2.4.4` - `@clerk/nextjs`: the helper has been patched as of `6.23.3` - `@clerk/nuxt`: the helper has been patched as of `1.7.5` - `@clerk/react-router`: the helper has been patched as of `1.6.4` - `@clerk/remix`: the helper has been patched as of `4.8.5` - `@clerk/tanstack-react-start`: the helper has been patched as of `0.18.3` ## Resolution The issue was resolved in **`@clerk/backend` `2.4.0`** by: - Properly parsing the webhook request's signatures and comparing them against the signature generated from the received event ## Workarounds If unable to upgrade, developers can workaround this issue by verifying webhooks manually, per [this documentation](https://clerk.com/docs/webhooks/overview#protect-your-webhooks-from-abuse). ## Credits Thanks to a **Clerk customer** for responsibly disclosing the issue to the team. ## References - [Fix in `@clerk/backend` `2.4.0`](https://github.com/clerk/javascript/releases/tag/%40clerk%2Fbackend%402.4.0) - [GHSA-9mp4-77wg-rwx9](https://github.com/clerk/javascript/security/advisories/GHSA-9mp4-77wg-rwx9) --- ## CSS variables support - URL: https://clerk.com/changelog/2025-07-08-css-variables-support.md - Date: 2025-07-08 Clerk's appearance variables object now supports CSS custom properties (CSS variables), making it easier to integrate with your existing design system and enable dynamic theming without JavaScript configuration changes. ## How to use CSS variables You can now use CSS variables directly in your appearance configuration: ```css {{ filename: 'styles/globals.css' }} :root { --brand-primary: oklch(49.1% 0.27 292.581); } @media (prefers-color-scheme: dark) { :root { --brand-primary: oklch(54.1% 0.281 293.009); } } ``` Reference these variables in your Clerk configuration: ```tsx {{ filename: 'app/layout.tsx' }} ... ``` ## Dynamic Theming With CSS variables, your theme changes automatically based on user preferences, system settings, or any other CSS-driven logic: ```css /* Theme automatically updates based on user preference */ @media (prefers-color-scheme: dark) { :root { --brand-primary: oklch(54.1% 0.281 293.009); } } /* Or with data attributes */ [data-theme='corporate'] { --brand-primary: #1e40af; } [data-theme='creative'] { --brand-primary: #7c3aed; } ``` No need to swap Clerk themes or update JavaScript configuration - the components automatically pick up the new colors. ## Design System Integration This enhancement makes it seamless to integrate Clerk with existing design systems: ```tsx ... ``` > \[!NOTE] > Clerk's support for CSS variables relies on `color-mix()` and relative color syntax, which require a modern browser (Chrome 119+, Safari 16.4+, and Firefox 128+). **If your application needs to support older browsers, continue using static color values** (like `#ff0000` or `hsl(0, 100%, 50%)`) instead of CSS variables, which will use our existing JavaScript-based color manipulation. To learn more about support for CSS variables, check out the [documentation](/docs/customization/variables). --- ## Increased Backend Rate Limits - URL: https://clerk.com/changelog/2025-07-03-bapi-rate-limits.md - Date: 2025-07-03 We’ve increased the [Backend API rate limits](/docs/backend-requests/resources/rate-limits#backend-api-requests) for production instances to better support your growing workloads! 🚀 Production instances now support **1000 requests per 10 seconds**, a 10x increase from before. This change applies across all endpoints, including `Create User`. If you're running high-traffic workloads in production, this gives you more headroom without hitting throttling errors. We're also working on a smarter, more flexible rate limiting system that scales with your app. More on that soon! *Note: Development instances remain at 100 requests per 10 seconds.* --- ## Billing Webhooks - URL: https://clerk.com/changelog/2025-07-02-billing-webhooks.md - Date: 2025-07-02 ## Payment Attempts Payment attempt webhooks allow you to track successful and failed payments, for both checkouts and recurring charges. - `paymentAttempt.created` - `paymentAttempt.updated` ## Subscriptions A subscription is the top level container unique to each user or organization. Subscription events can help you track billing changes for each of your customers. - `subscription.created` - `subscription.updated` - `subscription.active` - `subscription.past_due` ## Subscription Items Subscription items provide more details about the relationship between a user or organization and a plan. A top level subscription may contain multiple subscription items. - `subscriptionItem.updated` - `subscriptionItem.active` - `subscriptionItem.canceled` - `subscriptionItem.upcoming` - `subscriptionItem.ended` - `subscriptionItem.abandoned` - `subscriptionItem.incomplete` - `subscriptionItem.past_due` For more details about these webhook events, visit the Event Catalog tab on the [Webhooks](https://dashboard.clerk.com/~/webhooks) page in Clerk dashboard. --- ## MCP Server Support for Next.js - URL: https://clerk.com/changelog/2025-06-25-mcp-server-nextjs.md - Date: 2025-06-27 We're excited to announce server-side support for the [Model Context Protocol](https://modelcontextprotocol.io/introduction) (MCP) in Next.js applications using Clerk authentication. This enables your users to securely grant AI applications like Claude, Cursor, and others access to their data within your app. ## What is MCP? MCP is an open standard that allows AI applications to request permission to access users' private information that would normally require authentication — like emails, private repositories, or application-specific data. This creates new possibilities for AI-powered workflows while keeping users in control of their data access. If you are building an application using Clerk and would like for your users to be able to grant access to their data to AI applications, you can now do so with Clerk's MCP support 🎉. ## Getting Started Setting up an MCP server in your Next.js app is straightforward with [Clerk's modern OAuth provider implementation](https://clerk.com/changelog/2025-06-13-oauth-improvements). Here's an example of how the MCP route handler might look in your Next.js app: ```tsx // app/[transport]/route.ts import { verifyClerkToken } from '@clerk/mcp-tools/next' import { clerkClient, auth } from '@clerk/nextjs/server' import { createMcpHandler, experimental_withMcpAuth as withMcpAuth } from '@vercel/mcp-adapter' const clerk = await clerkClient() const handler = createMcpHandler((server) => { server.tool( 'get-clerk-user-data', 'Gets data about the Clerk user that authorized this request', {}, async (_, { authInfo }) => { const userId = authInfo!.extra!.userId! as string const userData = await clerk.users.getUser(userId) return { content: [{ type: 'text', text: JSON.stringify(userData) }], } }, ) }) const authHandler = withMcpAuth( handler, async (_, token) => { const clerkAuth = await auth({ acceptsToken: 'oauth_token' }) return verifyClerkToken(clerkAuth, token) }, { required: true, resourceMetadataPath: '/.well-known/oauth-protected-resource/mcp', }, ) export { authHandler as GET, authHandler as POST } ``` > \[!NOTE] > OAuth tokens are machine tokens. Machine token usage is free during our public beta period but will be subject to pricing once generally available. Pricing is expected to be competitive and below market averages. ## Implementation Details Our MCP implementation is built on [the current specification draft](https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization), ensuring compatibility with the latest protocol standards and authentication flows. We've worked closely with the MCP community and contributed to the specification and SDK to ensure robust, secure integrations. Rather than requiring separate MCP servers with their own authentication protocols, our approach allows you to add MCP capabilities directly to your existing application through a single API endpoint. This eliminates the overhead of deploying and managing additional services - you can expose your app's functionality to AI tools without architectural complexity. For legacy clients that use outdated implementations of the MCP protocol and/or do not support authentication, tools like [mcp-remote](https://github.com/geelen/mcp-remote) can bridge the gap. We are also grateful to Vercel for their fantastic work on the [MCP Adapter](https://github.com/vercel/mcp-adapter), which this implementation leverages heavily. We've thoroughly enjoyed collaborating with their team on this project. ## Connecting AI Tools Once your MCP server is running, connecting it to AI tools is straightforward. For example, with Cursor, you can add this configuration: ```json { "mcpServers": { "clerk-mcp-example": { "url": "http://localhost:3000/mcp" } } } ``` That's it — no `stdio` tools, command execution, or additional software installation required. Just provide the URL and authentication is handled automatically through the MCP protocol. For a complete guide on testing your MCP server with various AI clients, check out our [MCP client integration guide](/docs/references/nextjs/connect-mcp-client). ## Customer Implementations We've been developing MCP tooling publicly for the past few months and have been impressed by our customers' enthusiasm for building with this technology. The extensive testing and feedback we've received has been invaluable in shaping and stabilizing this release. We'd like to highlight a couple of examples of customers who have deployed MCP servers with Clerk authentication to production: - [Overbooked](https://overbooked.app) - ([MCP Server Documentation](https://www.overbooked.app/blog/m1740bxy2kz155xxzpfj3280z57jgj9n)) - [Scorecard](https://scorecard.io) - ([Launch Post](https://www.scorecard.io/blog/scorecard-mcp-2-0-1000-lines---70), [MCP Repo](https://github.com/scorecard-ai/scorecard-mcp)) These customers have been exceptional development partners, and their engineering teams are working hard to build innovative products and ensure that their users can integrate their products with MCP as easily as possible. We're proud to have them as part of the Clerk community and encourage you to explore their products as well as their new MCP integrations! ## What's Next This initial release focuses on Next.js support, with additional framework support coming soon. We're also working on expanded tooling and utilities to make MCP integration even more straightforward across different development environments. Beyond server-side tooling, we're also building client-side tools to help AI applications connect with MCP endpoints more easily. If you're interested in early access for any of these features, please [reach out to our support team](https://clerk.com/contact/support), and we'll get you set up! Check out our [step-by-step MCP implementation guide](/docs/references/nextjs/build-mcp-server) in the documentation to get started with your first MCP-enabled endpoint. We're excited to see what new AI-powered experiences you'll build with MCP and Clerk. If you have feedback or questions, we'd love to hear from you! --- ## Multiple domains for enterprise SSO connections - URL: https://clerk.com/changelog/2025-06-25-multiple-domains-sso.md - Date: 2025-06-25 You can now add multiple domains to a single SSO connection directly from the Clerk Dashboard, eliminating the need to create separate connections for each domain or subdomain. --- ## Tailwind CSS v4 support - URL: https://clerk.com/changelog/2025-06-17-css-layer-name.md - Date: 2025-06-17 To ensure compatibility with Tailwind CSS v4 and its use of native CSS layers, and to provide more granular control over CSS specificity, Clerk now accepts a new `cssLayerName` option. This new option allows Clerk's component styles to be integrated into the native CSS layering system. When you provide a layer name, Clerk will automatically wrap all of its styles within that CSS layer. ## How to use 1. Add the `cssLayerName` prop to the `appearance` object of your `ClerkProvider` or Clerk options config, depending on your framework. ```tsx {{ filename: 'layout.tsx', mark: ["cssLayerName: 'clerk'"] }} import { ClerkProvider } from '@clerk/nextjs' export default function RootLayout({ children }: { children: React.ReactNode }) { return ( {children} ) } ``` 2. After specifying the `cssLayerName` option, you then need to specify the CSS layer order in your global stylesheet. This ensures that the layer you assigned to Clerk (e.g., "clerk") is correctly sequenced with Tailwind's layers and your custom styles: ```css {{ mark: ['clerk'] }} @layer theme, base, clerk, components, utilities; @import 'tailwindcss'; ``` This configuration ensures that Clerk styles are part of the cascade in a predictable way, playing nicely with Tailwind CSS v4's architecture and allowing you to utilize Tailwind's utility classes within [Clerk's appearance object](/docs/customization/overview#use-tailwind-classes-to-style-clerk-components). --- ## OAuth Provider Improvements - URL: https://clerk.com/changelog/2025-06-13-oauth-improvements.md - Date: 2025-06-13 We're excited to announce a major expansion to Clerk's OAuth capabilities! This release adds the following features to Clerk: - OAuth tokens generated through Clerk's OAuth endpoints can now be verified through Clerk's SDKs and instantly revoked. - Clerk now supports [authorization server metadata](https://datatracker.ietf.org/doc/html/rfc8414) out of the box. - The OAuth authorization flow now includes a consent screen that displays the access that the user is granting and ensures that they are ok with it before completing the flow. - Implementing public clients (that must complete the token exchange in the browser) with Clerk's OAuth feature is now possible due to changes to our CORS handling. - Clerk now supports [dynamic client registration](https://datatracker.ietf.org/doc/html/rfc7591) for OAuth clients. - Clerk's OAuth implementation is compatible with all the requirements needed to implement [MCP](https://modelcontextprotocol.io/introduction) services using Clerk as an authorization service. We have been working hard for the last few months on these features and are beyond excited to finally get them into our customers and users' hands. Many thanks to everyone who helped us to test and refine them through our early access program! ### What is OAuth? If you're a web developer, you have no doubt heard the term “OAuth” and know it's in some way related to authentication, or maybe to single sign on, but for the vast majority of engineers, this is about as far as it goes. Truth be told, OAuth is quite a confusing topic, largely because *the term “OAuth” is used to refer to three entirely different features, and there is no clear way to differentiate between them.* We wrote a detailed post explaining OAuth in general, as well as these three distinctions that [you can read here](/blog/how-oauth-works). The key takeaway: these new features enable **OAuth scoped access** - allowing third-party applications to access user data with explicit permission and limited scope. Let's recap the three OAuth use cases: 1. **OAuth Scoped Access** - *The features from this announcement enable this* 2. **OAuth SSO** - *We already [had support for this](/docs/oauth/oauth-single-sign-on)* 3. **OAuth User Management** - *We do [user management](/docs/how-clerk-works/overview), but not via OAuth* With this background out of the way, let's get into an example of how these new features work! ### Implementing OAuth scoped access If you'd like to take this feature for a spin, we have a guide on how to implement OAuth scoped access into a Clerk application [right here](/docs/oauth/oauth-scoped-access). It just takes a few minutes to configure an OAuth client in Clerk's dashboard and start using it. ### Verifying OAuth access tokens with Clerk If you are building an application that uses Clerk and would like to incorporate OAuth, you will want to ensure that, after the client gets an OAuth access token, they can use it to make authenticated requests into your app (the *resource service*) using the token. Let's look at an example of how this could be done on an API route with Clerk's Next.js SDK: ```tsx // app/api/example/route.ts import { auth } from '@clerk/nextjs' export async function GET() { const { userId, isAuthenticated } = await auth({ acceptsToken: 'oauth_token', }) if (!isAuthenticated) { return Response.json({ error: 'Unauthorized' }, { status: 401 }) } // pseudo-code: get user data from a database const userData = await getUserDataFromDatabase({ clerkUserId: userId }) return Response.json(userData) } ``` To learn more about verifying machine tokens with Clerk, check out our new OAuth documentation on the topic [right here](/docs/oauth/oauth-verify-tokens). OAuth token verification through Clerk is currently available across most of our SDK ecosystem, making it easy to build resource servers that can authenticate requests from OAuth clients. **Fully supported:** - [Next.js](/docs/references/nextjs/verifying-oauth-access-tokens) - [JavaScript Backend SDK](/docs/references/backend/authenticate-request#authenticaterequestoptions) - [Express SDK](/docs/reference/express/get-auth#getauth-options) - [React Router](/docs/guides/development/verifying-oauth-access-tokens) - [Fastify SDK](/docs/reference/fastify/get-auth#getauth-options) - [TanStack Start](/docs/guides/development/verifying-oauth-access-tokens) - [Python SDK](https://github.com/clerk/clerk-sdk-python/blob/main/README.md#authenticating-machine-tokens) - [C# SDK](https://github.com/clerk/clerk-sdk-csharp?tab=readme-ov-file#machine-authentication) - [Java SDK](https://github.com/clerk/clerk-sdk-java?tab=readme-ov-file#machine-authentication) **Coming soon:** - Astro SDK - Nuxt SDK - PHP SDK - Go SDK - Ruby SDK - Expo SDK - iOS SDK If you're using one of the "coming soon" SDKs, you can verify OAuth tokens using [Clerk's REST API directly](https://clerk.com/docs/reference/backend-api/tag/OAuth-Access-Tokens#operation/verifyOAuthAccessToken): ```bash curl https://api.clerk.com/oauth_applications/access_tokens/verify \ -X POST \ -H 'Authorization: Bearer your-clerk-api-key-here' \ -H 'Content-Type: application/json' \ -d '{ "access_token": "your-oauth-token-here" }' ``` Want to help prioritize? Let us know [on our roadmap](https://feedback.clerk.com/roadmap) which SDK you need most! ### OAuth consent screen The new OAuth consent screen ensures users understand exactly what permissions they're granting before completing the OAuth flow. **The consent screen displays:** - The requesting application's name and logo - Specific scopes being requested in user-friendly language - Clear accept/deny options ![Clerk's OAuth consent screen](./consent-screen.png) In order to avoid breaking changes and security issues, we have implemented the following settings with respect to the consent screen - **New OAuth applications**: Consent screen enabled by default - **Existing OAuth applications**: Disabled by default (to avoid breaking changes), but we strongly recommend enabling it - **OAuth applications with dynamic client registration enabled**: Consent screen automatically enforced and cannot be disabled You can toggle the consent screen in the settings for any individual OAuth application [on the Clerk dashboard](https://dashboard.clerk.com/~/oauth-applications). ![A screenshot of the OAuth "consent screen" setting in the Clerk dashboard](./dashboard-oauth-consent-screen-toggle.png) We strongly recommend enabling the consent screen for all OAuth applications. Without a consent screen, any logged-in user who visits an OAuth authorization URL automatically grants access to any requested scopes. The consent screen acts as a critical security checkpoint, preventing malicious applications from silently gaining access to user accounts. ### Dynamic client registration Clerk now supports [dynamic client registration](https://datatracker.ietf.org/doc/html/rfc7591), allowing OAuth clients to be created programmatically via API in addition to [manually through the dashboard](https://dashboard.clerk.com/~/oauth-applications). You can enable this feature through a toggle in your [OAuth applications settings](https://dashboard.clerk.com/~/oauth-applications): ![A screenshot of the "enable dynamic client registration" setting in the Clerk dashboard](./dashboard-dynamic-client-registration.png) **What is dynamic client registration?** If you're unfamiliar with this OAuth extension, we cover it in detail (including real-world use cases and security considerations) in [our comprehensive OAuth guide](/blog/how-oauth-works#dynamic-client-registration), and [our documentation](/docs/oauth/how-clerk-implements-oauth#dynamic-client-registration). ### Building an MCP service using Clerk's OAuth server We've heard loud and clear from our users about the interest in leveraging OAuth to support [MCP](https://modelcontextprotocol.io) integrations. With this set of improvements to our OAuth capabilities, building MCP services that use Clerk as their authorization server becomes possible. MCP services often need to access user data from various sources on behalf of AI applications. This requires robust OAuth flows with proper consent management, token verification, and security controls - exactly what Clerk's enhanced OAuth features provide. The combination of dynamic client registration (for registering MCP servers programmatically), the consent screen (for secure user authorization), and comprehensive SDK support makes Clerk an ideal authorization server for MCP implementations. Imagine the following example of a real-world use case. Say you've built a project management tool using Clerk for authentication. With Clerk's OAuth server, you can easily expose an MCP endpoint that allows AI applications like Cursor, ChatGPT, Claude, or Windsurf to securely access your users' project data. Your users can authorize these AI tools through Clerk's consent screen, and the AI applications can then help with tasks like generating project summaries, suggesting optimizations, or automating workflows - all while maintaining secure, user-controlled access to your application's data. We will have another post coming soon that goes into detailed implementation of building MCP services using Clerk's OAuth server. In the meantime, if you'd like to peek behind the curtains, we have a reference implementation of an MCP service using next.js and Clerk [right here](https://github.com/clerk/mcp-nextjs-example). ### Custom scopes: coming soon We don't yet have support for adding custom OAuth scopes, we wanted to get these new OAuth features into our users' hands as quickly as they were usable and stable, which we feel like they are now. Next on our list is implementing a way that custom scopes can be added, accepted, and checked through our SDKs. We'll have another update coming your way soon when this feature is available! If you're interested in getting involved with early access for custom OAuth scopes, please add a vote and/or feedback to [the item on our roadmap here](https://feedback.clerk.com/roadmap?id=d2d88be9-4d4f-45e6-997e-61d0b2a34bc9) and we'll be in touch soon! ### Aside: didn't Clerk already have OAuth support? Sort of - while Clerk previously had [endpoints for OAuth](/docs/reference/frontend-api/tag/OAuth2-Identify-Provider#operation/getOAuthConsent), and [docs for how to configure it for SSO](https://web.archive.org/web/20250323153634/https://clerk.com/docs/advanced-usage/clerk-idp), this implementation was built specifically for [SSO integration with Shopify](/docs/integrations/shopify) and was lacking several critical features that are necessary for broad usage: - The OAuth access token returned was not accepted by any of Clerk's SDKs and did not have a method for verifying its authenticity, making it not very useful as an access token. - There was no OAuth consent page implemented, meaning that users going through the OAuth flow would not get the chance to review and accept scopes being requested by the third party. As long as the user was signed in, and visited an authorize link, the access request would be automatically accepted. There are some cases when only limited scopes are available and the flow is only being used for SSO where this can make sense (which was the case with the previous implementation), but outside of that it's a substantial security risk. - While PKCE was previously implemented in order to support public clients, Clerk's API would reject any requests to the token endpoint made from a browser due to incomplete CORS configuration, making the public client flow for most use cases non-functional. - The OAuth applications page in Clerk's dashboard had no pagination, so any more than 10 applications were not displayed and unable to be accessed at all. - There was no support for [dynamic client registration](https://datatracker.ietf.org/doc/html/rfc7591), an OAuth protocol extension that is a frequent requirement for use with MCP services. - There was no way to create custom scopes and add them to OAuth requests With the current release, all of these points (outside of the custom scopes, but that's coming very soon) are now resolved, and we feel confident that this is a *feature-complete* release of a built-in OAuth server for [OAuth scoped access](/blog/how-oauth-works#other-oauth-use-cases). --- ## Billing MRR Report - URL: https://clerk.com/changelog/2025-06-11-billing-mrr-report.md - Date: 2025-06-11 We've added a new MRR chart to the Subscriptions tab, making it easier to track revenue growth over time. ![Billing MRR Report feature showcase](./mrr-report.png) --- ## Improved Invoices - URL: https://clerk.com/changelog/2025-06-09-improved-invoices.md - Date: 2025-06-09 Before, all line items showed up with the same label, even if they referred to different features of the same product. That made it hard to tell what each charge was for. Now, items are grouped by their feature name. It's a much clearer view of what you're paying for. ![Invoice Preview](./invoice-preview.jpg) This is already live. No action needed. Next invoice should look a lot nicer. --- ## Subscription Payments - URL: https://clerk.com/changelog/2025-06-06-payment-history.md - Date: 2025-06-06 We've added a new Payments tab to both user and organization detail pages in the Dashboard. This feature gives you complete visibility into all subscription payment attempts, making it easier to track billing activity and troubleshoot payment issues. ![Subscription Payments feature showcase](./payments.png) --- ## All Time Sign-up Count in Dashboard - URL: https://clerk.com/changelog/2025-06-03-all-time-users-report.md - Date: 2025-06-03 For all you up-and-to-the-right folks, you can now view the total number of users who have ever signed up for your application directly from the dashboard, in this new handy chart. This new chart makes it easy to track your all time user growth at a glance and bask in that sweet-sweet hockey stick inflection. ![All Time Sign-up Count in Dashboard feature showcase](./total-signups.png) --- ## Redesigned Dashboard Overview - URL: https://clerk.com/changelog/2025-05-28-redesigned-dashboard-overview.md - Date: 2025-05-28 We've completely redesigned the Clerk Dashboard's overview page to focus on User Growth. Previously, we only tracked basic data points, but now we provide comprehensive retention and churn metrics that give you deeper insights into your user base. In the new charts we now show detailed insights like... - **New Users** - New Users - **Reactivated Users** - Inactive users who became active again - **Retained Users** - Existing users who remained active this period - **Retained churned** - Retained users who became inactive this period - **Reactivated churned** - Reactivated users that churned this period - **New users churned** - New users who churned this period Beyond the enhanced growth charts, we've introduced flexible time-based filtering options. You can now analyze your data across different time periods (Daily, Weekly, Monthly) and customize date ranges to gain deeper insights into your application's performance and user behavior patterns. Stay tuned for more planned improvements. --- ## Global support for Clerk Billing - URL: https://clerk.com/changelog/2025-05-13-billing-global-support.md - Date: 2025-05-13 When we launched Billing, the **Connect to Stripe** flow was locked to US-only businesses. Today, we've removed that constraint and Billing is now available in any country that's supported by Stripe ([see global availability](https://stripe.com/global)). Select your `Business Location` in the **Connect to Stripe** flow. If you find that the Business Location drop-down is still locked, you may need to disconnect the associated Stripe account and set up a fresh connection. Start building your global business with Clerk Billing today. --- ## Session Token JWT v2 - URL: https://clerk.com/changelog/2025-04-14-session-token-jwt-v2.md - Date: 2025-04-14 Key changes in v2 include a revamped structure for organization-related claims, now nested under the `o` claim for improved clarity and reduced token size. Additionally, a new `v` claim explicitly identifies the token version. As of today, April 14, 2025, version 1 of the session token format is deprecated. You can update to version 2 via the [**Updates** page](https://dashboard.clerk.com/~/updates) in your Clerk Dashboard. For a detailed breakdown of all claims available in v2 and how they differ from v1, please refer to our [Session Tokens documentation](/docs/backend-requests/resources/session-tokens). We strongly recommend using one of our SDKs that support API version [`2025-04-10`](/docs/versioning/available-versions#2025-04-10) to handle decoding reliably. --- ## Supabase Third-Party Auth Integration - URL: https://clerk.com/changelog/2025-03-31-supabase-integration.md - Date: 2025-03-31 Clerk is now supported as a [Supabase third-party authentication provider](https://supabase.com/docs/guides/auth/third-party/clerk). This first-class integration allows Supabase to accept Clerk-signed session tokens, removing the need to create a custom JWT template and generate a specific token when interacting with Supabase's APIs. Now, all you need to do is pass Clerk's session token to Supabase's client: ```ts import { createClient } from '@supabase/supabase-js' import { auth } from '@clerk/nextjs/server' const supabase = createClient( process.env.NEXT_PUBLIC_SUPABASE_URL!, process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!, { async accessToken() { return (await auth()).getToken() }, }, ) ``` ## Enable the integration To get started with Clerk and Supabase: 1. Visit the [Clerk dashboard](https://dashboard.clerk.com/setup/supabase) and go through the setup flow 2. Copy your Clerk instance domain into Supabase's [Third-party auth settings](https://supabase.com/dashboard/project/_/auth/third-party) For more information, visit the [Supabase Integration documentation page](/docs/integrations/databases/supabase). We can't wait to see what you build with Clerk and Supabase! --- ## Reverification - URL: https://clerk.com/changelog/2025-03-31-reverification.md - Date: 2025-03-31 Reverification is officially out of beta and is a great way to protect sensitive actions by requiring users to provide a step-up verification. As part of this release, we've also updated the `` component to require reverification for actions like password changes and email updates, you can find the complete list on our [documentation](https://clerk.com/docs/guides/reverification#sensitive-actions-that-require-reverification). ## How it works Our SDK includes straightforward hooks to manage reverification smoothly. Here's how to secure a Next.js server action: ```ts {{ filename: 'app/actions.ts' }} 'use server' import { auth, reverificationError } from '@clerk/nextjs/server' export const myAction = async () => { const { has } = await auth.protect() // Confirm the user's credentials have been recently verified const shouldUserRevalidate = !has({ reverification: 'strict' }) // Prompt reverification if recent verification is missing if (shouldUserRevalidate) { return reverificationError('strict') } // Proceed if reverification is successful return { success: true } } ``` ```tsx {{ filename: 'app/page.tsx' }} 'use client' import { useReverification } from '@clerk/nextjs' import { isReverificationCancelledError } from '@clerk/nextjs/errors' import { myAction } from '../actions' export default function Page() { const performAction = useReverification(myAction) const handleClick = async () => { try { const myData = await performAction() // ^ this is typed as { success: boolean } } catch (error) { if (isReverificationCancelledError(error)) { // Handle the case where the user cancels reverification } // Handle any errors that occur during the action } } return } ``` ### Compatibility - Support for Reverification is enabled for all new Clerk applications - For existing applications that want to enable Reverification, you will need to activate the Reverification APIs within the [Clerk Dashboard](https://dashboard.clerk.com/~/upgrades) - Native and mobile app support within our SDKs is still actively underway and will be available soon For all of the details around Reverification, explore our [documentation](/docs/guides/reverification). --- ## Flutter SDK Public Beta - URL: https://clerk.com/changelog/2025-03-26-flutter-sdk-beta.md - Date: 2025-03-26 This release includes both frontend ([`clerk_flutter`](https://pub.dev/packages/clerk_flutter)) and backend ([`clerk_backend_api`](https://pub.dev/packages/clerk_backend_api), [`clerk_auth`](https://pub.dev/packages/clerk_auth)) packages, enabling developers to build secure, cross-platform applications with ease. ## Key Features - **Complete Authentication Flow**: Sign up, sign in, and manage user profiles directly from your Flutter code - **Organization Support**: Full implementation of Clerk's organization features for managing multi-tenant applications - **Cross-Platform Compatibility**: Works seamlessly across iOS, Android, and web platforms - **Type-Safe API**: Built with Dart's strong typing system for better development experience - **Secure Backend Integration**: Separate backend package for secure server-side operations ## Getting Started Add the package to your `pubspec.yaml`: ```yaml dependencies: clerk_flutter: ^0.0.8-beta ``` ### Flutter Implementation Here's an example for how to initialize Clerk in your Flutter app: ```dart class ExampleApp extends StatelessWidget { const ExampleApp({super.key, required this.publishableKey}); final String publishableKey; @override Widget build(BuildContext context) { return ClerkAuth( config: ClerkAuthConfig(publishableKey: publishableKey), child: MaterialApp( theme: ThemeData.light(), debugShowCheckedModeBanner: false, home: Scaffold( body: SafeArea( child: ClerkErrorListener( child: ClerkAuthBuilder( signedInBuilder: (context, authState) { return const ClerkUserButton(); }, signedOutBuilder: (context, authState) { return const ClerkAuthentication(); }, ), ), ), ), ), ); } } ``` ### Server-side Usage The `clerk_auth` package also allows interaction with Clerk via dart on the server side, if necessary: ```dart import 'dart:io'; import 'package:clerk_auth/clerk_auth.dart'; Future main() async { final auth = Auth( config: const AuthConfig( publishableKey: '', ), persistor: await DefaultPersistor.create( storageDirectory: Directory.current, ), ); await auth.initialize(); await auth.attemptSignIn( strategy: Strategy.password, identifier: '', password: '', ); print('Signed in as ${auth.user}'); await auth.signOut(); auth.terminate(); } ``` ## Requirements - Flutter >= 3.10.0 - Dart >= 3.0.0 ## Beta Status This SDK is currently in beta. While we're confident in its functionality, we recommend: - Hard pinning to the patch version in your `pubspec.yaml` - Exercising caution before deploying to production - Testing thoroughly in your development environment ## Feedback We welcome your feedback during this beta period. Please share your thoughts, report issues, or suggest improvements on our [GitHub repository](https://github.com/clerk/clerk-sdk-flutter/issues). ## Acknowledgments Special thanks to [DevAngels](https://www.devangels.london/) for their exceptional work in developing this SDK. Their expertise in Flutter development has been instrumental in bringing Clerk's authentication capabilities to the Flutter ecosystem. --- ## Automatic emails to users signing in with an unrecognized devices - URL: https://clerk.com/changelog/2025-03-20-sign-in-emails.md - Date: 2025-03-20 Offer your users more peace of mind with email notifications for sign-ins from unfamiliar devices. This feature helps users identify potentially malicious activity and take action, such as revoking suspicious sessions. ### How It Works When a user signs in from an unrecognized device, Clerk sends an email notification to the account owner. The email includes essential details about the sign-in device, such as: - Device type - Operating system - IP address - Location - Sign-in method Like all emails delivered by Clerk, you can customize the template in the [Clerk Dashboard](https://dashboard.clerk.com/~/customization/email). And for supported instances, the email may also include a button to sign out from the unrecognized device immediately. ### Get Started New device sign-in emails are enabled by default for all new applications but are disabled by default for existing instances. For more information, visit the [Unauthorized Sign-In](/docs/security/unauthorized-sign-in) reference page in our docs. --- ## Introducing @clerk/agent-toolkit - URL: https://clerk.com/changelog/2025-03-7-clerk-agent-toolkit.md - Date: 2025-03-12 We're excited to introduce our `@clerk/agent-toolkit` package, a new experimental package designed to integrate Clerk into your AI agent workflows. This toolkit empowers developers to build powerful agentic systems with support for managing users, user data, organizations, and more. It's designed to work seamlessly with frameworks like Vercel's AI SDK and LangChain. Adding Clerk to your workflow is as simple as: ```typescript import { createClerkToolkit } from '@clerk/agent-toolkit/ai-sdk' import { openai } from '@ai-sdk/openai' import { streamText } from 'ai' import { auth } from '@clerk/nextjs/server' export async function POST(req: Request) { const { messages } = await req.json() // 1. Instantiate the toolkit const toolkit = await createClerkToolkit() const result = streamText({ model: openai('gpt-4o'), messages, system: systemPrompt, // 2. Pass the tools to the model tools: toolkit.users(), }) return result.toDataStreamResponse() } ``` Running a local MCP server is just as easy: ```shell npx -y @clerk/agent-toolkit -p local-mcp --secret-key sk_123 ``` ## Key Features - **Vercel AI SDK & LangChain support**: First-class support for Vercel's AI SDK and LangChain, with framework-specific helpers for each. - **Local MCP server support**: The `@clerk/agent-toolkit` package comes with a standalone local MCP server so you can easily integrate Clerk with any MCP client such as Claude Desktop. - **Session context injection**: Easily inject session claims (`userId`, `sessionId`, `orgId`) into system prompts for contextual awareness. - **Scoped helpers**: Support for scoping actions to specific users or organizations to limit resource access. ## Up Next - **Openai SDK support (coming soon)**: We're actively working on adding support for the `openai` SDK. Stay tuned for updates! ## Try it today Install the package using your preferred package manager and start building today: ```shell npm install @clerk/agent-toolkit ``` Check out our [example repository](https://github.com/clerk/agent-toolkit-example) and the package's [documentation](https://github.com/clerk/javascript/blob/main/packages/agent-toolkit/README.md) to learn more. We'd love to hear from you as you build. Your feedback will help shape the future of Clerk and AI. Reach out to [ai@clerk.dev](mailto:ai@clerk.dev). --- ## Clerk as an OpenID Connect provider - URL: https://clerk.com/changelog/2025-02-13-clerk-oidc.md - Date: 2025-02-13 Clerk now offers OpenID Connect (OIDC) support for your Clerk instance, making the authentication across third-party services even easier. This update provides greater flexibility, enhanced security, and more control over authentication flows. ## What's New? - **OpenID Connect (OIDC) support** – Authenticate with external services using industry-standard protocols and ID Tokens. - **OAuth application management in the Clerk Dashboard** – Configure and manage your settings directly from one central place. - **Support for multiple redirect URIs** - Seamlessly handle different environments (development, production) without extra work. - **Token introspection endpoint** - Validate and inspect Access and Refresh tokens securely, ensuring better control over access management. - **Improved authentication control** – Support for `none` and `login` prompts, giving you finer control over user authentication. ## Upgrade from the legacy OAuth 2.0 provider For any Clerk application which already using the legacy OAuth 2.0 provider, migrating to take advantage of the new OpenID Connect (OIDC) compatible provider is a self-service process. Simply migrate directly from the [Clerk Dashboard](https://dashboard.clerk.com/~/oauth-applications) to utilize the new and improved functionality. ## Try it today Get started today by creating your first OAuth application, visiting the [Clerk Dashboard](https://dashboard.clerk.com/~/oauth-applications). To learn more visit our [documentation page](/docs/advanced-usage/clerk-idp). --- ## Passkeys support for Expo - URL: https://clerk.com/changelog/2025-02-10-expo-passkeys.md - Date: 2025-02-10 We're excited to announce native Passkeys support for Clerk's Expo SDK. ## Implementation Adding Passkeys support to your Expo app is straightforward using the `user.createPasskey()` method from `useUser()` hook and the `signIn.authenticateWithPasskey()` method from `useSignIn()` hook. ### Create a Passkey ```tsx const CreatePasskeyPage = () => { const { user } = useUser() const handlePasskeySignIn = async () => { if (!user) return try { return await user.createPasskey() } catch (e: any) { // Handle errors } } } ``` ### Sign in with Passkey ```tsx const SignInWithPasskeyPage = () => { const { signIn } = useSignIn() const handlePasskeySignIn = async () => { try { const signInAttempt = await signIn?.authenticateWithPasskey({ flow: 'discoverable', }) if (signInAttempt?.status === 'complete') { await setActive({ session: signInAttempt.createdSessionId }) router.push('/') } else { // Handle errors } } catch (err) { // Handle errors } } } ``` ## Getting Started To implement Passkeys in your Expo application: 1. Enable Passkeys in your [Clerk Dashboard](https://dashboard.clerk.com/~/user-authentication/email-phone-username) 2. Follow our [Passkeys integration guide](/docs/references/expo/passkeys) for detailed setup instructions ## Platform Support - iOS 16.0 or later - Android 9+ or later Visit our [documentation](/docs/references/expo/passkeys) to learn more about implementing Passkeys in your Expo application. --- ## SAML Native Flows - URL: https://clerk.com/changelog/2025-02-05-saml-native.md - Date: 2025-02-05 We're excited to announce support for SAML on both Expo and iOS SDKs. Visit our documentation for step-by-step integration guides with [`@clerk/expo`](/docs/references/expo/use-sso) or [iOS](https://clerk.github.io/clerk-ios/documentation/clerk/signin/authenticatewithredirectstrategy) --- ## Ruby Backend SDK 4.0 - URL: https://clerk.com/changelog/2025-01-30-ruby-sdk-4.md - Date: 2025-01-30 We're excited to announce the release of the Clerk Ruby Backend SDK 4.0! Below is a quick preview of the major changes that we've made. ## First-Class Framework Support In the past, outside of the standard Rails configuration, you had to create your own adapters and helpers to work with Clerk. With this release, we've added or expanded on first-class support for Rails, Rails API, Sinatra, and Rack so that everything works out of the box for the most popular frameworks and configurations. Here's a quick preview of what 4.0 offers: ```ruby {{ title: 'Standalone SDK Usage' }} Clerk.configure do |config| config.secret_key = 'sk_live_*****' end sdk = Clerk::SDK.new sdk.users.get_user('*****') ``` ```ruby {{ title: 'Ruby on Rails' }} class AdminController < ApplicationController include Clerk::Authenticatable def index @user = clerk.user end end ``` ```ruby {{ title: 'Sinatra' }} # Sinatra class App < Sinatra::Base register Sinatra::Clerk get "/admin" do @user = clerk.user erb :index, format: :html5 end end ``` ## OpenAPI We've also brought the SDK into full alignment with our Backend API thanks to now generating parts of the SDK from our [OpenAPI spec](https://github.com/clerk/openapi-specs). You can view the full generated [documentation on GitHub](https://github.com/clerk/clerk-http-client-ruby/tree/main/.generated#documentation-for-api-endpoints). ## Upgrading Upgrade your gem by installing version `~> 4.0.0`: ```ruby {{ filename: 'Gemfile' }} gem 'clerk-skd-ruby', '~> 4.0.0', require: 'clerk' ``` ## Breaking Changes Please note that this release contains a number of breaking changes. Please refer to the [upgrade guide](/docs/references/ruby/v4-upgrade-guide) for more information. --- ## Member search added to - URL: https://clerk.com/changelog/2025-01-28-search-on-org-profile.md - Date: 2025-01-28 Our `` component now supports searching across various member details such as email addresses, phone numbers, web3 wallets, usernames, user IDs, and first or last names. The search supports partial matches, making it easier than ever to locate the member you need. Check it out now on your [``](/docs/components/customization/organization-profile) component! --- ## Stable release of React Router SDK - URL: https://clerk.com/changelog/2025-01-23.md - Date: 2025-01-23 Back in December we announced the [Beta release of our React Router SDK](/changelog/2024-12-12-react-router-beta), a new official SDK that allows developers to add authentication and authorization into their React Router application in a matter of minutes. After fixing some bugs and receiving positive feedback on the SDK we're transitioning the React Router SDK from beta to stable. The best part? You can just upgrade! There are **no changes** between the beta and stable release. Upgrade your package by installing version `^1.0.0`: ```shell npm install @clerk/react-router@latest ``` --- ## Combined sign-in-or-up - URL: https://clerk.com/changelog/2025-01-16-sign-in-or-up.md - Date: 2025-01-16 The `` component now allows users to sign up if they don't already have an existing account. When attempting a sign-in and no existing account is found, users will be prompted to continue through the flow to create an account, without needing to navigate to a separate route where `` is mounted. The combined flow is a great option when email-based authentication strategies are used, as the sign-in and sign-up flows tend to be very similar. To start using the combined sign-in-or-up flow, remove your existing `` usage, and unset `CLERK_SIGN_UP_URL`. Your existing `` component will now handle sign ups. While this is the new default behavior, you can opt out of the combined flow by defining your `CLERK_SIGN_UP_URL`. For more information, including how to build a dedicated `` page, visit the [documentation](/docs/references/nextjs/custom-sign-up-page). --- ## End of Support for Node SDK - URL: https://clerk.com/changelog/2025-01-10-node-sdk-eol.md - Date: 2025-01-10 Today marks the end of support for `@clerk/clerk-sdk-node` as previously announced in our [October 2024 deprecation notice](/changelog/2024-10-08-express-sdk#deprecating-clerk-clerk-sdk-node). While we will no longer maintain this package, we've ensured a smooth transition path for all our users. ## What This Means - The `@clerk/clerk-sdk-node` package has been moved to a separate [repository](https://github.com/clerk/sdk-node) for archival purposes - Express users can migrate to the `@clerk/express` package, [see migration guide](/docs/upgrade-guides/node-to-express) - Other Node.js projects should use our [JavaScript Backend SDK](/docs/references/backend/overview) --- ## C# Backend SDK - URL: https://clerk.com/changelog/2025-01-09-csharp-sdk.md - Date: 2025-01-09 Check out the new server-side [C# SDK right here](https://github.com/clerk/clerk-sdk-csharp)! With this launch, C# developers can more easily interface with the [Clerk Backend API](/docs/reference/backend-api) to manage users, organizations, and sessions. ```csharp {{ title: 'Clerk Backend API call' }} using Clerk.BackendAPI; using Clerk.BackendAPI.Models.Operations; using Clerk.BackendAPI.Models.Components; var sdk = new ClerkBackendApi(bearerAuth: ""); var res = await sdk.EmailAddresses.GetAsync(emailAddressId: "email_address_id_example"); // handle response ``` This release also makes it straightforward to authenticate backend requests in ASP.NET, Blazor, and other C# web frameworks: ```csharp {{ title: 'authenticateRequest in action' }} using Clerk.BackendAPI.Helpers.Jwks; using System; using System.Net.Http; using System.Threading.Tasks; public class UserAuthentication { public static async Task IsSignedInAsync(HttpRequestMessage request) { var options = new AuthenticateRequestOptions( secretKey: Environment.GetEnvironmentVariable("CLERK_SECRET_KEY"), authorizedParties: new string[] { "https://example.com" } ); var requestState = await AuthenticateRequest.AuthenticateRequestAsync(request, options); return requestState.isSignedIn(); } } ``` You can use NuGet to install the new [`Clerk.BackendAPI`](https://www.nuget.org/packages/Clerk.BackendAPI) module via `dotnet add package Clerk.BackendAPI`. To help you from there, we've prepared [detailed reference documentation](https://github.com/clerk/clerk-sdk-csharp?tab=readme-ov-file#summary) in the SDK's GitHub repository. *Special thanks to [Speakeasy](https://www.speakeasy.com/) for partnering with us on this SDK release 🎉*! --- ## Official SDK for Vue and Nuxt - URL: https://clerk.com/changelog/2025-01-07-vue-and-nuxt-sdk.md - Date: 2025-01-07 We're excited to announce `@clerk/vue` and `@clerk/nuxt`, two new *official* SDKs that allow developers to add authentication and authorization into their Vue and Nuxt applications in a matter of minutes. Both SDKs come fully equipped with Clerk's UI components, composables, and low-level utilities for your custom flows. ## Use Clerk UI components Clerk's pre-built UI components give you a beautiful, fully-functional user and organization management experience in minutes. Here's an example on how to use the `` component in Vue. ```vue {{ filename: 'pages/sign-in.vue' }} ``` ## Protect API routes For Nuxt users, use the `auth` context to restrict unauthorized access to your API routes. ```ts {{ filename: 'server/api/me.ts' }} import { clerkClient } from '@clerk/nuxt/server' export default eventHandler(async (event) => { const { userId } = event.context.auth if (!userId) { setResponseStatus(event, 401) return 'Unauthorized' } const user = await clerkClient(event).users.getUser(userId) return { user } }) ``` This is only a quick preview of all that `@clerk/vue` and `@clerk/nuxt` offer. For more information on the available APIs and how to get started building Vue and Nuxt applications with Clerk, check out our [Vue Quickstart guide](/docs/quickstarts/vue) and [Nuxt Quickstart guide](/docs/quickstarts/nuxt). We extend our gratitude to all contributors of the previous [community SDK for Vue](https://github.com/wobsoriano/vue-clerk), which served as the foundation for these official releases. --- ## URL-based active organization sync - URL: https://clerk.com/changelog/2024-12-20-sync-org-with-url.md - Date: 2024-12-20 `clerkMiddleware()` now supports configuration to detect an organization by slug in a request's URL and automatically set that organization as active for the current session. Any client-side logic to handle syncing a session's active organization with the current URL can now be removed! ## Try it today To start using URL-based active organization syncing, see the [`clerkMiddleware()` documentation](https://clerk.com/docs/references/nextjs/clerk-middleware#organizationsyncoptions). To learn more about best practices for using organization slugs to manage the active organization, check out the [new guide](/docs/organizations/org-slugs-in-urls). --- ## Enterprise Connections for Organizations - URL: https://clerk.com/changelog/2024-12-18-sso-per-org.md - Date: 2024-12-18 After linking an organization to an enterprise connection, whenever users authenticate with their IdP, new sign-ups will automatically be added to the linked organization with the organization's default role and that organization will be set as active on the client side. Sign-ins will have the linked organization automatically set as their currently active organization. If you're an application owner that previously found yourself detecting new sign-ups and sign-ins in an attempt to orchestrate the joining and setting active of an organization, all that code can now be removed. Linked organizations are available for all enterprise connection types (SAML, OIDC, and [EASIE](https://easie.dev)) and we are planning to support more configurable enrollment modes in the future. ## Try it today If you have existing enterprise connections, head to [Configure / SSO Connections](https://dashboard.clerk.com/~/user-authentication/sso-connections) and link your customer's organizations through the Clerk Dashboard. If you're looking for more detail, read through our full guide on how to configure an enterprise connection for an organization by visiting our [Manage Organization SSO](/docs/organizations/manage-sso) page. --- ## Improved offline support for Expo - URL: https://clerk.com/changelog/2024-12-12-expo-offline-support.md - Date: 2024-12-12 We're excited to announce experimental offline support for Clerk's Expo SDK. This update significantly improves how Expo applications using Clerk handle network connectivity issues. ## Key Features - Initialization of the Clerk SDK is now more resilient to network failures. - Faster resolution of the `isLoaded` property and the `` control component. - Network errors are no longer muted, allowing developers to catch and handle them effectively in their custom flows. - The `getToken()` function in the `useAuth()` hook now supports returning cached tokens, minimizing disruptions caused by network failures. ## How to use To try out the experimental offline support features, visit our [documentation](/docs/references/expo/offline-support) for step-by-step integration instructions for your Expo project. --- ## React Router SDK Beta - URL: https://clerk.com/changelog/2024-12-12-react-router-beta.md - Date: 2024-12-12 We're excited to announce the beta release of `@clerk/react-router`, a new official SDK that allows developers to add authentication and authorization into their React Router application in a matter of minutes. The SDK comes fully equipped with Clerk's UI components, server utilities, and low level utilities for any of your custom flows. You can use React Router both as a framework or library with Clerk. If you want to dive right into it, head over to our [React Router quickstart](/docs/quickstarts/react-router). ## Use Clerk UI components Clerk's pre-built UI components give you a beautiful, fully-functional user and organization management experience in minutes. Here's an example on how simple it is to build a sign-in page using Clerk's `` component inside your React Router applications. ```tsx {{ filename: 'app/routes/sign-in.tsx' }} import { SignIn } from '@clerk/react-router' export default function SignInPage() { return } ``` ## Server functions You can also pair our `getAuth()` utility function with React Routers's server data loading to protect your routes. ```tsx {{ filename: 'app/routes/profile.tsx' }} import { redirect } from 'react-router' import { getAuth } from '@clerk/react-router/ssr.server' import { createClerkClient } from '@clerk/react-router/api.server' import type { Route } from './+types/profile' export async function loader(args: Route.LoaderArgs) { const { userId } = await getAuth(args) if (!userId) { return redirect('/sign-in?redirect_url=' + args.request.url) } const user = await createClerkClient({ secretKey: process.env.CLERK_SECRET_KEY }).users.getUser( userId, ) return { user: JSON.stringify(user), } } export default function Profile({ loaderData }: Route.ComponentProps) { return

Hello! Your user id is {loaderData.user.id}

} ``` You can learn more about `@clerk/react-router` in the React Router [reference documentation](/docs/references/react-router/overview). --- ## Enterprise Connections for Custom OAuth Providers - URL: https://clerk.com/changelog/2024-12-11-custom-oauth-ent-connections.md - Date: 2024-12-11 We're excited to announce that in addition to EASIE and SAML, you can now enable enterprise single sign-on through any OpenID Connect (OIDC) compliant provider. ## Authenticate with Enterprise SSO To support this, we have added a new authentication strategy to our SDKs, `enterprise_sso`. This strategy lets you start an enterprise sso flow with a single method, regardles if the users will be signing in through OIDC, SAML, or EASIE. ## Get started To learn how to configure a provider, visit our [setup guide](/docs/authentication/enterprise-connections/oidc/custom-provider) or explore our [enterprise connections documentation](/docs/authentication/enterprise-connections/overview) to discover how enterprise SSO works in Clerk. --- ## Reverification: Public Beta - URL: https://clerk.com/changelog/2024-12-02-reverification-beta.md - Date: 2024-12-02 Our new **reverification** feature protects sensitive actions by requiring that users have verified their credentials recently. If not, the user is prompted to verify their credentials again. ## How it works Our SDK has been updated with new backend and frontend helpers to detect and coordinate a reverification flow. This is how you can protect a Next.js route handler: ```ts {{ filename: '/app/api/transfer/route.ts' }} import { auth, reverificationErrorResponse } from '@clerk/nextjs/server' export const POST = async (request: Request) => { const { has } = await auth() // Check if the user has *not* verified their credentials within the past 10 minutes. const shouldUserReverify = !has({ reverification: 'strict' }) // If the user hasn't reverified, return an error with the matching configuration (e.g., `strict`) if (shouldUserReverify) { return reverificationErrorResponse('strict') } const { amountInCents } = await request.json() // Now that the user has verified credentials, let's perform the sensitive action const updatedResource = await db.updateBalance(amountInCents) return new Response(JSON.stringify(updatedResource)) } ``` Then, from the frontend, you can configure fetch to listen for the reverification error and prompt the user for reverification. You can use our new `useReverification()` helper for this: ```tsx {{ filename: '/app/transfer/page.tsx' }} 'use client' import { useReverification } from '@clerk/nextjs' export default function Page({ amountInCents }: { amountInCents: number }) { const [transferMoney] = useReverification(() => fetch('/api/transfer', { method: 'POST', body: JSON.stringify({ amountInCents }), }), ) return } ``` Whenever Clerk identifies that a user needs to verify their credentials, a modal will appear, similar to the one shown in the image. ![reverification component](./reverification-ui.png) ## Get started Visit the [reverification guide](/docs/guides/reverification) to discover examples on how to integrate this feature into your application today. --- ## Chrome Extension SDK 2.0 - URL: https://clerk.com/changelog/2024-11-22-chrome-extension-sdk-2-0.md - Date: 2024-11-22 We're excited to release version 2.0 of the Chrome Extension SDK. Version 2.0 comes with the new `createClerkClient()` helper for background service workers, improved support for syncing auth state with your web application and detailed documentation for the SDK. Take a look at our [Chrome Extension Quickstart](/docs/quickstarts/chrome-extension) if you're just getting started, or read over the [Chrome Extension documentation](/docs/quickstarts/chrome-extension) to learn about all of the features. Our [Chrome Extension Quickstart repo](https://github.com/clerk/clerk-chrome-extension-quickstart) and [Chrome Extension Demo repo](https://github.com/clerk/clerk-chrome-extension-demo) are a great reference or starting point for a project. ## Introducing `createClerkClient()` for Service Workers Chrome Extensions pose a unique challenge for developers using Clerk. When the popup or side panel is closed, the Clerk session cookie will become stale. The `createClerkClient()` function is specifically designed to allow extension developers to refresh the user's session, obtain a valid token or other auth, and retrieve user data. ```ts {{ filename: 'src/background/index.ts' }} import { createClerkClient } from '@clerk/chrome-extension/background' const publishableKey = process.env.PLASMO_PUBLIC_CLERK_PUBLISHABLE_KEY // create a new Clerk instance and get a fresh token for the user async function getToken() { const clerk = await createClerkClient({ publishableKey, }) // if there is no user session, then return nothing if (!clerk.session) { return null } // return the user's token return await clerk.session?.getToken() } // create a listener to listen for messages from content scripts chrome.runtime.onMessage.addListener((request, sender, sendResponse) => { console.log('Handling request for the users current token') getToken() .then((token) => { sendResponse({ token }) }) .catch((error) => { console.error('[Service Worker]: Error occured -> ', JSON.stringify(error)) sendResponse({ token: null }) }) return true // REQUIRED: Indicates that the listener responds asynchronously. }) ``` You can now send a message from a content script to the background service worker and get auth status or a token for the user. ```tsx {{ filename: 'src/tabs/content.tsx' }} // send a message to the background service worker chrome.runtime.sendMessage({ greeting: 'get-token' }, (response) => { // you can now have access to the user's token console.log(response.token) }) ``` ## Breaking Changes - `syncSessionWithTab` has been removed and replaced with `syncHost`. [Changelog](https://github.com/clerk/javascript/blob/main/packages/chrome-extension/CHANGELOG.md) [Sync Host Guide](https://clerk.com/docs/references/chrome-extension/sync-host) - The `storage` host permission is now required. [Changelog](https://github.com/clerk/javascript/blob/main/packages/chrome-extension/CHANGELOG.md) --- ## Waitlist mode - URL: https://clerk.com/changelog/2024-11-20-waitlist-sign-up-mode.md - Date: 2024-11-20 Launching a new product but not ready to open it up to everyone yet? **Waitlist Sign-up mode** is here to help you manage early access seamlessly. ## What's New? With Waitlist Sign-up mode, you have complete control over onboarding new users: - Your `` component collects prospective users’ email addresses. - These users are added to a **Waitlist queue** in your [Clerk Dashboard](https://dashboard.clerk.com/~/user-authentication/restrictions). - You decide which entries get accepted or rejected. Or simply invite new users directly. - Once your product is ready for the world, just switch your Sign-up mode to **public** and you're live 🚀. ![Waitlist component UI](./component.png) ## Give it a try - Visit your [Clerk Dashboard](https://dashboard.clerk.com/~/user-authentication/restrictions). - Learn more about the [Waitlist Sign-Up Mode](/docs/authentication/configuration/restrictions#waitlist). --- ## Legal consent - URL: https://clerk.com/changelog/2024-11-11-legal-consent.md - Date: 2024-11-11 Keep your application compliant by requiring legal consent on your application's `` views. If you are using Clerk’s pre-built component or the Account Portal, simply enable it from the [Clerk Dashboard](https://dashboard.clerk.com/~/compliance/legal). Your users will be required to accept your legal documents before they are allowed to create an account, and you will have one less compliance issue to worry about. ![SignUp component with legal consent enabled](./ui.png) ## Ready to dive in? Head to your [Clerk Dashboard](https://dashboard.clerk.com/~/compliance/legal), or check out [the documentation](/docs/authentication/configuration/legal-compliance) to get started. ![Legal consent configuration screen on Dashboard](./dashboard.png) --- ## Export your users directly from the Dashboard - URL: https://clerk.com/changelog/2024-10-23-export-users.md - Date: 2024-10-23 Previously, your user exports weren't as accessible as we would have liked. Customers had to export via our [Backend API](/bapi) or if you needed hashed passwords, you had to rely on our support team to trigger a user export. Now you can easily generate and download a CSV export of your users, all within the [Clerk Dashboard](https://dashboard.clerk.com/). ### Key Features: - **Settings Page**: This new feature is added to the dashboard Settings. - **Export and Download Logs**: The Settings page also includes a table displaying logs for both export requests and downloads, providing a complete history of export activities. - **Real-time export management**: Trigger user exports with the new "Export All Users" button. Track progress in real-time with status updates displayed on the Exports logs table on the Settings page, including when the file is ready for download. - **Automatic notifications**: Once the export completes, you’ll receive a toast notification and can download the CSV file directly from the dashboard. - **Flexible navigation**: You can navigate away or switch tabs without interrupting the export process, and you’ll still get notified when the export is done. ### Other Details: - The download button remains visible until the file expires, allowing you to download the list at any time before requesting a new one. - The export is restricted to admins (or users in their personal workspace), ensuring the feature is secure and accessible only to authorized users. --- ## @clerk/nextjs v6 - URL: https://clerk.com/changelog/2024-10-22-clerk-nextjs-v6.md - Date: 2024-10-22 The Next.js team has [announced the stable release of Next.js 15](https://nextjs.org/blog/next-15), and Clerk is continuing the tradition of (nearly) same-day support for new major Next.js releases with the release of `@clerk/nextjs` v6. Get started by running the Clerk upgrade CLI: ``` npx @clerk/upgrade ``` Not ready to upgrade to Next.js v15? No problem: `@clerk/nextjs` v6 is backwards compatible with Next.js v14, including the switch to static rendering by default. ## Asynchronous `auth()` (breaking change) Now that [Next.js's request APIs are asynchronous](https://nextjs.org/blog/next-15-rc2#async-request-apis-breaking-change), Clerk's `auth()` helper will follow suit. In addition to supporting Next.js's new async APIs, this change will also allow the addition of more robust validations and new functionality into the `auth()` helper. Stay tuned! ```tsx import { auth } from '@clerk/nextjs/server' export default async function Page() { const { userId } = await auth() if (!userId) { return

Hello, guest!

} return

Hello, {userId}!

} ``` With the change to async, we weren't happy with how the usage of `auth().protect()` felt, so we moved `protect` to be a property of `auth`, instead of part of the return value. ```tsx import { auth } from '@clerk/nextjs/server' export default async function Page() { const { userId } = await auth.protect() return

Hello, {userId}!

} ``` To make migration as easy as possible, we're also including a codemod that will update your usages of `auth()` and `auth().protect()`. For situations where the codemod isn't able to update your code, please see the [upgrade guide](/docs/upgrade-guides/nextjs/v6) for detailed steps. ## Static rendering by default, opt-in dynamic (and partial prerendering support) Historically, usage of `` has opted your entire application in to dynamic rendering due to the dynamic and personalized nature of auth-related data. We've heard the feedback from our users that this default didn't feel like it aligned with Next.js best practices. Starting with v6, **`` will no longer opt your entire application into dynamic rendering by default.** This change also brings support for Next.js's upcoming [Partial Prerendering mode (PPR)](https://nextjs.org/docs/app/building-your-application/rendering/partial-prerendering). PPR allows a page to be both static *and* dynamic by moving the optimization from pages to components. Dynamic auth data is still available by using the `auth()` helper in a server component. This data can also be passed to client components directly as needed. This is the recommended way to access auth data going forward. For existing applications that use the `useAuth()` hook in Client Components that are server-side rendered, this is a breaking change. Wrap these components in `` to make auth data available to the hook during rendering. As a best practice, we recommend wrapping usage of `` with suspense to ensure your page is setup to take advantage of PPR. ```tsx import { Suspense } from 'react' import { ClerkProvider } from '@clerk/nextjs' export default function Page() { return (
}>
) } ``` If you want `` to continue making dynamic auth data available by default, add the `dynamic` prop to your root ``: ```tsx import { ClerkProvider } from '@clerk/nextjs' export default function RootLayout({ children }) { return ( {children} ) } ``` This opts every single page into dynamic rendering, or PPR when enabled. For this reason, it is still recommended to take a more granular approach to dynamic data access by using `` further down your component tree. To learn more about Next.js's different rendering modes and how Clerk interacts with them, check out the [documentation](/docs/references/nextjs/rendering-modes). ## Removal of deprecated APIs A number of deprecated APIs have been removed as part of this release: - `authMiddleware()` - use `clerkMiddleware()` instead - `redirectToSignIn()` - use `const { redirectToSignIn } = await auth()` instead - `redirectToSignUp()` - use `const { redirectToSignUp } = await auth()` instead - `clerkClient` singleton - use `await clerkClient()` instead For more information, please see the [upgrade guide](/docs/upgrade-guides/nextjs/v6). --- ## Fastify SDK 2.0 - URL: https://clerk.com/changelog/2024-10-10-fastify-v5-support.md - Date: 2024-10-11 Fastify, the fast and low overhead web framework for Node.js, has recently shipped Fastify v5. In order to support Fastify v5 a new major version of `@clerk/fastify` had to be released. With Clerk's Fastify SDK 2.0 comes full support for Fastify v5 and no breaking changes for the Clerk SDK itself. If you're using Fastify and `@clerk/fastify`, you can update like so: 1. Follow the official [Fastify v5 migration guide](https://fastify.dev/docs/latest/Guides/Migration-Guide-V5/) 2. Install the latest version of `@clerk/fastify` ```shell npm install @clerk/fastify@latest ``` 3. You're done! No further changes needed `@clerk/fastify@^2.0.0` only supports Fastify v5 or later, if you want/need to continue using Fastify v4, please stick with `@clerk/fastify@^1.0.0`. --- ## Express SDK - URL: https://clerk.com/changelog/2024-10-08-express-sdk.md - Date: 2024-10-08 We're excited to announce the release of [`@clerk/express`](/docs/quickstarts/express), our latest SDK designed specifically for [Express applications](https://expressjs.com/). The SDK comes fully equipped with server utilities and low level utilities for any of your custom flows. Here's an example on how simple it is to protect a route with our Express SDK: ```ts import express from 'express' import { requireAuth } from '@clerk/express' const app = express() // if the user is not signed in, they will be redirected to /sign-in automatically app.get('/protected', requireAuth({ signInUrl: '/sign-in' }), (req, res) => { return res.json({ userId: req.auth.userId }) }) ``` ### Deprecating @clerk/clerk-sdk-node With this release, we are initiating the process to deprecate `@clerk/clerk-sdk-node`. During this transition period, we intend to: - Continue to provide critical patches and bug fixes for `@clerk/clerk-sdk-node` - Pause adding new features to `@clerk/clerk-sdk-node` - Focus our development efforts on `@clerk/express` The transition to end `@clerk/clerk-sdk-node` support ends on January 8, 2025. To ensure a smooth transition, we've prepared a comprehensive [Migration Guide](/docs/upgrade-guides/node-to-express) with step-by-step instructions. Upgrade today and experience enhanced authentication and user management in your Express projects with Clerk! --- ## Python Backend SDK - URL: https://clerk.com/changelog/2024-10-08-python-backend-sdk-beta.md - Date: 2024-10-08 We're pleased to announce the release of our server-side [Python SDK](https://github.com/clerk/clerk-sdk-python)! With this launch, Python developers can more easily interface with the [Clerk Backend API](/docs/reference/backend-api) to manage users, organizations, and sessions. ```python {{ title: 'Asynchronous backend API call with asyncio' }} import asyncio from clerk_backend_api import Clerk async def main(): sdk = Clerk( bearer_auth="", ) res = await sdk.email_addresses.get_async( email_address_id="email_address_id_example" ) if res is not None: # handle response pass asyncio.run(main()) ``` This release also makes it straightforward to authenticate backend requests in Django, Flask, and other Python web frameworks: ```python {{ title: 'authenticateRequest in action' }} import os import httpx from clerk_backend_api import Clerk from clerk_backend_api.jwks_helpers import AuthenticateRequestOptions def is_signed_in(request: httpx.Request): sdk = Clerk(bearer_auth=os.getenv('CLERK_SECRET_KEY')) request_state = sdk.authenticate_request( request, AuthenticateRequestOptions( authorized_parties=['https://example.com'] ) ) return request_state.is_signed_in ``` You can `pip install` the new [`clerk-backend-api`](https://pypi.org/project/clerk-backend-api/) module in any Python 3.8+ application to get started. To help you from there, we've prepared [detailed reference documentation](https://github.com/clerk/clerk-sdk-python/blob/main/README.md) in the SDK GitHub repository. *Special thanks to [Speakeasy](https://www.speakeasy.com/) for partnering with us on this SDK release 🎉*! --- ## Consolidating SSO Connections in the Dashboard - URL: https://clerk.com/changelog/2024-10-03-sso-connections-page.md - Date: 2024-10-03 We've made an update to the [Clerk Dashboard](https://dashboard.clerk.com/~/user-authentication/sso-connections) that consolidates "Social Connections" and "Enterprise Connections" into one unified view. We found through working with our customer's that this distinction was unclear and having to manage these in different places felt unintuitive. Going forward you can simply select the **Add connection** and choose whether you're attempting to set up a connection for all of your users, or only for users of a specific domain. ![Consolidated SSO Connections](./image.png) --- ## Clerk + Coinbase Developer Platform: Advancing tools for the Web3 ecosystem - URL: https://clerk.com/changelog/2024-10-01-coinbase-smart-wallet.md - Date: 2024-10-01 We're excited to announce that Clerk has teamed up with Coinbase to make building Web3 applications easier. As a first step, Clerk released a new API today that allows developers to quickly integrate a customer's [Coinbase Wallet](https://www.coinbase.com/en-gb/wallet) with their Clerk user account. In addition, Clerk's embeddable `` and `` components now support authentication with Coinbase Wallet. [Read our documentation to get started](/docs/authentication/web3/coinbase-wallet). `` with Coinbase Wallet and `` with Coinbase connection: ![SignIn with Coinbase Wallet and UserProfile with Coinbase connection](./ui.png) Coinbase Wallet is a user-friendly, self-custodial solution that simplifies onchain transactions. Secured by Passkeys, it allows applications to cover gas fees, enabling users to pay with their Coinbase balance. This streamlined approach makes blockchain interactions more accessible, eliminating complex setups and lowering entry barriers to use products onchain. Developers building with Clerk can now seamlessly connect user management with Coinbase Wallet functionality. This offers a path to building Web3 applications that prioritize speed of development, security, and ease of use. We envision a future where identity-based enablement allows for more autonomous, efficient, and secure payment systems. By leveraging Clerk's user management capabilities, developers building on Coinbase Developer Platform are provided with a powerful suite of tools that goes beyond wallet integration – including robust session management, authorization controls, and tools for better customer engagement and retention. We're eager to see how developers use these tools to more easily create new possibilities in Web3, and we're thrilled to deepen our collaboration with Coinbase Developer Platform to simplify onchain application development. --- ## Disable additional identifiers for users who sign-in with Enterprise connections - URL: https://clerk.com/changelog/2024-09-30-disable-additional-accounts-for-saml.md - Date: 2024-09-30 Administrators now have more control over the behavior of `` when their users authenticate via an Enterprise Connection. This is particularly useful when a B2B customer has strict policies regarding the management of user account information through their IdP (Identity Provider). Moving forward, additional identifiers will no longer be allowed by default. For existing connections, you are able to adjust this setting in the [Advanced tab](https://dashboard.clerk.com/~/user-authentication/enterprise-connections) of each Enterprise Connection in the dashboard. ![Disable Additional Identifiers](./clerk-dashboard-disable-additional-identifiers.jpg) --- ## Say goodbye to unwanted sign-ups with Restricted mode - URL: https://clerk.com/changelog/2024-09-30-restricted-sign-up-mode.md - Date: 2024-09-30 Whether you're in stealth-mode, running a private beta, or want to only ever manually onboard your customers, we know managing user access can be extremely important. So allow us to introduce our newest sign-up mode: **Restricted** ## What’s new? In contrast to the *Public* sign-up mode that allows for anyone to sign-up to your application, *Restricted* mode means you have full control over your sign-ups. Use our [Backend APIs](/bapi) or the [Clerk Dashboard](https://dashboard.clerk.com/) to manage who gets access. Only users who have received invitations will have the ability sign-up. As mentioned, this can be helpful for use-cases where you want to tightly control who has access to your application whether by inviting folks individually or only supporting previously onboarded B2B customers via [Enterprise SSO](/docs/authentication/saml/overview). ## Ready to dive in? Head to your [Clerk Dashboard](https://dashboard.clerk.com/~/user-authentication/restrictions), or check out [how to enable Restricted sign up mode](/docs/authentication/configuration/restrictions#restricted) to get started. --- ## TanStack Start SDK Beta - URL: https://clerk.com/changelog/2024-09-11-tanstack-start-beta.md - Date: 2024-09-11 > \[!NOTE] > This package has been renamed from `@clerk/tanstack-start` to `@clerk/tanstack-react-start` to better align with TanStack's own package naming convention. [TanStack Start](https://tanstack.com/start/latest) is an exciting new full-stack React framework that provides tons of great functionality like full-document SSR, streaming, server functions, bundling, and more. It's built by the same folks who have contributed some wonderful tools that we all know and love, like [TanStack Router](https://tanstack.com/router) and [TanStack Query](https://tanstack.com/query). We're so excited by it, we've even helped by sponsoring the project. And today, we're proud to announce `@clerk/tanstack-start@beta`, a new official SDK that allows developers to add authentication and authorization into their TanStack Start application in matter of minutes. The SDK comes fully equiped with Clerk's UI components, server utilities, and low level utilities for any of your custom flows. ## Use Clerk UI components Clerk's pre-built UI components give you a beautiful, fully-functional user and organization management experience in minutes. Here's an example on how simple it is to build a sign-in page using Clerk's `` component inside your TanStack Start applications. ```tsx {{ title: 'app/routes/sign-in.$.tsx' }} import { SignIn } from '@clerk/tanstack-start' import { createFileRoute } from '@tanstack/react-router' export const Route = createFileRoute('/sign-in/$')({ component: Page, }) function Page() { return } ``` ## Server functions You can also pair our `getAuth()` utility function with TanStack Start's server functions to protect your routes. ```tsx {{ title: 'app/routes/index.tsx' }} import { createFileRoute, useRouter, redirect } from '@tanstack/react-router' import { createServerFn } from '@tanstack/start' import { getAuth } from '@clerk/tanstack-start/server' const authStateFn = createServerFn('GET', async (_, { request }) => { const { userId } = await getAuth(request) if (!userId) { throw redirect({ to: '/sign-in/$', }) } return { userId } }) export const Route = createFileRoute('/')({ component: Home, beforeLoad: async () => await authStateFn(), loader: async ({ context }) => { return { userId: context.userId } }, }) function Home() { const router = useRouter() const state = Route.useLoaderData() return

Welcome your user id is {state.userId}!

} ``` This is just the beginning. You can learn more on how to get started building TanStack Start applications with Clerk, check out our [TanStack Start Quickstart guide](/docs/quickstarts/tanstack-start). We're excited to see what you build 🏝️. --- ## Host multiple Clerk apps on the same domain - URL: https://clerk.com/changelog/2024-09-09-multiple-apps-same-domain.md - Date: 2024-09-09 Previously, Clerk only supported hosting one application per domain without causing cookie collisions and this limitation forced our users into a handful of unacceptable workarounds. So, we went back to the drawing board and rearchitected the way we set and handle our cookies to finally support multiple apps under the same domain. Now, cookies are more tightly scoped, enabling useful scenarios like: - **Staging and production environments on the same domain**: No more need to buy a separate domain just to set up a staging environment. Your production environment can live at `example.com`, and your staging app can live at `staging.example.com`. - **Separate apps, same TLD**: Some customers had multiple apps but wanted to keep the top-level domain consistent. Enable a scenario like `dashboard.example.com` and `admin.example.com` without needing a separate domain. - **Developing multiple apps on localhost at the same time**: You can now develop multiple applications on localhost simultaneously using different ports (e.g., on `localhost:3000` and `localhost:3001`) out of the box. The best part is, there’s no need to make any changes to your applications - everything works out of the box. Just ensure your Clerk SDKs are up to date to fully leverage this feature. We’ve been rolling out this change gradually over the past few weeks and have done the heavy lifting to ensure everything runs seamlessly. There are even more improvements to come as it relates to enabling best-in-class deployment workflows (*cough* [staging instances](https://feedback.clerk.com/roadmap/de417dd1-fa2e-4997-868f-4c9248027e7d) *cough*), and this foundational change gets us a step closer to that reality. --- ## Hugging Face SSO Provider - URL: https://clerk.com/changelog/2024-08-29-huggingface-oauth-provider.md - Date: 2024-08-29 Easily integrate [Hugging Face](https://huggingface.co/) into your applications as either an authentication method or an external account that can be linked to your existing users. 🤗 Visit our [Setup guide](/docs/authentication/social-connections/huggingface) to configure a Hugging Face Connected App for your application in minutes. --- ## Local Credentials in Expo - URL: https://clerk.com/changelog/2024-08-21-expo-local-credentials.md - Date: 2024-08-21 We've expanded our Expo SDK with a new hook, `useLocalCredentials`, which combines the capabilities of Clerk's user management with the concept of *Local Authentication* in native apps. For applications that allow their users to log in with an identifier and a password, `useLocalCredentials` enables them to use biometric authentication like Face ID, or Touch ID, when they sign back into the app. So, the next time they need to provide their credentials, they can simply use their device's biometrics. Credentials are stored securely on the user's device only when they first sign in and can later be retrieved only after the user successfully passes biometric authentication. Visit the [Local Credentials guide](/docs/references/expo/local-credentials) to learn more about how to integrate this into your Expo app today. --- ## Add any social sign-in option with Custom Providers - URL: https://clerk.com/changelog/2024-08-20-custom-oauth-providers.md - Date: 2024-08-20 Ever look through our list of [built-in authentication providers](/docs/authentication/social-connections/overview#social-connections-authentication-providers) and be disappointed that you couldn't find the one your users are looking for? Well first off, we're sorry we let you down. But today's a new day... Starting now you can add *any* OpenID Connect (OIDC) spec-compliant OAuth provider to your Clerk application today. It's as easy as filling out a form. We've even added **Debug** section where you can test your configuration and troubleshoot by viewing errors and API responses. Head to the [Clerk Dashboard](https://dashboard.clerk.com/~/user-authentication/social-connections), or have a look at our [custom provider docs](/docs/authentication/social-connections/custom-provider) and never be dissappointed by Clerk again\* *\* We can't actually promise this, but we'll do our best!* --- ## iOS SDK Beta - URL: https://clerk.com/changelog/2024-08-19-ios-sdk-beta.md - Date: 2024-08-19 In a world where users prefer different devices and often switch between them, having a consistent and convenient authentication experience across platforms is more important than ever. Our [Expo SDK](/docs/quickstarts/expo) has long enabled the creation of universal applications for Android, iOS, and the web using a single React codebase. However, we recognize that some customers prefer native SDKs for optimized performance, direct access to platform-specific features, and seamless integration with other native components. That's why we’re excited to introduce Clerk iOS (Beta)! The Clerk iOS SDK is a toolkit designed to integrate Clerk’s authentication and user management services with applications made for the Apple ecosystem. Built with Swift, the SDK adheres to modern standards, delivering the idiomatic and consistent developer experience you expect from Clerk. Clerk iOS is launching in beta today, with support for building fully custom sign-up and sign-in flows for iOS, macOS, visionOS, tvOS, and watchOS. Along with the release, we're also sharing [reference documentation](/docs/references/ios/overview) and a [quickstart](/docs/quickstarts/ios) to get you started. Now, on to some highlights of the Clerk iOS SDK... ## SwiftUI The Clerk iOS SDK was built with SwiftUI in mind, allowing you to harness it's declarative approach to user interface on all Apple platforms. ```swift {{ filename: 'ContentView.swift' }} import SwiftUI import ClerkSDK struct ContentView: View { @ObservedObject private var clerk = Clerk.shared var body: some View { VStack { if let user = clerk.user { Text("Hello, \(user.id)") } else { Text("You are signed out") } } } } ``` ## Async/Await The Clerk iOS SDK makes use of the latest in Swift networking, allowing your code to be as readable and expressive as possible. ```swift // Create a new sign up let signUp = try await SignUp.create( strategy: .standard( emailAddress: "newuser@clerk.com", password: "••••••••••" ) ) // Send an email with a one time code // to verify the user's email try await signUp.prepareVerification( strategy: .emailCode ) ``` ## Social Connections (OAuth) Authenticate with your favorite social providers in just a few lines of code. ```swift try await SignIn .create(strategy: .oauth(.google)) .authenticateWithRedirect() ``` ## State Management Let the Clerk iOS SDK take care of managing your user's authentication state so you can get back to building your app. ```swift {{ filename: 'SwiftUI' }} @ObservedObject private var clerk = Clerk.shared var body: View { if let session = clerk.session { Text(session.id) } else { Text("No session") } } ``` ```swift {{ filename: 'UIKit' }} override func viewDidLoad() { super.viewDidLoad() if let session = Clerk.shared.session { sessionLabel.text = session.id } else { sessionLabel.text = "No session" } } ``` ## Building towards GA As an official Clerk SDK, you can expect responsive support, even while in beta. Your [feedback](https://clerk.com/contact/support) is critical during this testing period to ensure Clerk iOS is the best it can be. If you have questions or want to talk to other users who are trying out the beta, join the [Clerk Discord](https://clerk.com/discord) community. Please note the SDK is currently in beta. Certain features - notably pre-built components, organizations, and magic links - are not yet implemented, but we're working on it. You can see a list of the currently available features [here](https://github.com/clerk/clerk-ios?tab=readme-ov-file#-supported-features). The API will likely undergo breaking changes until the 1.0.0 release next year. --- ## Limit how many organizations users can create - URL: https://clerk.com/changelog/2024-08-13-limit-org-creation.md - Date: 2024-08-13 ![Limit how many organizations users can create feature showcase](./clerk-dashboard-limit-org-creation.png) Administrators can now more easily control how many organizations their users are allowed to create, providing extra controls for your B2B applications. [Configure](https://clerk.com/docs/organizations/overview#application-user) a default setting for all users via API or from the [Clerk Dashboard](https://dashboard.clerk.com/~/organizations-settings), and then customize the limit on a per-user basis (also via the [Backend API](/docs/reference/backend-api/tag/users/PATCH/users/\{user_id}) or in a specific User detail view in the [Clerk Dashboard](https://dashboard.clerk.com/~/users)) For some applications, this unlocks the ability to restrict org creation initially until a user has taken additional actions - like signing up for a paid plan. You simply set the defaults and Clerk keeps track of the creation and deletion of organizations. --- ## Add custom menu items to - URL: https://clerk.com/changelog/2024-08-06-userbutton-custom-menu-items.md - Date: 2024-08-06 ### UserButton Customization The `` component now supports the following customizations: - **Custom Links**: Add external links to the menu using the `` component. - **Custom Actions**: Define custom actions that can trigger specific behaviors within your app using the `` component. This includes implementing custom logic with onClick handlers or opening the user profile modal to a specific page. Here is an example of how to use our new React API for `` customization: ```tsx } href="/terms" /> } open="help" /> {/* Navigate to `/help` page when UserProfile opens as a modal. (Requires a custom page to have been set in `/help`) */} } onClick={() => setOpenChat(true)} /> ``` For more information and implementation instructions, please refer to our [documentation](/docs/components/customization/user-button) for ``. --- ## Set Active Organization by Slug - URL: https://clerk.com/changelog/2024-08-02-set-active-by-slug.md - Date: 2024-08-02 For applications that include the organization slug in their URL path, when managing the Clerk [active organization](/docs/organizations/overview#active-organization), it is common to have an organization slug handy from the URL, but not necessarily an organization ID. Now, it's possible to call [`setActive`](/docs/references/javascript/clerk/session-methods#setactive) with an organization slug. This saves an extra call to fetch the organization ID, improving performance and reducing complexity. The example below creates a component that uses The Next.js useParams() hook to get the organization slug from the URL, and then the [`setActive`](/docs/references/javascript/clerk/session-methods#setactive) method to set that organization as active. ```tsx {{ title: 'utils/sync-active-organization-from-url-to-session.tsx' }} 'use client' import { useEffect } from 'react' import { useParams } from 'next/navigation' import { useAuth, useOrganizationList } from '@clerk/nextjs' export function SyncActiveOrganizationFromURLToSession() { const { setActive, isLoaded } = useOrganizationList() // Get the organization slug from the session const { orgSlug } = useAuth() // Get the organization slug from the URL // e.g. https://example.com/orgSlug/ const { orgSlug: urlOrgSlug } = useParams() as { orgSlug: string } useEffect(() => { if (!isLoaded) return // If the org slug in the URL is not the same as the org slug in the session (the active organization), // set the active organization to be the org from the URL. if (urlOrgSlug !== orgSlug) { void setActive({ organization: urlOrgSlug }) } }, [orgSlug, isLoaded, setActive, urlOrgSlug]) return null } ``` --- ## Cognito password migrator - URL: https://clerk.com/changelog/2024-08-02.md - Date: 2024-08-02 We’re excited to share with you the release of our Cognito password migrator! Existing AWS Cognito customers can now migrate their users into Clerk, and their users will be able to sign in to Clerk with their prior cognito passwords — No password reset flow required. Visit our [guide](/docs/deployments/migrate-from-cognito) to learn more about how to use the Cognito password migrator. --- ## Development Mode UI Changes - URL: https://clerk.com/changelog/2024-08-02-dev-notice.md - Date: 2024-08-02 Clerk's [development instances](https://clerk.com/docs/deployments/environments#development-instance) are great for getting started with Clerk, making local development smooth and simple, and testing out features. However, we have seen many users go to production using their development instance by accident - your app looks exactly the same, and works similarly enough that most wouldn't notice the difference. But if this does happen, it turns into a substantial issue. Development instances have a more relaxed security posture, are not indexed by search engines, use shared OAuth credentials for social providers by default, and lack custom domain support. In addition, development instances are capped at 100 users, 20 SMS messages, and have "development" prefixes on SMS and email messages, which quickly becomes a large problem if accidentally taken to production. Especially so if the user or SMS limits are hit, which can stop your app from being able to sign up or log in users - certainly not something you want to happen in production 😰. And on top of that, you then need to go through a process of migrating users from your development to your production instance to fix it, which can be challenging and time consuming. In order to combat this common issue, we made some modifications to the design Clerk's UI components in a specific effort to make it more clear that you're using a development instance. Our hope is that, with these changes, nodoby ends up taking a development instance to production by accident anymore. You can see an example of the change on the `` component here: ![Clerk's SignIn component in development mode](./dev-mode-ui.png) If you need to deactivate this UI change temporarily to simulate how components will look in production, you can do so by adding the `unsafe_disableDevelopmentModeWarnings` layout appearance prop to `` as such: ```tsx ``` It should be noted that this UI change initially will only apply to *newly created Clerk applications*. If you have an existing application, you won't see this UI change. We will be rolling out a way for existing applications to enable this feature in the coming weeks. --- ## Notice: Plans to EOL Gatsby SDK - URL: https://clerk.com/changelog/2024-08-01-gatsby-eol.md - Date: 2024-08-01 As of today August 1st, 2024 we are announcing a notice period for our Gatsby SDK that will complete on September 1st, 2024. **📣 During this period we are actively seeking a new community maintainer** In addition to seeking a new home, during this period we intend to: - Continue to provide critical patches and bug fixes - Pause adding new features to the Gatsby SDK unless contributed by community members - Migrate the Gatsby SDK from our [clerk/javascript](https://github.com/clerk/javascript) monorepo into a separate repository for easier community contributions If community maintainers are not found, the Gatsby SDK will be marked as archived. We've valued the partnership with the Gatsby community and we encourage interested developers to please [reach out](https://clerk.com/contact/support)! --- ## Clerk Expo v2 - URL: https://clerk.com/changelog/2024-07-26-clerk-expo-v2.md - Date: 2024-07-26 We are excited to announce that we have released `@clerk/clerk-expo` v2 with support for Expo Web! This means that you can create universal apps that run on Android, iOS, and the web all with a single codebase! ## Getting started If you haven't already created an Expo app with Clerk you can follow the [Expo quickstart guide](/docs/quickstarts/expo). Otherwise, you can update your existing Expo app to the latest version of `@clerk/clerk-expo` by following the [upgrade guide](/docs/upgrade-guides/expo-v2/upgrade). ## Use Clerk's prebuilt components on the web Adding a sign-in page to your web app is now as easy as adding a [single component](/docs/components/overview): ```tsx filename="/app/sign-in.web.tsx" import { SignIn } from '@clerk/clerk-expo/web' export default function Page() { return } ``` ## Build universal authentication flows from one codebase Leverage our hooks to build universal sign-in and sign-up views for Android, iOS, and web all from one codebase 🤯. Here's an example of a OAuth sign-in flow, using the SDK's `useOAuth` hook: ```tsx {{ title: '/app/sign-in-oauth.tsx', collapsible: true }} import React from 'react' import * as WebBrowser from 'expo-web-browser' import { Text, View, Button } from 'react-native' import { Link } from 'expo-router' import { useOAuth } from '@clerk/clerk-expo' import * as Linking from 'expo-linking' export const useWarmUpBrowser = () => { React.useEffect(() => { void WebBrowser.warmUpAsync() return () => { void WebBrowser.coolDownAsync() } }, []) } const SignInWithOAuth = () => { useWarmUpBrowser() const { startOAuthFlow } = useOAuth({ strategy: 'oauth_google' }) const onPress = React.useCallback(async () => { try { const { createdSessionId, signIn, signUp, setActive } = await startOAuthFlow({ redirectUrl: Linking.createURL('/'), }) if (createdSessionId) { setActive!({ session: createdSessionId }) } else { // Use signIn or signUp for next steps such as MFA } } catch (err) { console.error('OAuth error', err) } }, []) return ( Home