> ## Documentation Index > Fetch the complete documentation index at: https://docs.venlyfinance.com/llms.txt > Use this file to discover all available pages before exploring further. # Resend a webhook delivery > Replay a failed or discarded delivery with its original payload. **Requires scope:** `manage:webhooks` — see [Required scopes](/getting-started/authentication#required-scopes-finance-api). Re-sends the **original payload** as a further attempt on the same delivery. The `notificationId` is unchanged, so deduplication at your endpoint will not discard it — this is a genuine retry, not a new event. Only a delivery in `FAILURE` or `DISCARDED` can be resent; anything else is `400 delivery-not-resendable`. The response shows the delivery re-queued, normally `SCHEDULED`. ## OpenAPI ````yaml api-reference/Finance-API-Specs.yaml POST /webhooks/{webhookId}/deliveries/{deliveryId}/resend openapi: 3.1.0 info: title: Venly Finance API description: > REST API for the Venly Finance platform: - Party management (Individuals & Organisations) - Identity verification — hosted KYC/KYB links and Sumsub share-token forwarding - Account management with party association - Wallet balances & token allowances on supported chains - Virtual bank accounts for global pay-in (EUR SEPA, USD ACH/WIRE/RTP/SWIFT) - Fiat-to-crypto payment sessions (pay-in) - Bank pay-outs — beneficiary allow-listing, routes, and PULL/PUSH pay-outs - Account-to-account fiat & crypto transfers - EIP-2612 permits and allowances - Webhook registration for asynchronous event delivery ## Authentication All endpoints use OAuth2 client credentials. Obtain a token first, then include it in every request: **Step 1 — Get a token:** ```bash curl -X POST https://login.venly.io/auth/realms/VenlyFinance/protocol/openid-connect/token \ -H "Content-Type: application/x-www-form-urlencoded" \ -d "grant_type=client_credentials&client_id={CLIENT_ID}&client_secret={CLIENT_SECRET}" ``` **Step 2 — Use the token:** ``` Authorization: Bearer {access_token} ``` Tokens expire after **5 minutes**. Implement refresh logic in your client. ## Selecting a tenant A token that grants more than one tenant must say which one each request is for, in the `x-tenant-id` header. With a single-tenant token, omit it. Any value you send must exactly match a tenant the token grants; a missing, malformed or foreign value is answered with a generic `403 forbidden` that reveals nothing about which tenants exist. Send the header at most once. ## Request correlation Every response — including `401` and `403` — carries an `X-Correlation-Id` header identifying the operation in our logs. Quote it in a support request. You may supply your own, as `X-Correlation-Id` or (as a fallback) `X-Request-Id`, matching `^[A-Za-z0-9_.:-]{1,64}$`. A value outside that shape is replaced with a generated one rather than rejected. version: 1.10.0 contact: name: Venly Support email: support@venly.io url: https://docs.venlyfinance.com license: name: Proprietary x-logo: url: https://venlyfinance.com/logo.png x-security-contact: security@venly.io servers: - url: https://api.venlyfinance.com/v1 description: Production - url: https://api-staging.venlyfinance.com/v1 description: Staging security: - OAuth2: [] tags: - name: Parties description: Party management (Individuals & Organisations) - name: Accounts description: Account management, party-role associations - name: Wallets description: Blockchain wallet balances - name: Virtual Bank Accounts description: Virtual bank account payment references for global payments - name: Fiat-to-crypto Payment Sessions description: >- Hosted fiat-to-crypto pay-in sessions. **Coming soon** — not yet enabled; use a virtual bank account to receive fiat today. - name: Payout Bank Accounts description: Allow-listing beneficiary bank accounts as pay-out destinations - name: Payout Routes description: >- Account-scoped routes pairing a beneficiary bank account with a crypto deposit asset - name: Payouts description: Crypto-to-fiat pay-outs over a registered route - name: Transfers description: Fiat and crypto transfer operations between accounts - name: Permits description: EIP-712 permit signature management for token approvals - name: Supported Assets description: >- Discover which chains and assets your tenant can settle in, and whether an account can use them yet. - name: Allowances description: Token allowance management for wallets - name: Webhooks description: Webhook registration, delivery testing and delivery history - name: Pay-Ins description: >- The pay-in ledger — every fiat credit that settled (or failed to settle) into an account wallet - name: Billing description: The invoices Venly has issued to your company - name: API Credentials description: Self-service management of your company's OAuth client credentials - name: Company description: Your own company profile paths: /webhooks/{webhookId}/deliveries/{deliveryId}/resend: parameters: - $ref: '#/components/parameters/TenantId' post: tags: - Webhooks summary: Resend a webhook delivery description: > **Requires scope:** `manage:webhooks` Re-sends a delivery, replaying **the original payload** as a further attempt on the same delivery rather than as a new event. The `notificationId` is unchanged, so deduplication at your endpoint will not discard it — this is a genuine retry of what failed, not a similar-looking new event. Only a delivery in `FAILURE` or `DISCARDED` may be resent; anything else is `400 delivery-not-resendable`. The response reports the delivery in its new state, normally `SCHEDULED`. operationId: resendWebhookDelivery parameters: - $ref: '#/components/parameters/WebhookId' - $ref: '#/components/parameters/DeliveryId' responses: '200': description: The delivery, re-queued content: application/json: schema: $ref: '#/components/schemas/SingleWebhookDeliveryResponse' example: success: true result: id: dlv_01J7Q0Z8R6Y3M2K1N9P8T7V6W5 eventType: PAYOUT_COMPLETED notificationId: ntf_9f2c41ab7d0e4c6b status: SCHEDULED attempts: 5 nextRetryAt: '2026-09-11T09:00:00Z' createdAt: '2026-09-10T14:02:11Z' updatedAt: '2026-09-11T08:59:58Z' '400': description: >- `delivery-not-resendable` — the delivery is not in `FAILURE` or `DISCARDED`. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '401': $ref: '#/components/responses/Unauthorized' '403': description: Forbidden — the token lacks `manage:webhooks`. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '404': description: Webhook or delivery not found, or not owned by your company content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '503': description: The delivery service could not be reached. Retry. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' components: parameters: TenantId: name: x-tenant-id in: header required: false description: > Which tenant the request is scoped to, among those your token grants. Omit it when the token grants exactly one tenant; it is **required** when the token grants more than one. A supplied value must exactly match a tenant the token grants. Absent when required, blank, malformed, or naming a tenant the token does not grant — each gets the same generic `403 forbidden`, which reveals neither whether a tenant exists nor which ones you may use. Send the header once: a repeated header is rejected the same way. schema: type: string format: uuid example: 3fa85f64-5717-4562-b3fc-2c963f66afa6 WebhookId: name: webhookId in: path required: true description: Unique webhook identifier schema: type: string example: wh_8842f19c DeliveryId: name: deliveryId in: path required: true description: Delivery identifier, as returned by the deliveries list schema: type: string example: dlv_01J7Q0Z8R6Y3M2K1N9P8T7V6W5 schemas: SingleWebhookDeliveryResponse: allOf: - $ref: '#/components/schemas/BaseResponse' - type: object properties: result: $ref: '#/components/schemas/WebhookDelivery' ErrorResponse: type: object description: Error response wrapper properties: success: type: boolean description: Always false for error responses example: false errors: type: array description: List of errors that occurred items: $ref: '#/components/schemas/ErrorBody' result: type: object nullable: true description: Null or omitted when success is false BaseResponse: type: object properties: success: type: boolean description: Indicates whether the request was successful WebhookDelivery: type: object description: One delivery of a webhook event, as it appears in a listing. properties: id: type: string description: >- Delivery identifier — the key used to read it in full or to resend it eventType: type: string description: > The event type delivered. A string rather than a fixed enum: history outlives any single release, so a delivery may carry a type introduced after this version. Normally one of the `WebhookEventType` values. notificationId: type: string description: > The stable notification id derived when the event was published — its deduplication key. A resend reuses it, which is what makes the resend a further attempt rather than a new event. status: allOf: - $ref: '#/components/schemas/WebhookDeliveryStatus' description: > Absent if the delivery service reported a status this API does not recognise. The rest of the row is still accurate; treat an absent status as "outcome unknown", not "not delivered". attempts: type: integer description: How many delivery attempts have been made so far nextRetryAt: type: string format: date-time description: >- When the next attempt is due; absent unless the delivery is awaiting a retry createdAt: type: string format: date-time description: When the delivery was first queued updatedAt: type: string format: date-time description: The last state transition deliveredAt: type: string format: date-time description: >- When your endpoint accepted the delivery. Present only when `status` is `SUCCESS`. ErrorBody: type: object description: Individual error details properties: code: type: string description: Machine-readable error code example: invalid-request message: type: string description: Human-readable error message example: The request contains invalid parameters. WebhookDeliveryStatus: type: string description: > Outcome of a delivery. `DISCARDED` and `FAILURE` are different problems: `DISCARDED` means nothing was ever sent — the endpoint was inactive, or the event was filtered — while `FAILURE` means your endpoint was called and did not accept the delivery. Only these two can be resent. - `SCHEDULED` — queued for a first or further attempt - `PROCESSING` — an attempt is in flight - `RETRY` — a failed attempt is awaiting its automatic retry - `SUCCESS` — your endpoint accepted the delivery - `FAILURE` — every attempt failed; resendable - `DISCARDED` — never sent; resendable enum: - SCHEDULED - PROCESSING - RETRY - SUCCESS - FAILURE - DISCARDED responses: Unauthorized: description: Authentication required or failed (401) content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' example: success: false errors: - code: unauthenticated message: Please authenticate to perform this action. securitySchemes: OAuth2: type: oauth2 description: > OAuth2 client credentials flow. Token endpoints: - Staging: https://login-staging.venly.io/auth/realms/VenlyFinance/protocol/openid-connect/token - Production: https://login.venly.io/auth/realms/VenlyFinance/protocol/openid-connect/token flows: clientCredentials: tokenUrl: >- https://login-staging.venly.io/auth/realms/VenlyFinance/protocol/openid-connect/token scopes: {} ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.