Webhooks

Set up webhooks

Add or manage HTTPS destinations in the product: Integrations → Webhooks.

Delivery pacing

For each workspace we send at most 10 webhook POSTs per sliding 60-second window. That keeps traffic from arriving in one tight burst. Tools like n8n, Zapier, and similar automation endpoints often fail or drop work when too many requests land at once, so we pace deliveries on our side instead of overwhelming yours.

This per-workspace rate limit is separate from retries on a single delivery (below): pacing spreads distinct matches across time; backoff spaces repeated attempts for one failed delivery.

Retries and exponential backoff

If your endpoint returns a non-2xx response, times out, or cannot be reached, SnitchFeed retries that delivery using BullMQ exponential backoff.

• Attempts: Each delivery job runs up to 10 attempts in total—that includes the first POST, so you get up to 9 automatic retries after failures.
• 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 transient errors or short outages recover.
• 404: If your endpoint keeps returning 404, we treat that as a broken URL. After enough failed attempts we deactivate that webhook in the app so it does not retry indefinitely. Other error codes still follow the backoff rules until attempts are exhausted.

Timeouts and payload expectations for a single POST are documented on match.created.

Delivery history in the app

To audit what we sent—timestamps, HTTP codes, response snippets, and status—open the product: Integrations → Webhooks → Log (requires a plan that includes webhooks). 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.match.created.