Monitor, retry and recover deliveries

The Outbound Gateway records every message, delivery and attempt for 35 days. You can see what a customer's endpoint answered, find every failing endpoint across all customers, retry one delivery, re-send everything that failed during an outage, or replay messages skipped while an endpoint was paused. None of this requires publishing the event again, and every copy keeps the original webhook-id. Everything on this page is also available in the dashboard's Outbound webhooks page, in the TypeScript and Go SDKs, and through MCP. For a product overview, see the Outbound Gateway.

Inspect delivery history

Filter deliveries

Filter an endpoint's deliveries with status (sent, failed, stalled, received or rejected), event_type or message_id, and page with limit (up to 100) and offset. The filters combine, so "failed invoice.paid deliveries to this endpoint" is one call. Each attempt records its status code, duration, response headers (up to 8 KiB) and the start of the response body (4 KiB per attempt; the latest response is kept up to 120 KiB). Custom endpoint headers are left out of the recorded request because they can hold credentials.

curl --user "$RELAY_KEY:$RELAY_SECRET" \
  "https://my.webhookrelay.com/v1/outbound/endpoints/6f0c2c0e-5a3b-4f43-9d0a-4c4f7d7a2b11/deliveries?status=failed&event_type=invoice.paid&limit=20"

The same filters in the SDKs (TypeScript @webhookrelay/sdk 0.3.0 or later, Go webhookrelay-go 0.7.0 or later):

const failed = await relay.outbound.endpoints.deliveries(endpointId, { status: "failed", event_type: "invoice.paid", limit: 20 });
const one = await relay.outbound.endpoints.deliveries(endpointId, { message_id: messageId });

failed, err := api.ListOutboundDeliveries(&webhookrelay.OutboundDeliveryListOptions{
    EndpointID: endpointID,
    Status:     "failed",
    EventType:  "invoice.paid",
    Limit:      20,
})

MCP: list_outbound_deliveries takes the same filters.

In the dashboard

Each message has its own page: a summary card (consumer, message ID, when it was received) beside the payload, then every endpoint it went to, by name, with the full attempt history and each response. From there you can retry a delivery. The publish dialog prefills the chosen event type's example payload as a template, and the create dialogs for consumers, event types and endpoints show the equivalent SDK call next to the form, so you can copy it into your code.

Retry one delivery

POST /v1/outbound/endpoints/{id}/retry with a message_id re-sends that message to that endpoint in the background and returns a recovery task. If the delivery is waiting for its next scheduled retry, it is sent now. A delivery whose first attempt is still queued is refused with 409.

curl --user "$RELAY_KEY:$RELAY_SECRET" \
  -H 'Content-Type: application/json' \
  -X POST https://my.webhookrelay.com/v1/outbound/endpoints/6f0c2c0e-5a3b-4f43-9d0a-4c4f7d7a2b11/retry \
  -d '{ "message_id": "0199cf5e-7a3c-7d2e-9b1a-3f4e5d6c7b8a" }'

Recover failed deliveries and replay missed ones

Two recovery tasks walk an endpoint's messages from since (RFC 3339, defaulting to 24 hours ago, at most 35 days back) until now:

• Recover (POST /v1/outbound/endpoints/{id}/recover) re-sends deliveries that ran out of retries, typically after the customer fixes an outage.
• Replay missing (POST /v1/outbound/endpoints/{id}/replay-missing) sends deliveries that were skipped while the endpoint was paused or disabled. Resume the endpoint first.

curl --user "$RELAY_KEY:$RELAY_SECRET" \
  -H 'Content-Type: application/json' \
  -X POST https://my.webhookrelay.com/v1/outbound/endpoints/6f0c2c0e-5a3b-4f43-9d0a-4c4f7d7a2b11/recover \
  -d '{ "since": "2026-10-08T00:00:00Z" }'

Each call answers 202 with a task. Follow its progress with GET /v1/outbound/recovery-tasks/{id}. status moves from pending to running to completed (or failed with an error), and processed counts the deliveries handled so far. A re-sent delivery starts a fresh retry schedule and keeps its earlier attempts in the history. An account can have up to 10 active recovery tasks.

The SDK equivalents:

const task = await relay.outbound.endpoints.recover(endpointId, { since: "2026-10-08T00:00:00Z" });
await relay.outbound.endpoints.resume(endpointId);
await relay.outbound.endpoints.replayMissing(endpointId);
await relay.outbound.endpoints.retry(endpointId, messageId);
const progress = await relay.outbound.recoveryTasks.get(task.id);

