Skip to content

Send signed webhooks, inspect a failed delivery's retry, then replay it

When an outbound webhook fails, you need to know what happened and how to recover. This walkthrough uses Centrali's outbound webhook views in the console to deliver a signed test event, inspect the delivery log, inspect a failed delivery's pending retry, and replay it once the endpoint is fixed.

Send is one way into Centrali, a composable backend. Here we only use the pieces needed for outbound webhooks.

Scope. This walkthrough covers outbound delivery only: sending a test event, a failed delivery and its pending retry, cancelling that retry, and replay. It uses synthetic data. It does not cover receiving inbound webhooks, and it does not cover dead-letter-queue behavior. This walkthrough uses Platform → Webhooks, where Send test event, Delivery Log, and endpoint editing live. The Send your first event to Play guide uses Send → Subscribers to publish a business event instead.

Before you start

You will need curl and (optionally) python3, plus access to a Centrali workspace.

  1. Get into a workspace. New to Centrali or joining a team? Follow Account Setup Steps 1–2 to create or join a workspace and confirm console access. This console-only walkthrough does not use the guide's service-account or local API-credential steps. (New projects can also start at centrali.io with Start building free.)
  2. Check your console access. For the built-in setup, start with the workspace_developers group. A workspace administrator adds it under Team → Users → your user → Groups → Add to Group. If Cancel retry or Replay is unavailable, ask your administrator to confirm your permissions; that action sequence has not yet been verified with a non-administrator account.

Use your console login to create subscriptions and Play's readToken to inspect captures. The Play captureUrl permits writes, so keep both Play values private and use synthetic data. For this console-based walkthrough, no service account is needed.

Part 1 — Send: signed delivery to your own endpoint

Send here means Centrali dispatches an outbound webhook to an endpoint you choose. The Send test event button sends a synthetic test event.

  1. Create a disposable receiver with Centrali Play:

    curl -X POST https://play.centrali.io/sessions

    Save the id, captureUrl and readToken. Sessions expire after one hour by default; check the returned expiresAt. Keep the captureUrl and readToken private and use synthetic data only.

  2. In the console go to Platform → Webhooks → New Webhook. Give it a Name, paste the captureUrl into Endpoint URL, choose Subscription mode → Record events and the Record Created event, then click Create webhook.

  3. On the subscription page click Send test event.
  4. In the Delivery Log tab you should see Success, HTTP 204, 1 attempt.

  5. Read back what Play captured:

    curl 'https://play.centrali.io/sessions/<session-id>/events?after=0-0' \
  -H 'Authorization: Bearer <readToken>'

    Each captured event has headers and a body whose data field is base64-encoded. The headers include webhook-signature, webhook-id and webhook-timestamp (also sent as Centrali-* headers). The signature format is v1,<base64>. To read the payload:

    echo '<body.data value>' | base64 --decode | python3 -m json.tool

    If the read request fails: 401 means the Authorization header is missing or malformed; 404 means the token is wrong, or the session ID is unknown or expired.

    An independent hosted check on 2026-10-29 verified a captured delivery's signature. Verify signatures in your own receiver using your signing secret, following signature verification.

Part 2 — Send: failure, retry, and replay

  1. Create a second subscription (Platform → Webhooks → New Webhook, with its own Name) pointed at an endpoint that cannot succeed: https://play.centrali.io/does-not-exist. It is Centrali's own disposable service, so no third party receives your test traffic. Any non-success response or connection error from the endpoint is treated as a failed attempt. Do not point test traffic at someone else's service, and do not use a 127.0.0.1 or private-network address.
  2. Click Send test event. The console may confirm with "Test queued — receiver did not respond, retrying". The delivery row shows Retrying; inspect its HTTP status (if any) and error in the log. By default the first retry is scheduled 30 seconds later, then 2 minutes, 10 minutes and 30 minutes, up to 5 attempts. The delivery can be cancelled any time it reads Retrying.
  3. Click Refresh in the Delivery Log and open the delivery to inspect the attempt so far and the pending retry.
  4. Click the delivery row to open Delivery Detail. While the delivery is Retrying, Replay is disabled ("This delivery is still in-flight. Cancel the retry first or wait for it to finish") and a Cancel retry button is shown. Click Cancel retry while it still reads Retrying; Centrali confirms with "Retry cancelled" and closes the dialog. The delivery now reads Cancelled. If you get "Delivery is in-flight, try again shortly", wait a moment and click Cancel retry again.
  5. "Fix the bug": open the subscription, click Edit, set Endpoint URL to your working Play captureUrl, and click Save changes.
  6. Click the cancelled delivery row again to reopen Delivery Detail, then click Replay. Centrali confirms with "Replay queued" and adds a new delivery row. It starts as Retrying because a replay is dispatched by the retry worker about a second later, not inline. Click Refresh and inspect the new delivery. With the working Play receiver, the expected result in this walkthrough is Success / 204. The original delivery stays in the log as Cancelled, with its own attempt history.

This walkthrough cancels the pending retry, so it does not describe later attempts or what happens when retries run out.

Retry and Replay: two names, two meanings

Name What it does
Retry Automatic re-attempt after a failed delivery
Replay Manual action that creates a new delivery from an eligible original (here, a cancelled one); the original stays in the log

Both can repeat side effects at the receiving end, so make receiver operations idempotent using a stable key for the application event or operation. Note that webhook-id identifies the delivery, not the event: a replay arrives with a new webhook-id and the same body, so do not deduplicate on webhook-id. Verify identifier behavior across retry and Replay before choosing a key.

Clean up

Delete the test subscriptions when you're done; this also permanently deletes their delivery history. The Play session expires on its own.