Account

Retry an account webhook delivery

Re-arm a failed delivery: the SAME delivery returns to pending and is sent again with the current signing secret.

  • Only failed and failed_permanently can be retried; others return 422 subcode account_webhook_retry_not_allowed.
  • Returns 202; requires a live key and an Idempotency-Key; 404 webhook_delivery_not_found.
post/accounts/{account}/webhooks/{webhook}/deliveries/{delivery}/retry

Request

  • Base URL: https://api.factuarea.com/v1
  • URL: https://api.factuarea.com/v1/accounts/{account}/webhooks/{webhook}/deliveries/{delivery}/retry
  • Auth: one of:
    • HTTP bearer
    • API key in header X-API-Key

Path parameters

accountstring uuid required

Public identifier (UUID v7) of your account. Get it from GET /v1/me (data.account.id).

webhookstring uuid required

Public identifier (UUID v7) of the webhook endpoint.

deliverystring uuid required

Public identifier (UUID v7) of the webhook delivery.

Headers

Idempotency-Keystring required
Example:01928f10-7c0e-7c4a-9b7d-2f8a6e3c1d4b

Client-generated opaque key (up to 255 characters; UUID v7 recommended) that makes retries safe: the first response is cached and replayed for repeats without re-executing the mutation. Reusing a key with a different body returns 422 idempotency_key_reused; the values of secret fields (password, secret…) count as part of the body, so retrying with a corrected secret under the same key is a different request, never the replay of the earlier answer. See the Idempotency guide. Required on this operation: repeating it delivers an effect that cannot be taken back (an email sent, a file generated, a third-party call, a charge), so a request without this header is rejected with 422 idempotency_key_required before any business logic runs.

Factuarea-Versionstring date
Example:2026-06-01

Pin the API version (YYYY-MM-DD, Stripe-style date versioning) for this request; omit to use the key's pinned version, or the latest if none. Unsupported version → 400 unsupported_api_version; malformed → 400 parameter_invalid_format. The effective version is echoed in the Factuarea-Version response header. See the Versioning guide.

Response

The delivery was re-armed and queued: the SAME delivery goes back to pending and is sent again with the current signing secret. data.id is that delivery; read its outcome with the delivery detail.

Example response

{
  "data": {
    "id": "01933b71-9c2d-7e5f-a674-6d8f0b3c4e06"
  }
}

Changes

No recorded changes to this operation across all 1 revision of this API.