Webhooks
Webhook events, delivery pacing, retries and backoff, delivery history in the app, and OpenAPI.
| Event | When it fires | Specification |
|---|---|---|
mention.created | SnitchFeed stored a new mention for your organization (listener matched a post or comment) and routed it to this endpoint. | Event and JSON body |
mention.resent | Someone queued an existing mention from the app (Send to webhook). Same JSON body shape as mention.created. | Same body as mention.created |
Set up webhooks
Add or manage HTTPS destinations in the product: Integrations → Webhooks.
Delivery pacing
Each webhook destination has two independent, configurable limits (set in Integrations → Webhooks → Advanced in the app):
- Requests per minute — defaults to 10 deliveries per sliding 60-second window.
- Concurrent requests — defaults to 1 in-flight delivery at a time.
Tools like n8n, Zapier, and similar automation endpoints often fail or drop work when too many requests land at once — n8n, for example, drops anything beyond its configured inflight limit (5 by default) regardless of how spread out those requests are over time. That's why concurrency and rate are separate knobs: a per-minute cap alone can't stop a burst of simultaneous deliveries from tripping a destination's own inflight limit. Raise either limit for destinations that can handle more throughput (e.g. Clay, Make.com scenarios backed by a higher-throughput API step).
These per-destination limits are separate from retries on a single delivery (below): pacing spreads distinct matches across time and concurrency; backoff spaces repeated attempts for one failed delivery.
Retries and exponential backoff
If your endpoint times out, cannot be reached, or returns a retryable error (for example 5xx, 429, or most other non-permanent 4xx), SnitchFeed retries that delivery with exponential backoff.
- Attempts: Each delivery runs up to 10 attempts in total. That includes the first POST, so you get up to 9 automatic retries after transient failures. The same
event.idis kept across retries of one delivery. - Backoff: Retries use an exponential strategy with a 30 second base delay. Waits grow from that base (each delay roughly doubles), so we do not hammer your URL while short outages recover.
- Permanent failures (no retries): 401, 403, 404, and 410 fail that delivery immediately. 404 / 410 also deactivate the webhook so a broken URL does not keep firing. 401 / 403 still count toward consecutive failure auto-pause (after enough exhausted deliveries).
- HTTPS only: Destinations must use an HTTPS URL.
Timeouts and payload expectations for a single POST are documented on mention.created (mention.resent uses the same body).
Delivery history in the app
To audit what we sent (timestamps, attempt count, HTTP codes, response snippets, and status), open the product: Integrations → Webhooks → Log (requires a plan that includes webhooks). Each row is one logical delivery (one mention to one endpoint). The Attempts column shows how many times we POSTed, including retries. You can filter by status, endpoint, and date range, page through results, and expand a row to read the full stored response body when available.
OpenAPI
Machine-readable contract: GET https://api.snitchfeed.com/v1/openapi.json — see webhooks.mention.created.