Skip to main content

Overview

Webhooks allow you to receive real-time HTTP POST notifications when events occur in your FaceSign sessions. This enables you to:
  • Track session progress without polling
  • Update your database when verification completes
  • Handle errors and retries automatically
  • Send notifications to users
Webhook Security — Production webhooks include cryptographic signatures for validation. Always verify webhook signatures in production to ensure authenticity.

Setting Up Webhooks

Create an HTTPS endpoint in your application to receive webhook events.
The examples below focus on event routing and skip signature verification for brevity. Production code must verify the X-FaceSign-Signature HMAC against the raw request body before trusting any event — see Signature validation below.
Example Webhook Handler

Event Types

FaceSign sends the following webhook events during the session lifecycle:

Webhook Payload Examples

All webhook events include these common fields:
Common Webhook Fields

Webhook Event Types

The following webhook events are currently available and correspond to the documented API contract:

session.status

Sent when the status of a session changes:
session.status payload

media.user_photo

Sent when a user selfie has been captured and is ready to download:
media.user_photo payload

media.document_photo

Sent when a document photo is captured and available:
media.document_photo payload

media.user_video

Sent when the user’s verification video is ready for download:
media.user_video payload

analysis.video

Sent when post-verification video analysis completes:
analysis.video payload

analysis.screenshot

Sent when screenshot analysis result is available:
analysis.screenshot payload

settings.avatars

Sent when the list of available avatars is updated:
settings.avatars payload

settings.langs

Sent when the list of available languages is changed:
settings.langs payload
Every event — regardless of type — carries the same four top-level fields:
  • id — unique event ID, use it for idempotent processing
  • type — one of the WebhookType values listed in the table above
  • createdAt — event timestamp in milliseconds since the Unix epoch
  • sessionId — the session the event belongs to
Media events (media.user_photo, media.document_photo, media.user_video) add a single media object containing id, createdAt, url, expires, and contentType — there are no other event-specific fields. For the full session state — node reports, AI analysis, transcript, and so on — fetch GET /sessions/:id using the sessionId from the event.

Media URLs

15-Minute Media Access — Media URLs (images, documents) in webhook payloads are signed and expire 15 minutes after generation. Download and store media immediately if you need permanent access.
Media URLs are provided in media.user_photo, media.document_photo, and media.user_video events:
Downloading Media Files

Webhook Security

Signature validation

Every webhook delivery carries an HMAC-SHA256 signature you can use to confirm that the request really came from FaceSign before trusting any of its contents. FaceSign sends two headers with every event: The signing secret is shown once per webhook in the FaceSign dashboard. Store it as an environment variable — never hard-code it.
Verify against the raw request body — the HMAC is computed over the exact bytes FaceSign sent. If you parse the JSON first and then re-serialize, any whitespace or key-order difference will make the signature check fail. Always capture the raw body, verify, and only then call JSON.parse.
Webhook signature verification

Error Handling

Retry Logic

FaceSign retries failed webhook deliveries with exponential backoff. A delivery counts as failed when your endpoint returns a non-2xx response, times out, or is unreachable. Your endpoint should:
  1. Always return HTTP 200 for successfully received events — even if downstream processing will happen asynchronously.
  2. Return 4xx for invalid payloads — these are considered permanent failures and will not be retried.
  3. Return 5xx for transient failures — these will be retried on the backoff schedule.

Idempotency

Webhooks may be delivered more than once. Each webhook event has a unique id property, which should be used to guarantee idempotent processing:
Idempotent Webhook Processing

Testing Webhooks

Local Development

Use ngrok or similar tools to test webhooks locally:
Testing with ngrok

Webhook Testing Service

You can use webhook.site for quick testing:
  1. Go to https://webhook.site
  2. Copy your unique URL
  3. Use it as your webhook URL when creating sessions
  4. View incoming webhooks in real-time

Best Practices

  1. Always return 200 OK - Even if processing fails, acknowledge receipt
  2. Process asynchronously - Don’t block the webhook response
  3. Implement idempotency - Handle duplicate deliveries gracefully
  4. Store event data - Keep webhook payloads for debugging
  5. Monitor failures - Set up alerts for webhook processing errors
  6. Handle all event types - Even if you don’t process them yet
  7. Download media immediately - URLs expire after 15 minutes

Next Steps

Sessions

Understand session structure

Error Handling

Handle errors gracefully