API template library

Plaid Statements mock API and live sandbox

A WireMock simulation of Plaid's REST API — covering bank statement inventories, statement downloads, and refresh.

Vendor
Plaid
Functionality
Bank statement retrieval
Spec version
2020-09-14_1.688.6
Endpoints
3
Stubs
3
Protocol
REST
Validation
AI-validated Before publication, an AI agent exercised these endpoints against the real Plaid API through WireMock's recording proxy, and the recorded traffic was used to verify each stub's request and response shapes.

Live sandbox · no signup, no API key

Plaid Statements

A running WireMock Cloud instance of this template, callable right now from a terminal, a script, or an AI agent.

Base URL
https://w2lz1.wiremockapi.cloud

POST List Statements

curl -s -X POST 'https://w2lz1.wiremockapi.cloud/statements/list' \
  -H 'Content-Type: application/json' \
  -d '{}'

POST Download Statement

curl -s -X POST 'https://w2lz1.wiremockapi.cloud/statements/download' \
  -H 'Content-Type: application/json' \
  -d '{}'

POST Refresh Statements

curl -s -X POST 'https://w2lz1.wiremockapi.cloud/statements/refresh' \
  -H 'Content-Type: application/json' \
  -d '{}'
Method Path Summary
POST /statements/download Retrieve a single statement.
POST /statements/list Retrieve a list of all statements associated with an item.
POST /statements/refresh Refresh statements data.

Unauthenticated WireMock Cloud demo sandbox for Plaid — not an official Plaid sandbox, and it returns simulated example data only.

What's inside the Statements template

The product is three routes — an inventory, a download, a refresh — and the inventory carries the detail: the Plaid Checking account with a two-entry statement history, January 2024 and December 2023, each entry holding month, year, and posting date inside the institution envelope. The statement ids read like documentation (stmt_january_2024), which keeps test assertions legible in a way production's opaque identifiers never are, and the download route serves a stand-in document body for any id you name.

  • Statement inventory — the per-account listing with months, years, and posted dates
  • Download — a base64 body standing in for the statement document itself
  • Refresh — the acknowledgement that requests a fresh statement pull

Frequently asked questions

A JSON-quoted base64 string that decodes to a one-line PDF stand-in. Production serves raw binary with a Plaid-Content-Hash header, so a client built here needs one adjustment for the real thing — decode the string here, stream bytes there. Everything around the fetch carries over unchanged: statement selection, storage, retry.

The download route matches on path alone — no statement_id is validated, so asking for a month the inventory never mentions succeeds and returns the same body. A history that actually spans accounts and years, with per-id documents, is stub editing in a WireMock Cloud copy rather than anything this instance distinguishes.

You don't, here — the route acknowledges with a request_id and the sandbox's role ends there, since completion signals travel by webhook in production. Drive the post-refresh branch of your code directly in tests and treat the ack as the contract being checked.

Nothing on this instance checks credentials — every route answers without a token. The Item bookkeeping that governs statements access in production is modeled by the Items & Webhooks template; pair the two when a test needs consent state on one side and statement retrieval on the other.

Vendor names identify APIs represented by WireMock template sources. This page does not imply vendor endorsement, certification, partnership, or official integration status.