Overview
Instead of polling our API for new data, you can register an HTTPS endpoint and we’ll POST to it the moment an event fires. Use webhooks to wake up an agent on a fresh earnings release, new financial statements, extracted KPIs and guidance, or insider filings; push records into your warehouse; or trigger downstream automation.New to webhooks? The setup guide walks you through a working Python receiver end-to-end in under 15 minutes. This page is the reference you’ll come back to once you’re integrated.
Webhooks are available on Scale and Enterprise plans. Manage your plan from the dashboard.
Get started
Five steps to get from zero to receiving events:1
Create a destination
Register an HTTPS endpoint and the events you want to receive from the Webhooks dashboard.
2
Set up your endpoint
Stand up an HTTPS handler that can accept JSON POSTs and read the raw request body. See the setup guide for Python + Node examples.
3
Verify the signature
Confirm each request came from us using the
FD-Signature header. See Verifying the signature.4
Test with a canned event
Fire a test event from the dashboard’s destination row and confirm your endpoint returns
2xx within 10 seconds.5
Go live
Walk through the production checklist before flipping real customer flows onto your handler.
Production checklist
Before relying on webhooks for production-critical flows, work through each of these:- Use HTTPS, not HTTP. Your endpoint URL must start with
https://. We won’t deliver to plainhttp://in production. Security → - Confirm each request actually came from us. Use the
FD-Signatureheader to check authenticity. Skip this and anyone could forge events. How to verify → - Reply within 10 seconds. Send back
200 OKquickly, then do the heavy work in the background. Slow replies count as failures and we’ll retry. Delivery behavior → - Return
2xxfor event types you don’t handle. A handler that throws on an unrecognized type turns our delivery into a failure. Acknowledge first, then decide what to process. Troubleshooting → - Don’t process the same event twice. We may deliver the same event more than once. Track which
event.idvalues you’ve handled and skip duplicates. Idempotency → - Keep your signing secret safe. Treat it like a password: never commit it to git, store it in a secret manager, and rotate it from the dashboard if it ever leaks. Security →
Event types
We publish 14 event types across six families. A destination can subscribe to any combination.Webhook event types
Full catalog: the payload each event carries, its field schema, and the API endpoint its entries match.
Payload format
Every delivery is aPOST of a JSON envelope wrapping a resource. The envelope is identical across event types; data.object carries the resource, and its shape depends on the event type.
data.object are identical to entries from the corresponding API response, so any parser you’ve written against our REST endpoints works unchanged. See Webhook event types for the per-event schema.
Headers
Every request includes:Verifying the signature
TheFD-Signature header lets you confirm the request actually came from us and wasn’t tampered with. The signature is an HMAC-SHA256 of {timestamp}.{raw_body} using your destination’s signing secret.
- Python
- Node
hmac.compare_digest / crypto.timingSafeEqual). A normal == is vulnerable to timing attacks.
Delivery behavior
A delivery succeeds when your endpoint returns any2xx response within 10 seconds. Anything else — a 4xx, a 5xx, a connection error, or a timeout — counts as a failure, and we’ll retry on this schedule:
After three failed attempts we stop trying that specific event. The destination stays active and keeps receiving new events normally; you’ll just see this delivery marked
Dead in the dashboard.
Ordering is not guaranteed. Events for the same resource can interleave, and a retry that succeeds late can land after a newer event. Don’t build logic that assumes arrival order.
Idempotency
The sameevent.id can arrive more than once: replays, retries that succeed late, network races. Your handler must be idempotent.
- Dedupe on
id(e.g. insert into aprocessed_eventstable with a unique constraint and ignore conflicts). - Don’t trust delivery order; events for the same resource can interleave.
Test mode
The Send test event button on each destination row fires a canned event withlivemode: false, shaped exactly like a real event: an earnings destination gets an earnings.created test, an insider destination gets an insider-shaped test. If your handler parses the test event, it parses real events.
A destination subscribed to several event types gets a test of the first type it subscribes to. To exercise a specific one, replay a real delivery of that type from Recent events instead.
Test events are delivered only to the destination you fired them from, and are throttled to 1 per minute per destination.
Security
- HTTPS only. We refuse to deliver to plain
http://URLs in production. - SSRF defense. We resolve your URL’s IP at every delivery attempt and reject private (RFC 1918), loopback, link-local, and metadata-service ranges.
- Signing-secret rotation. Use Regenerate secret on the destination’s row whenever you suspect a leak. The old secret stops working as soon as you rotate, so deploy the new secret to your handler in lockstep.
- Secret access. Re-copy your secret from the destination’s row in the dashboard if you misplace it. Retrieval is gated by your dashboard login; API keys cannot read signing secrets.
Limits
Troubleshooting
Destination keeps auto-disabling. Open the destination’s expanded row and checkRecent failures. Your endpoint is probably 5xx-ing or timing out beyond 10s. The fastest debug path is replaying a recent failed delivery from Recent events and inspecting the response body that came back.
Some event types fail while others succeed. Open Recent events and compare the Event and Response columns: if one family of events fails while the rest deliver fine, the problem is in your handler’s branch for those types, not the connection. Your server logs will have the stack trace, and replaying one of the failed deliveries from Recent events reproduces the exact payload on demand. A destination in this state never auto-disables, because the successful deliveries keep resetting the consecutive-failure counter, so it can stay half-broken indefinitely. If you don’t need those event types, edit the destination and unsubscribe from them.
Signature verification fails. Three usual suspects:
- You parsed the body before computing the HMAC. Always verify the raw bytes.
- The signing secret in your config is stale after a rotation. Re-copy from the dashboard.
- Your server has clock drift > 5 minutes. We reject signatures outside the skew window.
Active (not Disabled). Fire a test event from the row’s ⋯ menu; if that doesn’t arrive within ~5 seconds, the destination URL is unreachable from our network (check firewalls / IP allowlists).
Still stuck? Open a ticket via Support and include the destination id + a recent event id from the dashboard.
See also
- Webhook event types — the full catalog with payload schemas.
- How to set up webhooks — step-by-step walkthrough with a working Python receiver.
- Open the Webhooks dashboard to create your first destination.