Webhooks for developers
The engineer reference for Feedjolt webhooks: what we deliver, the headers and timeout, verifying signatures, staying idempotent, and handling delivery failures.
When something happens in Feedjolt, we POST your payload to your endpoint. This section is the engineer-oriented reference.
For setting up a webhook (UI, picking events, getting a secret), see Integrations -> Webhooks.
What we deliver
POST application/json with three relevant headers:
Content-Type: application/json
X-Feedjolt-Signature: sha256=<hex>
X-Feedjolt-Event: status.changed
X-Feedjolt-Timestamp: 2026-04-30T12:34:56.789012+00:00The body is the event payload - see Payloads.
What we expect back
- 2xx - delivery succeeds. Logged as success.
- Anything else - logged as failure. No automatic retry today. A workspace admin can replay manually from the dashboard.
- 10-second timeout - respond fast, queue heavy work.
Three things you must do
- Verify the signature. See Signing. Without verification, anyone on the internet can forge events.
- Be idempotent. Manual replay sends the same event again; use the payload's
idas a dedupe key. - Respond fast. Return 200 in under 10 seconds. Queue any long work.
Three things to know
- Logs are your alarm. There's no auto-disable for failing endpoints today. Watch
Settings -> Webhooks -> Deliveriesor the API equivalent. - Order isn't guaranteed. Use timestamps in the payload to ignore stale events.
- New event types may appear as we ship them. If you subscribed to a small allow-list, you control your blast radius; if you subscribed to all events, expect change.
What's where
Widget Content Security Policy
The exact Content Security Policy directives the Feedjolt widget needs to load: script, connect, frame, img, style, and font sources, plus a strict CSP example.
Webhook payloads
The Feedjolt webhook event types and the headers that frame each delivery. Covers payload shape, the signature and event headers, idempotency, and stability.