Delivery and retries

Documentation Index

Fetch the complete documentation index at: https://docs.authsignal.com/llms.txt

Use this file to discover all available pages before exploring further.

​

Synchronous webhooks

Sent during an active request. The response affects the outcome of that request, so respond as quickly as possible and defer slow work to a background job.

• Challenge events (email.created, sms.created, push.created). A non-2xx fails the challenge and an error is returned to the caller. The pre-built UI prompts the user to retry; the SDK or API surfaces the error to your application.
• Action verification (action.verify). A non-2xx or a timeout blocks the transition to CHALLENGE_SUCCEEDED. No automatic retries; the user can retry by re-running the verification.

​

Asynchronous webhooks

Sent in the background, so they do not block the originating request.

• Authenticator events (authenticator.*). When your endpoint returns a non-2xx response, the event is retried up to 3 times, with a minimum of 30 seconds between attempts.
• Log events (action.log_created, challenge.log_created). Delivered in batches of up to 500 events after your tenant’s challenge token duration (typically 15 minutes). Failed batches are retried periodically until delivery succeeds.

Both types use at-least-once delivery, so the same event can arrive more than once. De-duplicate using the envelope id. Authsignal also does not guarantee strict ordering, so use the time field on the envelope to reconstruct order if you need it.

​

IP address allow-listing

Authsignal will send webhooks originating from the following IP addresses: