Clerk Changelog

Application Logs⁠ now record delivery events for SMS messages sent by Clerk, including phone verification codes, OTPs, and password reset codes. When a user reports a missing code, these events show whether the message was accepted, delivered, rejected, or left unconfirmed.

The delivery lifecycle

Each message can generate several event types, helping you distinguish between a send failure, a delivery rejection, and an unknown outcome:

• sms.accepted — the delivery provider accepted the message (not yet proof it reached the phone)
• sms.delivered — the carrier confirmed delivery to the handset
• sms.failed — the send stopped before handoff, or the provider rejected it
• sms.undeliverable — the carrier could not deliver it after accepting it
• sms.unconfirmed — the provider reported an unknown delivery outcome

Failure events carry a normalized reason — like invalid_phone_number, destination_unreachable, or rate_limited — so a failure tells you whether to fix the number, wait out a provider limit, or adjust your own configuration. The message body, verification code, and provider identity are never included.

Filtering and search

The dedicated SMS logs view⁠ lists these events, where you can filter by a single event type like sms.failed or by the destination phone number to pull up one recipient's history. Every event for a single message shares a trace, so you can follow its whole timeline end to end.

Get started

SMS events are available on all plans as part of Application Logs. Retention varies by plan. See the pricing page for details. Open the SMS logs view⁠ to investigate SMS delivery, or Application Logs⁠ to view SMS events alongside other application events. Read the documentation to learn more.

Going forward

SMS delivery events build on Clerk's ongoing observability work alongside Admin Logs and Email Logs.

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⁠ 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 to configure an OAuth application, implement device and token requests, and handle polling responses.

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⁠ 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. For sensitive actions unique to your application, define the required window in your application. See the reverification guide for details.

The Clerk Dashboard now has 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.

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 for details. They start recording on August 24, 2026; actions before that date aren't included. Open Admin Logs⁠ in the Clerk Dashboard, or read the docs.

Going forward

Admin Logs join Application Logs and Email Logs in Clerk's ongoing observability work.

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⁠ 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.

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

import { useBiometricCredentials } from '@clerk/expo'

const { enroll } = useBiometricCredentials()

await enroll()

import { useBiometricCredentials } from '@clerk/expo'

const { signIn } = useBiometricCredentials()

await signIn()

import { useBiometricCredentials } from '@clerk/expo'

const { revoke } = useBiometricCredentials()

await revoke(biometricCredentialId)

iOS

try await Clerk.shared.biometricCredentials.enroll()

try await Clerk.shared.auth.signInWithBiometrics()

try await Clerk.shared.biometricCredentials.revoke(id: biometricCredentialId)

Android

scope.launch {
  Clerk.biometricCredentials.enroll()
}

scope.launch {
  Clerk.auth.signInWithBiometrics()
}

scope.launch {
  Clerk.biometricCredentials.revoke(biometricCredentialId)
}

See the biometric sign-in docs for setup and reference material:

• iOS guide
• Android guide
• Expo guide