What the Registry is

The Registry is how an Akedly passkey is shared across apps. A passkey Akedly holds for a phone number can be used at any Akedly app; the app that created it is never part of its identity. The private key is not shared: it stays on the user's device and in their credential manager, and apps receive only the result of the check.

There is nothing to opt into. The Registry is managed by Akedly and has no per-pipeline switch. An app can use a passkey from the Registry when passkeys are turned on for its account and pipeline.

---

How a person experiences it

1. At app X, the user signs in with a code over WhatsApp, Telegram, SMS or email, then chooses to turn on Face ID, a fingerprint or a screen lock for instant sign-in. The screen tells them that other apps and websites that use Akedly may also let them verify with the passkey.
2. At app Y, another Akedly app, the user enters the same phone number. App Y offers the passkey, the user confirms with a biometric or screen lock, and app Y receives a verified result. No code is sent.
3. If something is missing, such as no passkey on this device, app Y sends a code as usual. A code is never removed from the flow.

---

The trust rule

A passkey is trusted across the Registry only when Akedly itself has sent and matched a code to that phone number, on a device that holds that passkey, within the last 90 days.

Akedly tracks this itself. An app cannot create or renew that trust by sending its own code, and a code Akedly sends and matches is what keeps a passkey current across the Registry.

---

When a code is still asked

A passkey lets a user skip the code. It does not remove the code from your flow. The normal OTP flow runs when:

• The passkey is not yet tied to a recent Akedly code. A passkey that Akedly has not yet matched to a code of its own, for example one saved before the Registry, or one whose last matched code is more than 90 days old, triggers one code on the same attempt. After that code, the passkey is current for the whole Registry.
• Your app supplies its own OTP. An app that sends its own otp can use Registry passkeys but cannot create or renew trust.
• There is no passkey on the device, the user cancels, or the platform does not support passkeys.
• Passkeys are off for your account or pipeline, or the phone number is blocked on your account.

When a passkey needs a code first, the user taps the passkey, then completes the code step on the same attempt. You pay for that one OTP and there is no passkey charge.

---

What your integration does

V2.0 Widget. Nothing changes in your integration. Your widget starts offering passkeys that users saved at other Akedly apps. Your iframe, redirect, postMessage and webhook contracts are the same. Keep the allow attribute on your iframe so the widget can use WebAuthn.

V1.2 REST API. Keep calling POST /auth-options from your backend. Handle three outcomes:

• Verified. Akedly returns a verified result. No code is sent.
• NO_PASSKEY (404) or any failure. Continue with your OTP send and verify flow.
• A code is needed first. On the hosted passkey page, Akedly handles the code step for you.

Requirements. V1.2 or V2.0 (V1.0 is not supported). Passkeys turned on for your account and for the pipeline.

---

Billing

The app where the user signs in pays, and only for a successful passkey sign-in. Enrolling is free.

The charge is the passkey rate applied to your own OTP price for that phone number: your earliest OTP charge for it, or your own OTP rate for the country if there is none. The default passkey rate is 60%, which is up to 40% less than an OTP.¹ Some accounts are on a fixed per-passkey rate. The app where the passkey was saved is never part of the calculation, and another app's pricing is never used.

When a code is still needed, you pay for that one OTP and there is no passkey charge.

¹ With the default passkey rate (60% of your own OTP price for that phone number). Your rate may differ.

---

What is shared, and what is not

Shared across Akedly apps

• The passkey's public key, held by Akedly and tied to the phone number under akedly.io.
• Whether the passkey is current, and the date Akedly last matched a code to it.
• To offer a passkey, Akedly checks whether the phone number has one.

Not shared

• The biometric. It stays on the device.
• The private key. It stays in the user's credential manager.
• Which app the user saved the passkey at. Your dashboard and results never name another app.
• Another app's block settings, counts or credentials.

Your controls

• You can block a phone number from passkey sign-in on your account. It affects only your account, and codes still work.
• Akedly can revoke a phone number's passkeys everywhere. Contact support@akedly.io.

Phone numbers are ordinary OTP data to the app that collected them.

---

Multiple devices

A passkey lives in the user's credential manager. Where that manager syncs, such as Apple Keychain or Google Password Manager, the passkey is available on the user's other devices signed in to the same account. Syncing is done by the operating system; Akedly asks the device for a passkey that can sync but does not control whether it does.

Passkeys saved earlier may be tied to one device. A user with no passkey on the device in front of them verifies with a code and can save a new passkey there.

---

FAQ