Webhook endpoints
List webhook endpoints
Lists the webhook endpoints registered for your organization.
Path parameters
organizationIdstringRequiredYour organization id.
Behavior
Read-only. Registering, pausing, deleting, rotating the secret of or
replaying an endpoint is a dashboard action and cannot be done with an
API key, because a credential that could repoint its own webhook URL could
quietly redirect every payout notification you receive. The dashboard
routes, for completeness: POST .../webhook-endpoints/{endpointId}/rotate-secret
(the old secret keeps signing beside the new one for 24 hours, so
nothing in flight drops) and POST .../webhook-endpoints/{endpointId}/deliveries/replay
(re-fires up to 1,000 dead deliveries in a from/to window under
their original event ids, so your dedupe still holds).
The health fields are how you see an endpoint dying without asking us:
consecutiveFailures counts exhausted retry ladders since the last
success, and after three of them with no success for five days we
disable the endpoint (disabledReason: auto_disabled_after_failures),
email your organization's owners, and deliver
webhook_endpoint.disabled to your other endpoints whose events list
is empty. It cannot be named in events, so an endpoint with an
explicit list never receives it.
The signing secret is never returned here. You are shown it once, when the endpoint is created or rotated.
Responses
200Registered endpoints
Body
idstringRequiredurlstring<uri>Requiredeventsarray of stringRequiredEmpty means every payout-side type (payout, approval, batch and endpoint lifecycle), but not
checkout_payment.*, which is delivered only when named here.disabledAtstring<date-time> | nullRequiredNon-null while the endpoint is paused or auto-disabled.
disabledReasonstring | nullRequiredAllowed values:paused_by_ownerauto_disabled_after_failuresnullconsecutiveFailuresintegerRequiredRetry ladders exhausted since the last accepted delivery. Reset to 0 on success and on re-enable.
lastSuccessAtstring<date-time> | nullRequiredlastFailureAtstring<date-time> | nullRequiredcreatedAtstring<date-time>Required
Errors
401The key was refused. Nothing ran.
UNAUTHORIZED: missing, invalid or revoked, or a key on a route that does not accept one.KEY_EXPIRED: the key passed the expiry it was issued with. Issue a new one; an expired key cannot be rotated.KEY_IP_NOT_ALLOWED: the key is pinned to source addresses and this request came from another.
403A valid key that may not make this call. Nothing ran.
FORBIDDEN: the key belongs to a different organization.ACCOUNT_BLOCKED: API access for your organization is suspended.DEVELOPER_FEATURE_DISABLED: developer tools (webhook endpoints) are off for your organization.GET /policylistsdeveloperinfeatureswhen they are on.
429Too many requests. The default ceiling is 100 requests per minute per API credential on a 60-second window. High-volume payout and reconciliation routes declare a 600/minute override, and batch submission a 30/minute ceiling. A separate 2,000/minute per-source-IP abuse ceiling always applies.
Obey
Retry-After; it is in seconds and is authoritative. A 429 means the request was refused before the handler ran. Retry reads normally; retry an idempotent mutation with its sameIdempotency-Key.
Error body · Error
typestringRequiredStable machine-readable code.
detailstringRequiredWhat went wrong, in a sentence. Always a string, so
detail.toLowerCase()is safe.More
This is the field to read on
BAD_REQUESTandPROVIDER_REJECTED, where the type alone does not name the condition.messagestringRequiredThe same text as
detail, kept for integrations written beforedetailexisted. Readdetail.resolutionstringOptionalWhat to do about it, when there is a specific answer. It is not on every error (it is absent on
BAD_REQUEST,NOT_FOUND,PAYOUT_NOT_CANCELABLEandDESTINATION_ACCOUNT_NOT_FOUND), so treat it as optional and fall back todetail.statusintegerRequiredHTTP status, repeated in the body.
statusCodeintegerRequiredThe same value as
status, kept for integrations written beforestatusexisted. Readstatus.requestIdstringRequiredQuote this to support and we can find the exact request. Also sent as the
x-request-idresponse header, which is the only place it appears on a successful response. Success bodies do not carry it. Send your ownx-request-idon the request and we use it, so your trace and ours share one identifier; otherwise we mint one.errorsarray of stringOptionalPresent on VALIDATION_ERROR; names each field that failed.
originalIdempotencyKeystringOptionalOn
DUPLICATE_REQUEST_DETECTEDonly. Send the request again with this to receive the original payout instead of making a second one. Without it there is no way to recover except by risking a double payment.originalPayoutIdstringOptionalOn
DUPLICATE_REQUEST_DETECTEDonly. The payout the first request created.originalBatchIdstringOptionalOn a batch
DUPLICATE_REQUEST_DETECTED. The run the first request created.originalRequestIdstringOptionalOn a
409 PAYOUT_OUTCOME_UNKNOWNreplay. TherequestIdof the call whose outcome is unknown; quote it to support.existingRecipientIdstringOptionalOn
BANK_ACCOUNT_ALREADY_LINKED. The recipient in your organization that already holds this account.existingMethodIdstringOptionalOn
BANK_ACCOUNT_ALREADY_LINKED. The payment method on that recipient.
Branch on type, never on the status or the message. Every error type is listed with what to do about it.
Was this page helpful?