Skip to main content
The user.passkey.deleted event is triggered when a passkey credential is removed from a user’s account. There are two paths that produce this event:
  • User-driven: the user calls DELETE /me/passkeys/{credentialID} (typically from a “Manage your passkeys” settings page). session_id is the session that initiated the delete.
  • Compromise response: POST /me/revoke?target=all cascades into a passkey wipe — every credential the user holds is removed alongside the session revoke. session_id is empty on those events because the calling session is itself being revoked.
The credential field carries a snapshot of the credential as it was just before the delete (nickname, transports, backup state) so audit timelines and “we removed a passkey from your account” notifications can identify the device without an extra lookup.

​
Event payload

Emitted when a user deletes a registered passkey credential. The credential snapshot is captured before the row is dropped.

​
user_id
string
required

An app's user's unique identifier. It is prefixed with 'usr_'

Examples:

"usr_01jqebhswje1ka1z7ahr9rfsgt"

"usr_01jqy7455pf8p9bap5qke912g1"

​
credential
object
required

Subset of the credential surfaced on user.passkey.* events. Public key, sign count, and AAGUID are intentionally hidden — they are internal to the authentication flow and never relevant to a downstream webhook subscriber.

​
deleted_at
string<date-time>
required
Example:

"2025-03-15T10:30:00Z"

​
session_id
string

The session that initiated the delete. Empty on system-driven wipes that aren't tied to a specific caller session (e.g. the target=all revoke flow wipes credentials alongside the sessions that would have carried this field).

Example:

"ses_01jr0z5w2seq998trz7ftbb9rj"

​
correlation_id
string
Example:

"123e4567-e89b-12d3-a456-426614174000"