Introduction

Webhooks send outbound Level events to your own systems. When a selected alert, device, or group event occurs, Level queues an HTTP POST request to the URL you configure.

This article covers outbound event webhooks configured under Settings → Webhooks. To start a Level automation from an inbound request, see Webhook Trigger.

For request formats, signature verification, and receiver guidance, see Webhooks: Developer Guide.

⚙️ PREREQUISITES

A publicly reachable endpoint that accepts HTTP POST requests with a JSON body.
Admin access to your Level organization.
A secure secret for signature verification.

Use an HTTPS endpoint so webhook contents and signatures are encrypted in transit.

Webhook settings

Go to Settings → Webhooks. The page has two tabs:

Webhooks lists your configured destinations.
Requests shows delivery attempts and responses.

Create a webhook

Click + Add webhook or + Create webhook in the empty state.
Enter the destination URL.
Enter a Secret to sign requests.
Leave Enabled on to begin delivery, or turn it off to save the webhook in a paused state.
Under Events to send, choose all currently available event types or select individual types.
Click Add webhook.

💡 TIP: Generate a high-entropy secret with a password manager and store it in the secret manager used by your receiving service.

⚠️ WARNING: The saved secret cannot be viewed later. Store it before you click Add webhook. If it is lost or exposed, edit the webhook, set a new secret, and update your receiving service.

Available event types

Event	`event_type`	When it is sent
Alert active	`alert_active`	A new alert is raised.
Alert resolved	`alert_resolved`	An existing alert is resolved.
Device created	`device_created`	A device is added.
Device updated	`device_updated`	Device data or configuration changes.
Device deleted	`device_deleted`	A device is removed.
Group created	`group_created`	A device group is created.
Group updated	`group_updated`	A group's name or configuration changes.
Group deleted	`group_deleted`	A group is deleted.

Selecting all events stores all event types currently shown in Level. Review the webhook after new event types are released if you want to subscribe to them.

Payload structure

Every event uses this JSON envelope:

{  "event_type": "device_created",  "event_id": "550e8400-e29b-41d4-a716-446655440000",  "occurred_at": "2026-03-13T18:30:00.000Z",  "data": {    "id": "..."  }}

Field	Type	Description
`event_type`	string	One of the configured event types.
`event_id`	UUID	Identifies the event and remains stable when the same payload is delivered again.
`occurred_at`	ISO 8601 datetime in UTC	Time the event was generated.
`data`	object	Resource-specific event data.

Use event_id as an idempotency key. A request can be repeated because of automatic retry behavior or a manual re-run.

See Webhooks: Developer Guide for the request format, signature verification, and receiver checklist.

Verify request signatures

When a secret is configured, Level computes HMAC-SHA256 over the exact JSON request body and sends the result in this header:

X-Level-Signature: sha256=

Verify the signature before parsing or processing the JSON:

Read the raw request body as bytes.
Compute HMAC-SHA256 over those exact bytes, using the webhook secret as the key.
Encode the digest as lowercase hexadecimal and prefix it with sha256=.
Compare the computed value with X-Level-Signature using a constant-time comparison.
Reject the request if the values do not match.

ℹ️ NOTE: The signature header is omitted when the webhook has no secret. Configure a secret for every production webhook.

Return a successful 2xx response after accepting the event. If processing may take time, place the verified event on your own queue and return before performing the long-running work.

Review delivery logs

Open the Requests tab to inspect recorded delivery attempts.

Each row includes:

Delivery status.
HTTP response status, when the destination returned one.
Destination URL.

Open a row to see details such as the event time, full URL, error message, and response body.

Automatic retries

Failed deliveries may be retried automatically. Your endpoint can receive the same event_id more than once, even if an earlier request was processed successfully but its response did not reach Level.

Store processed event IDs or make each operation naturally idempotent.

Re-run a request manually

After correcting the destination or receiver, open a request and click Re-run request. Level immediately resends the original stored payload.

⚠️ WARNING: Re-running a request sends the same event again. Deduplicate by event_id before creating records or performing other non-idempotent work.

Manage existing webhooks

The Webhooks tab shows each destination URL and enabled status. From there, you can edit the URL, secret, event selection, or enabled state, or delete the webhook.

Turning Enabled off pauses future delivery without deleting the configuration. Turn it back on when the destination is ready.

FAQ

Who can manage webhooks? Organization administrators can create, edit, view, re-run, and delete webhooks.
What format does Level send? Level sends an HTTP POST with Content-Type: application/json and the envelope documented above.
How do I verify a request? Configure a secret and verify the X-Level-Signature HMAC against the raw body before parsing JSON.
Why did I receive the same event twice? A failed response, automatic retry, or manual re-run can repeat a delivery. Deduplicate with event_id.
Why is a request marked failed? Open it under Requests and review the status code, error, and response body. Confirm that the URL is publicly reachable and returns a successful 2xx response.
Can I send events to more than one endpoint? Yes. Create a webhook for each destination and choose its event types separately.
Can I recover a lost secret? No. Set a new secret on the webhook and update the receiving service.

Webhook Settings