Asynchronous
Extensions used for responding to platform events are run asynchronous. In this section we list the various event payloads as well as show how to configure them.
Configuration
Asynchronous extensions are configured via a rule on the extension itself. You can select from the following categories:
Event Types
All - triggers upon all event types (implicit - same as leaving blank)
API - triggers upon API calls
Data - triggers upon input or claims capture (username, OTP & federation)
Database - triggers upon resource changes (create, update & delete)
Authentication - triggers upon authentication events (pending, success & failed)
Authorization - triggers upon authorization events (pending, success & failed)
Communication - triggers upon communication requests (send OTP)
Event Results
All - triggers upon all event results (implicit - same as leaving blank)
Success - triggers upon all successful events
Failed - triggers upon all failed events
Pending - triggers upon all pending events
Event Actions
All - triggers upon all event actions (implicit - same as leaving blank)
... (see event details below)
Event Reasons (only relevant for failed or pending events)
All - triggers upon all event reasons (implicit - same as leaving blank)

Events
Authentication API
Factors
Tokens
Controls
Management API (GraphQL)
Factors
Controls
Extensions
Accounts
Tenants
Database
Factors
The following fields get redacted for factors at tenant level (replaced by <REDACTED>):
label(if enrollment)config.secret(if present)config.client_secret(if present on create or delete)config.client_secret__added(if present on update)config.client_secret__deleted(if present on update)
Controls
The following fields get redacted for controls at tenant level (replaced by <REDACTED>):
label(if consent)label__added(if consent and present on update)label__deleted(if consent and present on update)
Accounts
Extensions
Data
Factors
The capture_tokens feature is currently still experimental and should not be used for production setups — tokens in payload can not be guaranteed to be present at this time.
Authentication
Factors
Authorization
Controls
Communication
Factors
Accounts
Tenants
Example: One-Time Password
An example that pushes the OTP to a public AWS Lambda endpoint to deliver to OTP to the user by email using Amazon Simple Email Service (SES).
The code for the receiving Lambda below.

Once a user logs in using the One-Time-Password, the code gets executed, and as in this example, the OTP delivered to the user (in this example, it's simply sent to the Lambda endpoint without further distinction; in real-world scenarios, these could be requests to send an email or SMS via external APIs for example).

Last updated