Skip to content

Suggested

Dashboard
POST /v1/notifications/{id}/replay

Re-sends the payload of an earlier delivery to the webhook URL you have configured today. Use it to recover events your endpoint missed during an outage.

What is re-sent: The stored payload, byte for byte — same eventType, same timestamp, same transaction snapshot as the original. Conomy does not rebuild it from current state, so a replayed event describes the transaction as it was when the event fired, not as it is now. Read the transaction if you need its current state.

Where it is sent: To your CURRENT webhookUrl, signed with your CURRENT secretKey — not the ones in force when the original was sent. The intent is to reach where you are listening today. The X-Webhook-Signature header is recomputed over the replayed body, so verify it exactly as you verify a first delivery.

How to recognise a replay: The request carries the X-Webhook-Replay-Of header holding the ID of the original delivery. Because the body is byte-identical to the one already sent, that header and the payload itself are the two handles you have for deduplication — the payload contains no separate event ID.

Your receiver MUST be idempotent: A replay can deliver an event your endpoint already processed, because the original may have reached you and failed only on the way back. Key your processing on transaction.id together with eventType and make reprocessing a no-op. A replayed event must never credit an account, release goods or notify a user twice.

Replayable states: failed and skipped deliveries can be replayed freely. A delivered delivery already reached your endpoint, so replaying it is the case that can duplicate work on your side: it requires force: true in the body, and without it the call returns 409 Conflict with the current status in the error details.

The original is never modified: A replay inserts a NEW delivery row with isReplay: true and replayOf set to the original ID, and returns that new row. The original keeps its own outcome forever, so the log stays a truthful history of every attempt.

Audit trail: Each replay is its own row — createdAt records when it was requested, replayOf which delivery it repeats, and requestedBy who asked for it.

Rate limit: Approximately 6 replays per minute per merchant, with short bursts of up to 10. Exceeding it returns 429 Too Many Requests with a Retry-After header; wait that many seconds instead of retrying immediately.

Not enforced yet: force, requestedBy and the 409 Conflict response are the agreed contract but are not live — today a replay is accepted whatever the original's status, and no actor is recorded. Until they ship, prevent replays of delivered deliveries in your own tooling and do not rely on requestedBy being present on a row.

POST/v1/notifications/{id}/replay
Replay a notification delivery

Bearer access token returned by the authentication endpoint.

API version selector for Conomy endpoints. Use 24-04-2025 for the current version.

The ID of the delivery to replay.

Optional. Omitting the body is equivalent to force: false.

Required to replay a delivery whose status is already delivered. Setting it acknowledges that your endpoint will receive an event it has already accepted.

Defaultfalse

Identifier of the operator or system requesting the replay, recorded on the new delivery row for audit.

idstringrequired

Unique ID of this delivery. Pass it to the get and replay operations.

Example68a1b2c3d4e5f6a7b8c9d0e1
createdAtstringdate-timerequired

When this attempt was made.

Example2026-08-01T12:00:05.412Z
identityIdstring

The identity the notified transaction belongs to.

Example67a02f34ad9aa801a60144ea
transactionIdstring

The transaction the event is about.

Example67a0307eaddea901a60144ec
eventTypestring

The event name that was sent. Same values as the eventType field of the webhook-transaction-event payload.

Examplepayment.received
reasonstring

Raw discriminator that produced the eventType, for example settled or refundCreated.

Examplereceived
statusstringrequired
deliveredfailedskipped
httpStatusintegerrequired

HTTP status your endpoint returned, or 0 when the request never completed — a timeout, DNS or TLS failure.

Example502
attemptsintegerrequired

How many HTTP requests this single delivery row represents.

Example1
targetHoststring

Host the request was sent to. Only the host is recorded, never the full URL, path or query string.

Examplehooks.merchant.com
testModebooleanrequired

Whether this delivery originated in the sandbox environment.

Examplefalse
isReplaybooleanrequired

True when this row was produced by the replay operation.

Examplefalse
replayOfstring

ID of the delivery this row repeats. Present only when isReplay is true. The same value is sent to your endpoint as the X-Webhook-Replay-Of header, which is how you deduplicate a replay.

Example68a1b2c3d4e5f6a7b8c9d0e1
requestedBystring

Who requested the replay. Not populated yet — the audit row currently records when (createdAt) and which (replayOf) but no actor. Treat it as absent until that ships.

Exampleops:felipe@conomyhq.com
payloadobject

Webhook payload sent by Conomy to the client URL.

responseBodyExcerptstring

First 500 characters of your endpoint's response body, kept for diagnosis. Truncated, never the full body.

Example{"ok":true}
errorMessagestring

Transport-level error when the request never reached your endpoint. Absent when the request completed.

ExamplePost "https://hooks.merchant.com/conomy"…
Request
POST /sandbox/v1/notifications/{id}/replay HTTP/1.1
Host: api.conomyhq.com
Authorization: Bearer {ACCESS_TOKEN}
conomyhq-api-version: 24-04-2025
Content-Type: application/json

{
  "force": false,
  "requestedBy": "ops:felipe@conomyhq.com"
}
Response
{
  "id": "68a1b2c3d4e5f6a7b8c9d0e1",
  "createdAt": "2026-08-01T12:00:05.412Z",
  "identityId": "67a02f34ad9aa801a60144ea",
  "transactionId": "67a0307eaddea901a60144ec",
  "eventType": "payment.received",
  "reason": "received",
  "status": "delivered",
  "httpStatus": 502,
  "attempts": 1,
  "targetHost": "hooks.merchant.com"
}