Clerk changed its API changelog

===================================================================
--- before
+++ after
@@ -2,8 +2,33 @@
 
 CLERK CHANGELOG
 
 Subscribe to RSS
+Aug 25
+
+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.
+
 Aug 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.
 
@@ -21,11 +46,11 @@
 To enforce scopes in your API, verify each OAuth access token and check its granted scopes. See Verify OAuth tokens with Clerk.
 
 Aug 17
 
-Clerk's mobile SDKs can now enroll a signed-in user's current device as a trusted device, 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.
+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 trusted-device APIs directly.
+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
 
 Enroll
@@ -33,25 +58,25 @@
 Sign in
 
 Revoke
 
-import { useTrustedDevices } from '@clerk/expo'
+import { useBiometricCredentials } from '@clerk/expo'
 
-const { enroll } = useTrustedDevices()
+const { enroll } = useBiometricCredentials()
 
 await enroll()
 
-import { useTrustedDevices } from '@clerk/expo'
+import { useBiometricCredentials } from '@clerk/expo'
 
-const { signIn } = useTrustedDevices()
+const { signIn } = useBiometricCredentials()
 
 await signIn()
 
-import { useTrustedDevices } from '@clerk/expo'
+import { useBiometricCredentials } from '@clerk/expo'
 
-const { revoke } = useTrustedDevices()
+const { revoke } = useBiometricCredentials()
 
-await revoke(trustedDeviceId)
+await revoke(biometricCredentialId)
 
 IOS
 
 Enroll
@@ -59,13 +84,13 @@
 Sign in
 
 Revoke
 
-try await Clerk.shared.trustedDevices.enroll()
+try await Clerk.shared.biometricCredentials.enroll()
 
-try await Clerk.shared.auth.signInWithTrustedDevice()
+try await Clerk.shared.auth.signInWithBiometrics()
 
-try await Clerk.shared.trustedDevices.revoke(id: trustedDeviceId)
+try await Clerk.shared.biometricCredentials.revoke(id: biometricCredentialId)
 
 ANDROID
 
 Enroll
@@ -74,17 +99,17 @@
 
 Revoke
 
 scope.launch {
-  Clerk.trustedDevices.enroll()
+  Clerk.biometricCredentials.enroll()
 }
 
 scope.launch {
-  Clerk.auth.signInWithTrustedDevice()
+  Clerk.auth.signInWithBiometrics()
 }
 
 scope.launch {
-  Clerk.trustedDevices.revoke(trustedDeviceId)
+  Clerk.biometricCredentials.revoke(biometricCredentialId)
 }
 
 See the biometric sign-in docs for setup and reference material:
 
@@ -95,9 +120,9 @@
 Aug 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 [/_next/image?url=%2F_media%2Fchangelog%2F2026-08-10-discounts-and-promo-codes%2Fmanual-discounts.png%3Fhash%3DZ4mcZ0bxiJ6Bs2KRpT8htdJ1p2I07Ddy1nHQC4wnjlI&w=3840&q=75&dpl=dpl_2f1hvsmhBPcdZzVPfXCMEd8GmQvq]
+The Apply discount option on a subscription in the Dashboard [/_next/image?url=%2F_media%2Fchangelog%2F2026-08-10-discounts-and-promo-codes%2Fmanual-discounts.png%3Fhash%3DZ4mcZ0bxiJ6Bs2KRpT8htdJ1p2I07Ddy1nHQC4wnjlI&w=3840&q=75&dpl=dpl_xMKtMQL9QtkJuAu8Bc5ZxrrqYWLt]
 
 CREATE A DISCOUNT ONCE, USE IT ANYWHERE
 
 Discounts are reusable and flexible:
@@ -163,47 +188,5 @@
 Map array paths to a multi-valued attribute to sync all items.
 
 See the Directory Sync docs⁠ for the full setup guide.
 
-Aug 4
-
-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 <SignIn /> 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 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 <SignIn /> 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.
-
-Password can't be the starting strategy. Either disable Password or set the instance's preferred sign-in strategy to OTP⁠. 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, <SignIn /> 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⁠ page under Protect in the Clerk Dashboard. If your app already renders <SignIn /> as a combined sign-in-or-up page and is in Open access mode, 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.
-
-The Account Portal 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 <SignIn /> in your own app.
-
 Support
\ No newline at end of file