Skip to main content
Webhooks let Limitguard push events to your server as signed HTTP POST requests, so you do not have to poll.
Live today: sanctions.match.new. When the OFAC SDN, EU or UN consolidated list changes an entry that matches an entity or wallet you checked, or an entry on your watchlist, Limitguard sends you the same alert GET /v1/compliance/alerts shows you. Registrations and pending deliveries are stored, so they survive restarts and deploys.trust.score.changed, trust.level.downgrade and certificate.expired can be registered, but nothing sends them yet. Every registration and list response carries delivered_events, the subset of your events that is actually sent today.
Webhooks need an API key (X-API-Key). A webhook belongs to the key that registered it: only that key can list, test or delete it, and it receives alerts for that key’s checks and watchlist only.

How It Works

When an event occurs, Limitguard sends an HTTP POST with a JSON body to every active webhook of yours that subscribed to that event type. Respond with any 2xx status within 10 seconds to acknowledge it. Anything else (a non-2xx status, a redirect, a timeout, a TLS or connection error) counts as a failed attempt and is retried with backoff. Each request carries an X-Limitguard-Signature header: the hex HMAC-SHA256 of the raw request body, keyed with the webhook secret you received at registration. Always verify it before processing the payload.

Setup

1

Register your endpoint

Send POST /v1/webhooks with your HTTPS URL and the event types you want.
Response (201 Created)
The URL must use https://, its host must resolve, and it must not resolve to a private, loopback, link-local, multicast, reserved or cloud-metadata address (IPv4 or IPv6). The same address check runs again before every delivery, since DNS can change after registration. A URL that fails any of these is refused with 422.
The secret is returned once only, in this response, and is never shown again (it is stored encrypted). Put it in a secret manager or an environment variable that is never committed. If you lose it, delete the webhook and register a new one.
2

Verify the signature

Compute the HMAC-SHA256 of the raw request body (the exact bytes you received, before any JSON parsing), keyed with your secret string, and compare its hex digest with X-Limitguard-Signature in constant time. The header is the bare hex digest, with no sha256= prefix.
Compare signatures in constant time (hmac.compare_digest in Python, crypto.timingSafeEqual in Node.js). A plain == or === comparison leaks timing information.
3

Handle the event

Every delivery has the same envelope. Dispatch on event:
Delivery body
The body is JSON with its keys sorted. Always parse it rather than relying on key order or formatting, and verify the signature against the raw bytes before parsing.
sanctions.match.new is sent for every list change that touches you, not only new listings. Read data.event_type:data.match.basis says why the alert is yours: checked (an entity or wallet you checked) or watchlist (an entry on your watchlist). data.match.kind is how it matched (crypto_address, registration, name_exact or name_tokens) and data.match.score how strongly.

Event Types

These are the event types you can register. Only sanctions.match.new is sent today; the others are accepted so an integration can subscribe ahead of time, and delivered_events tells you which of yours are live. events must list at least one of these names; there is no wildcard. An unknown name is refused with 422.

Delivery Headers

There is no timestamp header. Protect against replays by storing the event_ids you have processed and ignoring repeats.

Retries

A failed attempt is retried with exponential backoff (doubling from 30 seconds, plus up to 20% random jitter), up to 6 attempts per event: After the 6th failed attempt that event is marked failed and is not retried again. Other events keep being delivered. Limitguard waits up to 10 seconds for your response and does not follow redirects. Respond 2xx immediately and do the work asynchronously.
Deactivation. When 10 events in a row fail all their attempts for the same webhook, that webhook is deactivated: its queued deliveries are dropped and it no longer appears in GET /v1/webhooks. Any successful delivery resets the count. To resume, fix your endpoint and register the webhook again; you will get a new secret. You can still poll GET /v1/compliance/alerts for anything you missed.

Managing Webhooks

List your webhooks

GET /v1/webhooks returns your active webhooks as a JSON array. Secrets are never included.
Response

Change a webhook

There is no update endpoint. To change the URL or the events, register the new configuration and then delete the old webhook. Registering the same URL twice is allowed and creates two separate webhooks, each receiving its own copy of every event.

Delete a webhook

curl
Returns 204 No Content. The webhook and its delivery history are removed and nothing more is sent to it. An unknown ID, or one registered by a different API key, returns 404.

Testing

POST /v1/webhooks/{webhook_id}/test sends one signed test delivery to your endpoint right away. It takes no request body, makes a single attempt with no retries, and reports the result:
Response
status_code is what your endpoint answered, or null if it could not be reached. Your endpoint receives this body, signed with your real secret, so the test exercises your whole verification path:
Test delivery body
Call the test endpoint from your deployment pipeline to confirm your handler is reachable and verifying signatures before real alerts depend on it.

Best Practices

Respond immediately, process asynchronously

Return 2xx within 10 seconds, before doing any real work, and hand the event to a background queue (Celery, BullMQ, SQS and so on). A slow handler turns into timeouts, retries and, eventually, deactivation.

De-duplicate on event_id

The same event can arrive more than once, for example when your 2xx response is lost and the attempt is retried. Record each event_id together with its side effects, in one transaction, and skip any you have seen:
Python

Ignore what you do not recognise

New event types and new data fields will be added. Acknowledge unknown event values with 2xx instead of failing, or the retries will count towards deactivation.

Serve a valid certificate

Deliveries verify your TLS certificate. A self-signed or expired certificate is not refused at registration, but every delivery to it fails.

Next Steps

API Reference

All endpoints, including the four webhook endpoints

Rate Limits

The per-minute and daily limits your API key has

Error Handling

The error catalog, including webhook registration errors

Sandbox

Try the API without spending anything