Webhook infrastructure with guaranteed delivery and retries

Paragon's ActionKit Triggers guarantees webhook delivery by default: a failed delivery retries with exponential backoff over a 24-hour window, every payload is signature-verified, and an endpoint that keeps failing is auto-disabled and flagged rather than silently dropped, across hundreds of triggers spanning dozens of integrations, at no additional cost on any Paragon plan. Failure gets caught, retried on a defined schedule, and reported plainly once the system gives up, instead of vanishing with no record.

The failure mode it prevents is common. A webhook fires once, the receiving endpoint is down or returns a 500, and if nothing is watching, the event is gone: no retry, no record, no alert. The customer who was supposed to see their CRM update, their support ticket route, or their agent react to a new message never does, and nobody finds out until they ask why.

What guaranteed webhook delivery really means (and what it doesn't)

Paragon delivers webhooks at-least-once: every event keeps retrying until your endpoint returns a 2xx or the 24-hour backoff window on ActionKit Triggers runs out, and every payload carries a signature you can verify before you trust it. No credible webhook vendor, Paragon included, claims exactly-once delivery. The moment a retry and a slow acknowledgment cross paths, an event can arrive twice, and any system implying otherwise is overstating what its infrastructure actually does.

"Guaranteed delivery" is really shorthand for four properties working together:

• At-least-once delivery. An event keeps retrying until it's acknowledged or the retry ceiling is hit, not until some fixed number of attempts passes and the system moves on regardless.

• Idempotency on your end. Because delivery is at-least-once, your endpoint has to handle seeing the same event ID twice without double-processing it.

• Exponential backoff. Retries space out with increasing wait time instead of hammering a downed endpoint every second.

• A dead end that isn't silent. After enough failures, a mature system disables the destination and alerts the owner, or moves the event somewhere for manual replay, instead of retrying forever or quietly dropping it.

Paragon's webhook infrastructure is built around all four, and it's the layer processing tens of millions of requests per day, per customer, underneath products like Zendesk, Postman, and CrewAI.

How ActionKit Triggers delivers events to your webhook

You configure one webhook URL, and Paragon delivers every subscribed event for every one of your users to it. Under Settings → ActionKit in the dashboard, you set a webhook URL that receives events on behalf of all your users, and Paragon generates a Signing Secret alongside it so you can verify every incoming payload actually came from Paragon rather than from someone who guessed your URL.

From there, the flow is three steps: configure the webhook URL and Signing Secret once, activate the specific trigger you want for a connected user (a Slack message received, a Salesforce record updated, a GitHub issue opened), then let the event fire. Delivery lands at your webhook within a few seconds, or shows up in ActionKit Logs if you'd rather trace it there first. Authentication to the API runs on a Bearer token, the same Paragon User Token JWT used for paragon.authenticate.

The catalog covers hundreds of triggers across dozens of integrations, including Slack, GitHub, HubSpot, Salesforce, Google Calendar, Jira, ClickUp, Gmail, Google Sheets, Google Drive, Calendly, and Notion. The exact request and response shapes are documented in the Triggers API reference.

What happens when a delivery fails

A failed delivery doesn't get one shot. If your endpoint returns an error or times out, ActionKit Triggers retries with exponential backoff across a 24-hour window, verifying the payload signature on every attempt, before it gives up. If the endpoint keeps failing past that window, Paragon auto-disables it and alerts you, so a broken listener doesn't keep silently losing events for days on end.

This retry system belongs to Triggers specifically, and it's separate from Workflows' own retry mechanism, which applies to steps inside a deployed workflow rather than to an inbound webhook delivery. A failed workflow step retries up to five times with its own exponential backoff, roughly 10, 20, 30, 50, and 80 seconds apart, applied per step, and the initial attempt plus every retry on that step together still count as one billed task, not one task per attempt. The two systems solve related but distinct problems: Triggers retries getting an event to your door, Workflows retries what your automation does once the event is inside. Don't assume one covers the other.

Custom Webhooks for events beyond the trigger catalog

If the event you need isn't in the pre-built trigger catalog, Custom Webhooks (available on Pro plan and above) let you subscribe directly to whatever the third-party app can send. There are two ways to set one up: an API-request flow, where the subscription is created programmatically and references {{settings.webhookURL}} when a user enables a workflow, or a manual flow, where a developer or end user registers the URL directly in the integration's own settings. The SDK function paragon.getCustomWebhookUserManualUrl generates the user-specific URL for that manual path.

Because a Custom Webhook is app-level rather than routed through Paragon's own trigger infrastructure, incoming events have to be matched back to the right user using provider ID properties in the payload; get that wrong and one customer's event can land against another customer's account. Payload verification supports pre-configured common methods, plus custom-code HMAC digest options for anything nonstandard.

One distinction worth being precise about: the 24-hour backoff window described above is documented for ActionKit Triggers, the pre-built catalog. Paragon's Custom Webhooks documentation doesn't restate that same schedule for developer-defined webhooks, so treat the retry behavior there as a separate, unconfirmed number rather than assuming it's identical.

Monitoring trigger status and log retention

Every trigger event shows up on the dashboard's Monitoring page, under the Triggers tab, with an Event ID, the integration it came from, the time it was received, and a status: Success, Delivery Failures, Processing Failure, or Queued. Filtering by user, integration, status, or date range turns "a customer says something didn't sync" into a five-minute lookup instead of a support escalation with no evidence.

How long that history sticks around depends on plan: Trial plans keep 7 days or 50,000 logs, Pro plans keep 30 days or 1 million logs, and Enterprise plans set retention to whatever the account needs. Logs rotate automatically once a plan hits its limit.

For teams that want trigger events in their own observability stack instead of checking the dashboard, Event Destinations forward them to Sentry, Slack, Datadog, or New Relic, plus a generic webhook destination if none of those fit. It's the same event data, routed to wherever your team already looks when something breaks.

How Paragon fits

The end-to-end flow: configure a webhook URL and Signing Secret once, under Settings → ActionKit in the dashboard. Activate the triggers you want for each connected user, through the dashboard or the API. An event fires on a user's connected app, Paragon delivers it to your webhook within a few seconds, and you verify the signature before trusting the payload. If delivery fails, the event enters the 24-hour backoff cycle, retried and re-signed on every attempt, rather than disappearing after one bad response. If it never succeeds, Paragon auto-disables the destination and alerts you instead of retrying forever. Every attempt is traceable in ActionKit Logs or forwarded to Sentry, Datadog, or New Relic, so a failure shows up as a specific event with a status, not a support ticket with no starting point.