A WireMock simulation of Plaid's REST API — covering e-wallet creation, wallet account numbers, and payout execution and lookup.
A shared instance of this template runs on a public endpoint — call it right now from curl, an SDK, or an AI agent. Responses are fixed examples and behavior can't be changed; rate limits apply.
Jump to the endpoints ↓Run this template as a mock API in WireMock Cloud for a private instance you control — edit stubs, add stateful scenarios, use dynamic response templating, and inspect requests in the log.
Open in WireMock Cloud (free) →Live sandbox · no signup, no API key
A running WireMock Cloud instance of this template, callable right now from a terminal, a script, or an AI agent.
Endpoints
POST Create - /wallet/create
curl -s -X POST 'https://5e74z.wiremockapi.cloud/wallet/create' \
-H 'Content-Type: application/json' \
-d '{}'POST List - /wallet/list
curl -s -X POST 'https://5e74z.wiremockapi.cloud/wallet/list' \
-H 'Content-Type: application/json' \
-d '{}'POST Create - /wallet/transaction/execute
curl -s -X POST 'https://5e74z.wiremockapi.cloud/wallet/transaction/execute' \
-H 'Content-Type: application/json' \
-d '{}'Spec catalog — The Plaid API (2020-09-14_1.688.6) · 6 endpoints
| Method | Path | Summary |
|---|---|---|
| POST | /wallet/create | Create an e-wallet |
| POST | /wallet/get | Fetch an e-wallet |
| POST | /wallet/list | Fetch a list of e-wallets |
| POST | /wallet/transaction/execute | Execute a transaction using an e-wallet |
| POST | /wallet/transaction/get | Fetch an e-wallet transaction |
| POST | /wallet/transaction/list | List e-wallet transactions |
Unauthenticated WireMock Cloud demo sandbox for Plaid — not an official Plaid sandbox, and it returns simulated example data only.
The e-wallet product in six endpoints, backed by a wallet store with precise edges. Created wallets are registered — their ids satisfy /wallet/get afterwards, and unknown ids draw WALLET_NOT_FOUND — while every registered wallet reads back as the same sterling fixture: a balance of 123.12 current against 100.96 available, a BACS sort-code pair, an IBAN and BIC for cross-border rails, status ACTIVE. Executed transactions are registered too, with one detail reconciliation code will appreciate: the stored record keeps the wallet_id your execute request named, so the wallet-to-payout linkage is real. The payout body itself carries a counterparty and a related RETURN reference.
The listing is a static empty page; the get route is the one wired to the transaction registry. Poll by transaction id rather than scanning the list on this instance, and treat list-driven reconciliation as something to exercise in a WireMock Cloud copy where the listing can be stubbed to match.
No — execution registers a transaction record, but every wallet read reports the fixture balance, so the shared instance's wallets stay solvent forever. Balance-decrement behavior is response templating in a private copy, layered onto the balance object this fixture already shapes.
A reference to the failure case: payouts can come back, and the related_transactions array shows how a return points at its original. Code that stitches return events to source payouts gets the linkage shape without waiting for a real return to occur.
Money leaving a customer's own bank account under their authorization is the Payment Initiation template — consents, bank redirects, BACS payments. Virtual Accounts is the held-balance side: funds already in your wallet estate moving out.
Vendor names identify APIs represented by WireMock template sources. This page does not imply vendor endorsement, certification, partnership, or official integration status.