Retry Handling

Cresora automatically retries webhook deliveries that don't receive a 2xx response. Your receiver must handle retries gracefully.

Retry schedule

After the 3rd retry fails, the delivery is recorded EXHAUSTED and Cresora stops. No further attempt is made, and no notification is sent — you find out by inspecting the delivery log or by reconciling. See Failed deliveries.

These are the platform defaults. GET /webhook-metadata returns the retry policy actually in force — it is derived from server configuration, so it cannot drift from behaviour the way a hardcoded table can.

What triggers a retry

• 5xx from your endpoint
• 403, 408, 429, or any other 4xx not in the permanent list below
• A redirect (3xx) — Cresora does not follow redirects; register the final URL
• No response within 10 seconds (timeout)
• Connection refused or DNS resolution failure

Statuses that are never retried

400, 401, 404, 405, 410 and 422 are treated as deliberate, permanent rejections. The delivery fails on its first attempt and is never retried.

Asking Cresora to slow down

If you return a Retry-After header on a retryable response, Cresora honours it in place of the ladder step above — so you can push the next attempt further out than the schedule would, for example while you drain a backlog behind a 429.

Two limits:

• Delta-seconds only. Retry-After: 120 works. The HTTP-date form is ignored, and the ladder step is used instead — so a date-formatted header silently does nothing.
• Capped at 24 hours. A larger value is clamped, so a misbehaving receiver cannot pin a delivery arbitrarily far into the future.

Because a honoured Retry-After replaces the ladder delay, it can stretch the total window well past the default ~35 minutes. The 4-attempt count does not change.

Idempotent retry handling

Because Cresora retries, your handler will receive the same event multiple times. Always handle events idempotently:

import crypto from "node:crypto";

// Use event.id as an idempotency key
async function handleWebhookEvent(event) {
  // Check if we've already processed this event
  const existing = await db.processedEvents.findOne({ eventId: event.id });
  if (existing) {
    console.log(`Duplicate event ${event.id} — skipping`);
    return; // Already handled; return 200 anyway
  }

  // Process the event
  await processEvent(event);

  // Record that we've handled it
  await db.processedEvents.insert({
    eventId: event.id,
    processedAt: new Date(),
  });
}

Respond quickly, process asynchronously

Your endpoint must respond within 10 seconds. For complex processing, respond immediately and handle the work in a background queue:

app.post("/webhooks/cresora", async (req, res) => {
  verifySignature(req); // Throws on invalid signature — respond 400
  res.sendStatus(200);  // Respond immediately
  await queue.enqueue(req.body); // Process asynchronously
});

Manual replay

You can manually replay any webhook delivery from the Partner Portal:

1. Developers → Webhooks — open the endpoint's delivery log
2. Find the failed delivery
3. Click Replay

Replayed events have the same id as the original — the stored envelope is resent verbatim, so your idempotency logic will correctly deduplicate them.

Two limits apply:

• One delivery at a time. There is no bulk replay; you replay a specific delivery.
• 100 replays per endpoint per hour. Exceeding it returns 429 with a Retry-After header.

If Cresora has suspended the endpoint (see Failed deliveries), replay is rejected until you resume it.