Event logs

Understand and debug your authentication flows using Stytch Event Logs.

You can find Event Logs in the Stytch Dashboard. Event logs should be available within a minute upon request completion and are currently retained for 30 days. For longer retention or external analysis, we recommend enabling event log streaming.

Event logs can be streamed to different observability platforms. Currently Datadog Logs and Grafana Loki are the only supported destinations. For more information, see the Event Log Streaming.

All events have the following fields:

• event_id: A unique identifier of the individual event
• project_id: The project ID related to this event
• action: A string that corresponds to a Stytch API request or an admin action. See below for more details
• status: The status for a given action tied to this particular event. See below for more details
• request_id: A unique identifier for the API request this event belongs to. Multiple events can share a request_id

Most events will have additional metadata specific to that action. For example:

• Most successful project-specific API calls will have project_name (start events do not have a project name)
• Events related to session authentication have session_jwt_hash or session_token_hash.
• Events with a status error or success will typically have http_status_code with the relevant information
• Events in projects with DFPPA enabled will have more metadata related to the request, including the verdict action

Each event log maps to a specific action, which corresponds to either a Stytch API request (e.g. MagicLinksEmailLoginOrCreate) or a meaningful dashboard request (e.g. CreatePublicToken). Actions help you understand what types of requests are being made.

The list of actions below is not exhaustive, but gives you a sense of the types of actions you can expect to see in your event logs:

• SessionsAuthenticate or MultiTenantSessionsAuthenticate: This action will appear whenever a user's session is authenticated. Our frontend SDKs will automatically call this method to refresh and auth a user's session. SessionsAuthenticate relates to a session in our Consumer API, while MultiTenantSessionsAuthenticate relates to a session in our B2B API.
• OAuthGoogleOneTapStart: This action will appear whenever the Google One Tap prompt is rendered, i.e. anytime a user visits a page where you display the Google One Tap prompt.
• GetUser: This action will appear whenever a user is fetched from Stytch via GetUsers.
• SessionsJwks: This action will appear whenever you fetch your Project's JWKS. This can be done manually, but is typically done automatically by our SDKs whenever a Stytch client is instantiated.
• SearchUsersExternal: This action will appear whenever you call SearchUsers. This is marked external to differentiate it from the search event (SearchUsers) called by our Dashboard user search.
• EmailDelivery: This action gives you visibility into email delivery and email opens for your users. This action will appear for successful deliveries, bounces or errors, and opens. Check out the message_status field to determine the type of event.
• PasswordsAuthenticate: This action appears whenever a user authenticates with a password.
• MagicLinksCreate: This action relates to our Embeddable Magic Links product. This action will appear whenever a magic link is created.
• CryptoWalletsAuthenticateStart: This action will appear whenever a user starts the authentication flow for a crypto wallet.
• OAuthAuthenticate: This action will appear whenever a user successfully authenticates with an OAuth provider.
• OAuthGoogleStart: This action will appear whenever a user starts the non-One Tap authentication flow for Google.
• SessionsRevoke: This action will appear whenever a user's session is revoked. This can happen when a user logs out or when a user's session is revoked via the API.
• CryptoWalletsAuthenticate: This action will appear whenever a user successfully authenticates with a crypto wallet.
• OTPsAuthenticate: This action will appear whenever a user successfully authenticates with an OTP.
• MagicLinksAuthenticate: This action will appear whenever a user successfully authenticates with a magic link.
• UpdateUser: This action will appear whenever a user is updated via UpdateUser.

You can filter for event logs by status type. The following status types are available:

• start marks the start of a request. It is paired with a subsequent success or error event log.
• success marks the completion of a successful request.
• error marks the failure of a request.

start and success/error event logs are tied together by request ID.