Managing Webhooks

Available via: Dashboard and API (private key). Sent events, replay and delivery attempts: API only.

From the Dashboard

Go to Settings → Developers. The Webhooks section lists each webhook's URL, Events, Status and Created date. From there you can:

• Add a webhook: click Add webhook.
• Edit a webhook: click the pencil icon to change its URL or events, or to enable or disable it.
• See its signing secret: click the key icon.
• See why a delivery failed: Error appears in Status when the last delivery failed; click it to see the reason.
• Delete a webhook: click the delete icon and confirm.

See Developers. The sections below cover the same operations via the API.

List All Webhooks

curl https://api.inflowpay.com/api/webhook \
  -H "X-Inflow-Api-Key: inflow_prod_your_key"

Response:

[
  {
    "webhookId": "webhook_abc123",
    "webhookUrl": "https://yourserver.com/webhooks/inflow"
  }
]

Get a Specific Webhook

curl https://api.inflowpay.com/api/webhook/{webhookId} \
  -H "X-Inflow-Api-Key: inflow_prod_your_key"

Check Webhook Status

See whether a webhook is active or has failures:

curl https://api.inflowpay.com/api/webhook/{webhookId}/status \
  -H "X-Inflow-Api-Key: inflow_prod_your_key"

Response:

{
  "webhookId": "webhook_abc123",
  "webhookUrl": "https://yourserver.com/webhooks/inflow",
  "status": "enabled",
  "failureReason": null
}

Status Values

If your endpoint consistently fails to respond with a 200 status, Inflow may disable it. The failureReason field will explain why.

Enable or Disable a Webhook

# Disable
curl -X PATCH https://api.inflowpay.com/api/webhook/{webhookId} \
  -H "X-Inflow-Api-Key: inflow_prod_your_key" \
  -H "Content-Type: application/json" \
  -d '{ "status": "disabled" }'

# Re-enable
curl -X PATCH https://api.inflowpay.com/api/webhook/{webhookId} \
  -H "X-Inflow-Api-Key: inflow_prod_your_key" \
  -H "Content-Type: application/json" \
  -d '{ "status": "enabled" }'

Get signing secret

Retrieve the Svix signing secret for an endpoint (for signature verification):

curl https://api.inflowpay.com/api/webhook/{webhookId}/secret \
  -H "X-Inflow-Api-Key: inflow_prod_your_key"

{
  "webhookId": "webhook_abc123",
  "secret": "whsec_…"
}

Update subscribed event types

Replace the full list of event types this endpoint receives (see Overview & event types):

curl -X PATCH https://api.inflowpay.com/api/webhook/{webhookId}/event-types \
  -H "X-Inflow-Api-Key: inflow_prod_your_key" \
  -H "Content-Type: application/json" \
  -d '{
    "eventTypes": [
      "connect.payment.authorized",
      "connect.payment.settled"
    ]
  }'

Marketplaces use connect.* names. Direct merchants use unprefixed names (payment.settled, etc.). An empty array subscribes to all events.

Delete a Webhook

curl -X DELETE https://api.inflowpay.com/api/webhook/{webhookId} \
  -H "X-Inflow-Api-Key: inflow_prod_your_key"

Response:

{
  "message": "Webhook deleted successfully"
}

Sent events, replay and delivery attempts

These operations are available via the API only. Inflow keeps every event it sends. Each one has an event id (mwe_…), which you receive in the payload as webhookEventId.

List sent events

curl "https://api.inflowpay.com/api/webhook/events?entityId=pay_xxx" \
  -H "X-Inflow-Api-Key: inflow_prod_your_key"

Optional filters: eventType (e.g. payment.settled), entityId (e.g. pay_xxx), page, limit (max 100). Events are returned newest first:

{
  "data": [
    {
      "id": "mwe_…",
      "eventType": "payment.settled",
      "entityId": "pay_xxx",
      "payload": { "id": "pay_xxx", "…": "…", "webhookEventId": "mwe_…", "occurredAt": "2026-10-02T20:42:07.963Z" },
      "svixMessageId": "msg_…",
      "createdAt": "2026-10-02T20:42:07.963Z"
    }
  ],
  "meta": { "total": 1, "page": 1, "limit": 20, "totalPages": 1 }
}

Replay an event

curl -X POST https://api.inflowpay.com/api/webhook/events/{eventId}/replay \
  -H "X-Inflow-Api-Key: inflow_prod_your_key"

Re-sends the stored payload to your webhooks. {eventId} is either:

• the event id, mwe_… — the webhookEventId of the payload, or id in the list above;
• a message id, msg_… — the one delivered with the event, whether it came from the original send (svixMessageId in the list above) or from a replay.

The replayed payload carries the same webhookEventId and the same occurredAt as the original, so an idempotent handler ignores it if the event was already processed, and a handler that dates events keeps the original time. The replay itself is a new message, with its own msg_….

The message id of a replay can take a few seconds to become usable, and replays made before message ids of replays were supported are not found by their msg_… — use the mwe_… id for those.

{ "success": true, "svixMessageId": "msg_…" }

List delivery attempts

curl https://api.inflowpay.com/api/webhook/events/{eventId}/delivery \
  -H "X-Inflow-Api-Key: inflow_prod_your_key"

{eventId} accepts the same ids as the replay. With an event id (mwe_…) or the original message id, the response covers the original send; with the message id of a replay, it covers that replay. It lists the delivery attempts that carried the message, for each of your webhooks, oldest first:

{
  "eventId": "mwe_…",
  "svixMessageId": "msg_…",
  "attempts": [
    {
      "endpointId": "webhook_…",
      "webhookUrl": "https://yourserver.com/webhooks/inflow",
      "status": "success",
      "batchSize": 3,
      "timestamp": "2026-10-02T20:42:19.000Z"
    }
  ],
  "complete": true
}

A failed attempt followed by a successful one means a retry delivered the event.

complete tells whether the list can be trusted as the full history. It is false when one of your webhooks had more attempts than could be read for that period (very active endpoints, long after the send): attempts may be missing, so an empty list or a failed last attempt is not conclusive; a success in the list is reliable, but some of the failed attempts before it may not be listed. When complete is true, an empty list means no delivery was attempted yet, or no webhook was subscribed to this event type.

Attempts are matched to your webhooks as they are configured today. A webhook deleted since the send no longer appears.

API Summary

All webhook endpoints require the private API key (X-Inflow-Api-Key). Webhook management is also available from the Dashboard under Settings → Developers, except sent events, replay and delivery attempts, which are API-only.

Limits

• Maximum 5 webhooks per account.
• Each webhook URL must be unique within your account.
• URLs must use HTTPS.

Retry & Failure Policy

If your endpoint does not respond with a 2xx within 15 seconds, Inflow retries with exponential backoff — up to 10 attempts spread over several hours to days. If all retries fail, the webhook is automatically disabled.

Check the webhook status endpoint and the failureReason field to diagnose issues, or click Error next to the webhook in the Dashboard. Once fixed, re-enable the webhook via the update status endpoint, or from the Dashboard with the pencil icon.