Skip to main content
When an event fires, Sevalla sends a POST request to your webhook endpoint with a JSON payload. This page documents what your endpoint receives and how to verify it.

Payload structure

Every webhook request body follows this format:

Request headers

Sevalla sends two headers with every webhook request:

Verifying signatures

Every webhook request includes an svl-signature header containing your webhook’s secret. Compare this value against the secret stored on your end to verify the request is from Sevalla.
Always verify the svl-signature header before processing a webhook. Without verification, anyone who discovers your endpoint URL could send fake events.

Event types

You can subscribe to any combination of these events when creating a webhook.

Application events

APP_CREATE, APP_UPDATE, APP_DELETE data:
APP_DEPLOY data:

Static site events

STATIC_SITE_CREATE, STATIC_SITE_UPDATE, STATIC_SITE_DELETE data:
STATIC_SITE_DEPLOY data:

Database events

Retry behavior

If your endpoint returns a non-2xx status code or doesn’t respond, Sevalla retries the delivery up to 12 times with exponential backoff: Each retry generates a new event_delivery_id but keeps the same event_id. After 12 failed attempts, the delivery is marked as failed permanently.
Return a 200 status code as quickly as possible. Process the webhook payload asynchronously to avoid timeouts. If your endpoint is slow to respond, it may be treated as a failure.

Secret rotation

When you rotate a webhook secret, you can set a grace period (0-24 hours) during which both the old and new secrets are valid. During this window, the svl-signature header will contain the old secret. Once the grace period expires, only the new secret is used. This lets you deploy updated verification logic without missing events.