> ## Documentation Index > Fetch the complete documentation index at: https://docs.spritz.finance/llms.txt > Use this file to discover all available pages before exploring further. # Get webhook deliveries > Returns recent webhook delivery attempts for the integrator, newest first. Use this to tell **"Spritz never sent it"** apart from **"my endpoint rejected it"** — from the outside both look like silence. Read `error` first — it is what separates the two cases. - `success: true` — your endpoint accepted the delivery, and `responseStatus` is what it returned. - `success: false`, **no** `error`, **with** a `responseStatus` — the request reached your endpoint and it responded with that status. Your handler is being called and is failing. - `success: false` with **neither** `error` nor `responseStatus` — the outcome was not recorded. Only older records look like this; every delivery the current sender writes carries a status. There is nothing to diagnose from them. - `success: false` **with** an `error` — no usable response came back: a timeout, a refused connection, a DNS or certificate problem. `error` carries the underlying reason (for example `getaddrinfo ENOTFOUND ...`). Note that `responseStatus` is still present here — 504 for a timeout, 500 otherwise — but it is our classification of the failure, **not** something your endpoint said. Do not read it as your handler's response. > **An `error` does not prove the event was not processed.** A refused connection means it never arrived, but a timeout or a dropped connection may mean your endpoint received and fully handled the event and we simply never heard the answer. Treat these as *unknown*, not as *not delivered* — re-running non-idempotent work on the strength of an `error` is how you double-process. This is the case idempotent handlers exist for. `payload` is the exact body that was sent, and the body the `Signature` header was computed over, so it can be replayed against your own verification code. Cursor-paginated: pass the previous response's `nextCursor` as `cursor` to walk further back. `nextCursor` is `null` on the last page. Deliveries are recorded for every webhook on the integrator. Scope is your own integrator only. ## OpenAPI ````yaml https://platform.spritz.finance/openapi.json get /v1/integrator/webhooks/deliveries openapi: 3.0.3 info: title: Spritz Finance API version: 1.0.0 description: API for the Spritz Finance platform with RFC 9457 error handling servers: - url: https://platform.spritz.finance description: Production - url: https://sandbox.spritz.finance description: Sandbox security: [] tags: - name: Users description: User management endpoints - name: Bank Accounts description: Manage bank accounts for off-ramp destinations - name: Bills description: Manage bill pay accounts - name: Cards description: Spritz-issued debit cards - name: Auto-Ramp Accounts description: Virtual bank accounts that automatically convert fiat deposits to crypto - name: Spritz App description: >- Endpoints used by the Spritz app and internal SDKs. Excluded from the public partner spec. paths: /v1/integrator/webhooks/deliveries: get: tags: - Integrator summary: Get webhook deliveries description: >- Returns recent webhook delivery attempts for the integrator, newest first. Use this to tell **"Spritz never sent it"** apart from **"my endpoint rejected it"** — from the outside both look like silence. Read `error` first — it is what separates the two cases. - `success: true` — your endpoint accepted the delivery, and `responseStatus` is what it returned. - `success: false`, **no** `error`, **with** a `responseStatus` — the request reached your endpoint and it responded with that status. Your handler is being called and is failing. - `success: false` with **neither** `error` nor `responseStatus` — the outcome was not recorded. Only older records look like this; every delivery the current sender writes carries a status. There is nothing to diagnose from them. - `success: false` **with** an `error` — no usable response came back: a timeout, a refused connection, a DNS or certificate problem. `error` carries the underlying reason (for example `getaddrinfo ENOTFOUND ...`). Note that `responseStatus` is still present here — 504 for a timeout, 500 otherwise — but it is our classification of the failure, **not** something your endpoint said. Do not read it as your handler's response. > **An `error` does not prove the event was not processed.** A refused connection means it never arrived, but a timeout or a dropped connection may mean your endpoint received and fully handled the event and we simply never heard the answer. Treat these as *unknown*, not as *not delivered* — re-running non-idempotent work on the strength of an `error` is how you double-process. This is the case idempotent handlers exist for. `payload` is the exact body that was sent, and the body the `Signature` header was computed over, so it can be replayed against your own verification code. Cursor-paginated: pass the previous response's `nextCursor` as `cursor` to walk further back. `nextCursor` is `null` on the last page. Deliveries are recorded for every webhook on the integrator. Scope is your own integrator only. operationId: getV1IntegratorWebhooksDeliveries parameters: - name: limit in: query required: false schema: description: Maximum number of results to return default: 50 minimum: 1 maximum: 100 type: number - name: cursor in: query required: false schema: pattern: ^[a-fA-F\d]{24}$ description: Opaque cursor from the previous response's `nextCursor` value type: string responses: '200': description: Response for status 200 content: application/json: schema: type: object properties: data: description: Recent webhook delivery attempts, newest first type: array items: type: object properties: event: description: The event that was delivered type: string example: onramp.completed webhookUrl: description: The URL the delivery was attempted against type: string example: https://api.example.com/webhooks payload: description: >- The exact body that was sent, and the body the signature was computed over type: object additionalProperties: {} success: description: >- Whether Spritz received a successful response. `false` alongside an `error` does not mean your endpoint rejected the event — it may have processed it and only the response was lost. `false` with neither `error` nor `responseStatus` means the outcome was never recorded, not that it failed. Read those two fields before concluding anything about delivery. type: boolean example: true responseStatus: description: >- HTTP status your endpoint returned — but only when `error` is absent. When `error` is set no response was received at all, and this is Spritz's classification of the failure (504 for a timeout, 500 otherwise) rather than anything your endpoint said. type: number example: 200 error: description: >- Set when no usable response was received — a timeout, a refused connection, a DNS or certificate problem. This does **not** prove the request never arrived: a refused connection means it did not, but a timeout or a dropped connection may mean your endpoint received and fully processed it and we never heard back. Treat delivery as unknown and rely on idempotent handling. When `error` is absent the request landed and `responseStatus` is your endpoint's own answer. type: string example: getaddrinfo ENOTFOUND webhooks.example.com timestamp: description: >- When the delivery was attempted. Absent on a handful of very early records that predate the field — omitted rather than guessed. format: date-time type: string required: - event - webhookUrl - payload - success hasMore: description: Whether there are more results type: boolean example: true nextCursor: type: string description: >- Pass as `cursor` to fetch the next page. Null on the last page. nullable: true required: - data - hasMore - nextCursor '400': description: Response for status 400 content: application/json: schema: type: object properties: type: default: about:blank description: A URI reference that identifies the problem type type: string example: urn:problem-type:auth:unauthorized title: description: A short, human-readable summary of the problem type type: string example: Unauthorized status: description: The HTTP status code type: number example: 400 detail: description: A human-readable explanation specific to this occurrence type: string instance: description: A URI reference that identifies the specific occurrence type: string example: /errors/1234567890 code: description: >- Machine-readable cause, present when exactly one thing failed. Branch on this, never on `detail`, which is human-facing copy and may change. For deposit limits the vocabulary matches the `reason` values the limits API returns pre-flight. type: string example: transaction_limit field: description: The offending request field, present alongside `code`. type: string example: amountUsd retryable: description: >- Whether retrying the same request later may succeed without changing its inputs. type: boolean example: true required: - title - status additionalProperties: false '401': description: Response for status 401 content: application/json: schema: type: object properties: type: default: about:blank description: A URI reference that identifies the problem type type: string example: urn:problem-type:auth:unauthorized title: description: A short, human-readable summary of the problem type type: string example: Unauthorized status: description: The HTTP status code type: number example: 401 detail: description: A human-readable explanation specific to this occurrence type: string example: Bearer token required instance: description: A URI reference that identifies the specific occurrence type: string realm: description: The authentication realm type: string example: API scope: description: The required scope for this resource type: string example: read:users required: - title - status additionalProperties: false '404': description: Response for status 404 content: application/json: schema: type: object properties: type: default: about:blank description: A URI reference that identifies the problem type type: string title: description: A short, human-readable summary of the problem type type: string status: description: The HTTP status code type: number example: 404 detail: description: A human-readable explanation specific to this occurrence type: string instance: description: A URI reference that identifies the specific occurrence type: string resourceType: description: The type of resource that was not found type: string example: user resourceId: description: The identifier of the resource that was not found type: string required: - title - status - resourceType - resourceId additionalProperties: false '500': description: Response for status 500 content: application/json: schema: type: object properties: type: default: about:blank description: A URI reference that identifies the problem type type: string example: urn:problem-type:auth:unauthorized title: description: A short, human-readable summary of the problem type type: string example: Unauthorized status: description: The HTTP status code type: number example: 400 detail: description: A human-readable explanation specific to this occurrence type: string instance: description: A URI reference that identifies the specific occurrence type: string example: /errors/1234567890 code: description: >- Machine-readable cause, present when exactly one thing failed. Branch on this, never on `detail`, which is human-facing copy and may change. For deposit limits the vocabulary matches the `reason` values the limits API returns pre-flight. type: string example: transaction_limit field: description: The offending request field, present alongside `code`. type: string example: amountUsd retryable: description: >- Whether retrying the same request later may succeed without changing its inputs. type: boolean example: true required: - title - status additionalProperties: false '502': description: Response for status 502 content: application/json: schema: type: object properties: type: default: about:blank description: A URI reference that identifies the problem type type: string example: urn:problem-type:auth:unauthorized title: description: A short, human-readable summary of the problem type type: string example: Unauthorized status: description: The HTTP status code type: number example: 400 detail: description: A human-readable explanation specific to this occurrence type: string instance: description: A URI reference that identifies the specific occurrence type: string example: /errors/1234567890 code: description: >- Machine-readable cause, present when exactly one thing failed. Branch on this, never on `detail`, which is human-facing copy and may change. For deposit limits the vocabulary matches the `reason` values the limits API returns pre-flight. type: string example: transaction_limit field: description: The offending request field, present alongside `code`. type: string example: amountUsd retryable: description: >- Whether retrying the same request later may succeed without changing its inputs. type: boolean example: true required: - title - status additionalProperties: false '503': description: Response for status 503 content: application/json: schema: type: object properties: type: default: about:blank description: A URI reference that identifies the problem type type: string example: urn:problem-type:auth:unauthorized title: description: A short, human-readable summary of the problem type type: string example: Unauthorized status: description: The HTTP status code type: number example: 400 detail: description: A human-readable explanation specific to this occurrence type: string instance: description: A URI reference that identifies the specific occurrence type: string example: /errors/1234567890 code: description: >- Machine-readable cause, present when exactly one thing failed. Branch on this, never on `detail`, which is human-facing copy and may change. For deposit limits the vocabulary matches the `reason` values the limits API returns pre-flight. type: string example: transaction_limit field: description: The offending request field, present alongside `code`. type: string example: amountUsd retryable: description: >- Whether retrying the same request later may succeed without changing its inputs. type: boolean example: true required: - title - status additionalProperties: false '504': description: Response for status 504 content: application/json: schema: type: object properties: type: default: about:blank description: A URI reference that identifies the problem type type: string example: urn:problem-type:auth:unauthorized title: description: A short, human-readable summary of the problem type type: string example: Unauthorized status: description: The HTTP status code type: number example: 400 detail: description: A human-readable explanation specific to this occurrence type: string instance: description: A URI reference that identifies the specific occurrence type: string example: /errors/1234567890 code: description: >- Machine-readable cause, present when exactly one thing failed. Branch on this, never on `detail`, which is human-facing copy and may change. For deposit limits the vocabulary matches the `reason` values the limits API returns pre-flight. type: string example: transaction_limit field: description: The offending request field, present alongside `code`. type: string example: amountUsd retryable: description: >- Whether retrying the same request later may succeed without changing its inputs. type: boolean example: true required: - title - status additionalProperties: false security: - hmacAuth: [] integratorKey: [] timestamp: [] components: securitySchemes: hmacAuth: type: apiKey in: header name: X-Signature description: >- HMAC signature authentication for backend integrators. **Required Headers:** - X-Integrator-Key: Integrator API key (format: int_...) - X-Signature: HMAC signature (format: sha256={hex}) - X-Timestamp: Unix timestamp in milliseconds - Authorization: Bearer {user-api-key} **Signature Algorithm:** HMAC-SHA256 **Signature Format:** {timestamp}.{METHOD}.{path}.{bodyHash} - timestamp: Unix timestamp in milliseconds - METHOD: HTTP method in UPPERCASE (GET, POST, etc.) - path: Request path (e.g., /v1/transactions) - bodyHash: SHA256 hex digest of request body (empty string if no body) **Timestamp Tolerance:** ±5 minutes (300 seconds) **Example:** For POST /v1/transactions with body {"amount":100} and timestamp 1234567890000: Payload: 1234567890000.POST./v1/transactions.{sha256(body)} Signature: sha256=abc123... integratorKey: type: apiKey in: header name: X-Integrator-Key description: 'Integrator API key (format: int_...) used with HMAC authentication' timestamp: type: apiKey in: header name: X-Timestamp description: >- Unix timestamp in milliseconds for replay attack prevention. Must be within 5 minutes of server time. ````