Skip to main content

Clerk Changelog

Directory Sync sends webhooks for group and membership changes, the Backend API reads a group and its members, and a directory can be paused without removing anyone's access.

Directory Sync has three new capabilities: webhooks for group changes, Backend API reads for a group and its members, and a pause switch for directories. Group pushes from the identity provider also produce fewer events than before.

Group webhooks

Directory Sync keeps Organization memberships and Roles in step with your identity provider, but until now the groups themselves were hard to observe. That matters most when your application maps identity provider groups onto its own objects, such as teams or projects, rather than onto Clerk Organizations alone. The only signal was the user.updated event Directory Sync fires for each member it touches. Your webhook handler fetched the user, read their current groups, and worked out what changed. When an IT admin deleted a group in the identity provider, that produced the same events as every member leaving at once, and nothing in them told the two apart.

Six webhook events now report group changes directly:

  • directoryGroup.created: the identity provider created a group.
  • directoryGroup.updated: the identity provider renamed a group. The payload carries the new display_name.
  • directoryGroup.deleted: the identity provider deleted a group, or it stopped appearing in a pull sync. The payload carries the last known name.
  • directoryGroup.synced: the identity provider pushed a group in full, whether or not anything changed. Okta sends that push on Push now and on its periodic re-push of unchanged groups, so the event fires once per group per push. It isn't sent for pull-synced directories such as Google Workspace.
  • directoryGroupMembership.created: a user was added to a group.
  • directoryGroupMembership.deleted: a user was removed from a group. cause says why: member_removed when the provider took the user out, group_deleted when the whole group went away.

Every payload names the directory_id and the group's id and display_name. Membership payloads also carry the member's directory_user_id and the user_id of the Clerk user they're linked to, which is null until that user has been provisioned.

Webhooks can arrive out of order. When two events describe the same group or membership, keep the one with the later updated_at, which is when the directory recorded the change.

Read a group and its members

Two reads join the Directories endpoints:

A webhook handler that receives a directoryGroup.* event can fetch the group's current state with these reads instead of keeping its own copy of the directory.

Fewer user.updated events on group pushes

Since October 20, a group push from the identity provider records only the members who joined or left. The per-user events a push produces, such as directoryGroupMembership.created and user.updated, cover those users alone. The group-level events don't depend on who changed: a rename sends directoryGroup.updated, and every push sends directoryGroup.synced, so a push with nothing changed sends that one event and nothing else. Before, every push rewrote the whole group, so every member counted as changed on every push, and large groups that Okta re-pushes every few minutes timed out.

If you relied on that fan-out to replay a group, for example by asking a customer to Push now in Okta so your application could rebuild its memberships, listen for directoryGroup.synced instead and page through the group with the members endpoint. That's one event per group per push, however many members the group has.

Pause a directory

A directory can now be paused, from its page in the Clerk Dashboard or by sending paused to PATCH /v1/directories/{directory_id}. Directory responses include the flag. A paused directory rejects provisioning requests and skips scheduled syncs, but keeps the memberships it granted. After you resume a SCIM directory, trigger a resync from the identity provider so it pushes its current state. Requests it sent while the directory was paused were rejected, not queued. A pull-synced directory catches up on its next sync. Disabling a directory withdraws the access it granted instead, so pause when you want changes to stop landing for a while without touching anyone's access.

Contributor
Maurício Antunes

Share this article

Set a minimum version for each native app in the Clerk Dashboard. Users on older builds see an update screen until they update.

The update required screen on iOS and Android.

You can now set a minimum version for each of your iOS and Android apps in the Clerk Dashboard. When a user opens a build that's older than the minimum, Clerk rejects most of the app's requests and the Clerk SDK covers the app with an update screen that links to the App Store or Google Play. Users stay signed in, so they continue where they left off after they update.

Set a minimum when older builds should no longer be used, such as after a security fix or a change to an API they depend on.

Get started

Update your app to Clerk iOS SDK 1.7.0, Clerk Android SDK 1.4.0, or @clerk/expo 4.15.0 or later, complete the required setup, then set a minimum on the Native applications page in the Clerk Dashboard.

Release a build with the new SDK before you set a minimum. Earlier SDK versions don't show the update screen, and apps on Clerk iOS SDK 1.0.0 through 1.6.x show an error instead.