task, err := api.RecoverOutboundDeliveries(endpointID, time.Now().Add(-48*time.Hour))
_, err = api.ResumeOutboundEndpoint(endpointID)
_, err = api.ReplayMissingOutboundDeliveries(endpointID, time.Time{}) // zero time: last 24 hours
_, err = api.RetryOutboundDelivery(endpointID, messageID)
progress, err := api.GetOutboundRecoveryTask(task.ID)

Watch endpoint health

With many customers, some endpoints will always be failing, so health is a list you check, not an alert. The gateway tracks it on each endpoint: state, consecutive_failures, failing_since and stats (attempts and failures over the last 24 hours). An endpoint becomes failing after 5 failed attempts in a row, or when one delivery runs out of retries, and returns to active on the next success. Failing endpoints never open incidents or send email to your account.

• GET /v1/outbound/health counts endpoints by state and reports the account's attempts and failures over the last 24 hours (updated within about 15 seconds).
• GET /v1/outbound/endpoints?state=failing lists failing endpoints across all consumers, longest failing first. Add consumer to narrow it down.

curl --user "$RELAY_KEY:$RELAY_SECRET" https://my.webhookrelay.com/v1/outbound/health
curl --user "$RELAY_KEY:$RELAY_SECRET" "https://my.webhookrelay.com/v1/outbound/endpoints?state=failing&limit=20"

const { endpoints, stats } = await relay.outbound.health();
const failing = await relay.outbound.endpoints.listAll({ state: "failing", limit: 20 });

health, err := api.GetOutboundHealth() // health.Endpoints["failing"], health.Stats.Failures
failing, err := api.ListAllOutboundEndpoints(&webhookrelay.OutboundEndpointListOptions{
    State: webhookrelay.OutboundEndpointStateFailing,
    Limit: 20,
})

MCP: get_outbound_health, and list_outbound_endpoints with a state. The dashboard shows the same data on the Endpoint health tab: the counts by state and the failing endpoints across all consumers, longest failing first. Use POST /v1/outbound/endpoints/{id}/pause to stop deliveries to an endpoint your customer is migrating, and .../resume to start them again. See endpoint states for how endpoints move between active, failing, paused and disabled.

Transform or drop payloads with Functions

Attach a Function to an endpoint with function_id to tailor what one customer receives. The Function gets the published JSON payload as r.body, and it can:

• replace the body with r.setBody(...). The result must be valid JSON up to 256 KiB.
• drop the message with r.stopForwarding(). The delivery is recorded as rejected, "Message dropped by Function".

const invoice = JSON.parse(r.body)

if (invoice.amount === 0) {
  r.stopForwarding()
} else {
  r.setBody(JSON.stringify({ id: invoice.invoice_id, total: invoice.amount / 100, currency: "USD" }))
}

Outbound Functions can change only the body. The method, URL and headers belong to the endpoint, so a Function that changes them fails the delivery with an explanatory error. The Function runs once per message and endpoint, and its result is reused for every retry and replay. The Function attached when a message is published is the one that runs for it. If a worker crashes before the result is saved, the Function can run again, so avoid external side effects.

Limits

Your plan sets how many customers, endpoints and event types you can register, and how many messages you can publish each month. Outbound webhooks are on every plan, Free included.

A message is one accepted publish. It counts once however many endpoints receive it, retries and replays don't count again, a duplicate publish with the same idempotency key doesn't count, a test event sent to one endpoint doesn't count, and a payload up to 256 KiB is one message. Outbound messages don't count toward the inbound webhook quota. Creating a consumer, endpoint or event type beyond your plan's count is refused with 403.

Monthly message quota and message packs

When the account has published its monthly quota, publishing returns 429 until the next billing period. Messages already accepted keep being delivered and retried. To keep publishing, add extra outbound message packs (recurring add-ons) or upgrade on the plan page:

Enterprise plans can raise or remove any limit.

GET /v1/outbound/access (MCP get_outbound_access) returns your account's effective limits, with the message quota including packs, and this billing period's usage. The other limits apply to every plan:

MCP tools and the dashboard agent

Every REST operation has an MCP tool with the same name. The dashboard agent uses the same tools, so you can ask it things like "which endpoints are failing?" or "recover customer_42's failed deliveries since Monday". Tools follow your role and any outbound token restriction, and configuration, secret and recovery changes are audited the same way as REST calls. create_outbound_endpoint accepts an optional secret to import an existing signing secret.

Restrict tokens to outbound

Give each service and agent the smallest outbound permission it needs. A token with permissions.outbound set reaches only /v1/outbound/* and the outbound MCP tools, whatever its role, and its role is still an upper bound:

Create one on the Access Tokens page (the Outbound option) or with the token API; see Create an access token.

Moving from another provider? Each migration guide links a machine-readable playbook under https://webhookrelay.com/outbound-migration/ that a coding agent can follow with these tools, up to a human approval step before any traffic moves.