Delivery, Retries, and Failures
Retry behavior, why a subscription is disabled after repeated failures, who gets notified, and how to recover.
This page explains what Preczn does when your endpoint is slow, erroring, or unreachable — including the conditions under which a subscription is automatically disabled, who is notified, and how to recover.
The delivery attempt
Each matching event produces one notification, and each notification produces one delivery attempt in your history. A single attempt may involve several HTTP requests, because retries happen inside it.
| Setting | Value |
|---|---|
| Method | POST |
| Timeout per request | 5 seconds |
| Retries | Up to 3, with exponential backoff |
| Retried on | Connection and network errors, DNS failures, timeouts, and 5xx responses |
| Not retried on | Any 4xx response |
| Success | Any 2xx response |
Retries are automatic and require nothing from you. Once the retries are exhausted, the attempt is final — the notification is not delivered again on its own. Transaction deliveries can be resent manually, as described below; other event types cannot.
Retries are not separate attempts in your historyYour delivery history records one entry per notification with its final outcome, not one entry per HTTP request. So a notification that failed shows as a single failed attempt even though we tried up to four times.
The consecutive failure counter
Every subscription carries a counter of consecutive failed notifications.
- A failed notification increments it by one.
- A successful notification resets it to zero.
The counter moves once per notification, not once per retry — a notification that exhausted all its retries still only adds one.
Because any success resets it, the counter only climbs when a subscription is failing continuously. An endpoint that fails occasionally and succeeds in between will never accumulate toward the threshold.
Automatic disabling
At 25 consecutive failed notifications, Preczn disables the subscriptionWhen the counter reaches 25, the subscription is set inactive and stops delivering. An email is sent to notify you.
This protects both sides: it stops us hammering an endpoint that is clearly not accepting traffic, and it stops your failure queue growing silently forever.
Who receives the email
The notification goes to one recipient — the user who created the subscription. It is not sent to all platform users, not to a configurable address, and not to an admin distribution list.
| Recipient | The email address of the user account that created the subscription |
| Subject | Preczn - Webhook Subscription Automatically Disabled |
| Contents | The subscription's ID, its endpoint URL, and its description if it has one |
If the creating user has been removed, nobody is emailedThe recipient is resolved from the user account that created the subscription. If that account no longer exists — someone left and their access was revoked — the subscription is still disabled, but the email is silently skipped.
This is the most common reason a subscription appears to have gone quiet with no warning. If your subscriptions were created by an individual rather than a shared or service account, consider recreating them under an account that will outlast any one person, and monitor subscription status yourself rather than relying only on the email.
Recovering from a disabled subscription
- Fix the endpoint first. Check the delivery history for the recorded responses and errors — that is the evidence of what was actually failing. Re-enabling before the cause is fixed just spends another 25 notifications getting disabled again.
- Re-enable the subscription. Toggle it active in the dashboard under Settings → Webhooks, or
PATCH /v1/webhooks/{webhookId}with"active": true. Remember thatPATCHreplaces the subscription, so sendendpointUrlandeventsas well — see Subscribing to Webhooks. - Backfill the gap yourself. Events that occurred while the subscription was inactive were not queued and will not arrive after re-enabling. Reconcile the affected window against the API — for example by listing transactions or re-reading merchant and form records — before trusting the resumed stream.
The subscription keeps its ID, signing secret, and delivery history throughout, so no code changes are needed on your side to resume. The counter clears on the next successful notification.
Delivery history
Every attempt is recorded and viewable per subscription in the dashboard. Each record contains:
- The notification's
idand event type - The endpoint URL it was sent to
- Whether it succeeded
- The full request body that was sent
- The response body on success, or the error on failure
- When it was attempted
History is retained for 15 daysDelivery records are automatically deleted after 15 days. They are an operational debugging aid, not a compliance record. If you need a durable audit trail of what Preczn sent you, persist the notifications on your own side as you receive them.
Older deliveries appear marked Archived: the fact of the delivery and its outcome remain visible, but the stored request and response bodies are gone, so they cannot be inspected or resent.
Resending a notification
A past transaction notification can be resent from the dashboard — useful when your endpoint was broken and you want a specific event redelivered after fixing it.
Open the transaction in the Transaction Log, go to its Webhook Deliveries tab, expand the delivery you want, and choose Resend Webhook.
What gets sent: the original eventType and data, delivered using the subscription's current configuration. It goes to whatever endpoint URL and custom header the subscription has now, not the ones it had at the time.
A resend carries a newidThe resent notification is a new notification: it reuses the original
eventTypeanddatabut is issued a fresh top-levelid. Deduplicating onidwill therefore not suppress it — see making your handler idempotent.
Constraints:
- Transaction deliveries only. Resend is reached through a transaction's detail view, so there is no equivalent for merchant, loan, or boarding form deliveries.
- The subscription must be active. Resending against a disabled subscription fails and prompts you to re-enable it first.
- The delivery must not be archived. Once the stored request and response age out, the original body no longer exists to resend.
- Resends are queued, not immediate. Confirmation means the resend was accepted, not that it was delivered. Check the delivery history for the outcome — a resend produces its own new entry.
- Dashboard only. There is no public API endpoint for resending.
FAQ
Why was my webhook subscription disabled?
Because 25 notifications in a row failed. A notification fails when your endpoint returned a 4xx or 5xx, closed the connection, could not be resolved, or did not respond within 5 seconds — after up to 3 retries.
Open the subscription's delivery history in the dashboard and read the recorded responses on the failed attempts. That tells you which of those causes it was. The most common are an expired TLS certificate, a firewall or IP allowlist change, a deploy that moved or removed the route, and handlers that grew slow enough to cross the 5-second timeout under load.
I never received the disable email. Why not?
The email goes only to the user account that created the subscription. If that account has since been deleted, the email is skipped entirely — the subscription is still disabled, but silently.
It is also worth checking spam filtering for the subject Preczn - Webhook Subscription Automatically Disabled, and confirming who actually created the subscription, which is often not the person now responsible for the integration.
Can I change who gets notified, or add more recipients?
Not currently — the recipient is always the subscription's creator and is not configurable. If you need this to reach a team, create subscriptions under a shared or service account whose mailbox is monitored by more than one person. Do not treat the email as your only signal; check subscription status from your own monitoring as well.
Can I raise the 25-failure threshold, or turn auto-disabling off?
No, the threshold is fixed and cannot be disabled per subscription. In practice it is difficult to hit accidentally, because any single success resets the counter to zero — reaching 25 means the endpoint failed 25 times consecutively with no successes in between.
Will Preczn redeliver what I missed while disabled?
No. There is no queue held during the outage and no automatic backfill on re-enable. Delivery resumes from the next event onward, so the gap has to be reconciled through the API.
This is why the 15-day delivery history matters: if the outage was recent, the history shows exactly which notifications failed, which tells you precisely what to reconcile.
Does a slow endpoint count as a failure?
Yes — anything over the 5-second timeout is a failure, even if your server eventually finishes the work. This is the failure mode that most often surprises people, because it appears only under load and the work does complete. Acknowledge with a 2xx immediately and process asynchronously.
If I have several subscriptions, does one failing affect the others?
No. The failure counter, active flag, and delivery history all belong to the individual subscription, so one endpoint failing and being disabled leaves your other subscriptions delivering normally — including a second subscription pointed at the same URL.
How do I monitor subscription health without waiting for an email?
Read the subscription's active flag from GET /v1/webhooks on a schedule and alert if anything you expect to be active is not. This catches the case where the disable email was never sent because its recipient account was removed.
On your own side, alerting on the absence of expected notifications is the stronger signal — a webhook that stops arriving is invisible in your logs, so a check for "no form.completed in the last N hours" catches problems that error-rate monitoring cannot.
Updated about 2 hours ago