To set it up or show your own update screen instead of Clerk's, see the guide for your platform:

Contributors
Sean Perez
Sam Wolfand
Robert Soriano

Share this article

Read Application Logs with the Backend API

Category
Product
Published

The GET /v1/logs endpoint is now public, so you can look up Application Logs events from your own code or an AI agent.

Application Logs are now available through the Backend API. Use the GET /v1/logs endpoint to look up specific events and debug issues, either by calling it directly or through an AI agent. It filters on the same event types as the Dashboard.

Limits

The endpoint is rate limited. Requests over the limit return 429 with the code too_many_requests. Viewing logs in the Dashboard doesn't count toward the limit. Results go back as far as your plan's retention period.

Syncing or exporting logs through the Backend API isn't allowed. To send logs continuously to a storage bucket you own, use log drains, available on the Enterprise plan.

Read the documentation to learn more.

Contributors
Brandon Romano
Ignacio Rueda

Share this article

Clerk for Agent Auth

Category
Product
Published

Clerk for Agent Auth is entering private beta.

Clerk for Agent Auth with icons for AI agents.

Clerk for Agent Auth is built on open OAuth standards as well as the Personal Agent Protocol, and helps enable and secure your application for the rapidly evolving personal agents landscape.

Agents that speak the protocol can discover your application and Clerk verifies their identities, and authenticates them for you. When an agent hits a wall or can’t complete a task on your site, it can report that feedback directly, giving you actionable steps to improve your application. And that’s just what’s possible today; there’s plenty more functionality on the horizon.

Clerk for Agent Auth is in private beta. During the initial launch, we plan to work with select partners in building together. Whether you're interested or just want your app to be agent-ready, fill out the Clerk for Agents interest form, and we'll be in touch!

Contributor
Kevin Wang

Share this article

New sign-up limits in Clerk Protect

Category
Product
Published

Set hourly sign-up limits per email domain and from shared infrastructure.

The Business plan now includes two more advanced protections in Clerk Protect to help limit bulk account creation:

Both limits apply across IP addresses and complement the existing per-IP sign-up limit.

Get started

Explore Protect in the Clerk Dashboard and choose the protections that fit your application. See the getting started guide for requirements and setup instructions.

Contributors
Theo Zourzouvillys
Mike Wickett

Share this article

Passkeys as a second factor

Category
Security
Published

Users can now use a passkey as their second factor for multi-factor authentication after they sign in another way.

Users can now use a passkey as their second factor for multi-factor authentication after they sign in another way. A passkey combines two factors, a device and a PIN or biometric, in one step.

When users sign in with a password, a social connection, or a reset-password code, they can use their passkey instead of an SMS code or authenticator app, including during reverification. In <SignIn /> and the reverification modal, users who have a passkey start on the passkey step and can pick another method with Use another method.

This also helps with recovery. A user who loses their phone or authenticator app can sign in with their password and use their passkey as their second factor, without waiting for an MFA reset.

A passkey doesn't turn on MFA for a user. Clerk doesn't prompt users who haven't set up MFA for a separate second factor. If you require MFA, those users must set up a second factor before sign-in finishes, including when they sign in with a passkey.

Get started

Native apps need clerk-ios 1.5.0, clerk-android 1.1.4, @clerk/expo 4.13.1, or later. Web apps need @clerk/clerk-js 6.40.0 and @clerk/ui 1.41.0 or later: upgrade your SDK to the minimum version in the versioning guide, and if you pin either package or bundle @clerk/ui, upgrade it too.

Then:

  1. If your application was created before July 8, 2026, turn on Passkeys satisfy multi-factor authentication under Sign-in with passkey on the User & authentication page. Newer applications already have it on, and native apps offer the passkey second factor once it's on.
  2. For web apps, opt in to the Passkeys as a second factor on the web update on the Updates page if your instance doesn't have it. Instances created on or after October 19, 2026 already have it, except production instances cloned from a development instance without it.

If you're building a custom flow, supportedSecondFactors can now include passkey. See the custom MFA flow guide to complete it, and the passkeys and MFA guide for SDK requirements.

Contributors
Daniel Moerner
Sean Perez
Sam Wolfand
Robert Soriano

Share this article