Triggered when a wallet statement is ready

Understand the wallet_statement_ready webhook, know when a requested statement has finished generating, and handle the event safely in reporting and reconciliation workflows.

Use this webhook reference to understand the event sent when a requested wallet statement has finished generating and is ready for retrieval or downstream processing.

When this webhook is useful

Use this event when your integration needs to:

  • detect that a wallet statement request has completed
  • start the next step in a statement download or processing workflow
  • notify internal users or customers that a statement is ready
  • reconcile statement-generation jobs with the wallet and time range originally requested

Before you rely on this event

Complete these steps first:

  1. Request a wallet statement using Request Wallet Statement.
  2. Configure a public webhook endpoint that can receive and acknowledge Verto events.
  3. Decide how your application will match this event back to the originating wallet and reporting period.
  4. Make sure your webhook handler can process duplicate deliveries safely.

What this event means

When this webhook is sent, Verto has completed the statement-generation workflow for the relevant wallet statement request.

Typical implications include:

Event meaningWhy it matters
Statement generation completedYour application can move from waiting state into retrieval or download logic.
Asynchronous job resolvedFinance or operations workflows no longer need to poll blindly for readiness.
Wallet-linked reporting availableThe generated statement can now be matched to the original wallet and requested timeframe.

How to handle this webhook safely

  • Acknowledge the webhook quickly with a successful response before starting long-running internal work.
  • Deduplicate deliveries using your event ID or internal correlation logic.
  • Match the event to the correct wallet and statement request before notifying users or updating internal systems.
  • Treat the event as the trigger for retrieval or processing, not as the statement file itself unless the payload explicitly includes it.

Common implementation notes

  • Keep the wallet ID, statement request metadata, and your own reporting job reference linked in your system.
  • Use this event in finance, reconciliation, and support tooling where teams need a reliable signal that historical data is ready.
  • If the statement does not appear where expected after the event, compare the event payload with the original request parameters and downstream retrieval logic.

Related workflow

This event is typically part of the following sequence:

  1. Request a wallet statement.
  2. Wait for the statement-generation job to complete.
  3. Receive the wallet_statement_ready event.
  4. Retrieve, download, or process the statement through the appropriate downstream workflow.

Next steps

  • Continue to Request Wallet Statement to review how statement generation is initiated.
  • Continue to Webhooks for the broader webhook delivery and deduplication model.
  • Continue to Wallets for the broader wallet lifecycle and reporting context.
Payload
string
required

Unique identifier for this specific event

string
enum
required

Type of webhook event

Allowed:
date-time
required

Timestamp when the webhook event was triggered (ISO 8601 format).

event
object
required

Event Object

Response
200

Wallet statement webhook received

LoadingLoading…