A WireMock simulation of Chase JPMorgan's REST API — covering current and end-of-day balance reporting for blockchain deposit accounts.
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
GET Retrieve all account balances - 200 OK
curl -s -X GET 'https://6gm7j.wiremockapi.cloud/accounts/balances'POST Inquire account balances - 200 OK
curl -s -X POST 'https://6gm7j.wiremockapi.cloud/accounts/balances/inquiry' \
-H 'Content-Type: application/json' \
-d '{}'Spec catalog — Blockchain Deposit Account Balances API (2.0.7) · 2 endpoints
| Method | Path | Summary |
|---|---|---|
| GET | /accounts/balances | Retrieve Balances of All Eligible Accounts |
| POST | /accounts/balances/inquiry | Inquire Balances |
Unauthenticated WireMock Cloud demo sandbox for Chase JPMorgan — not an official Chase JPMorgan sandbox, and it returns simulated example data only.
Blockchain deposit accounts are J.P. Morgan's ledger-on-chain cash accounts, and this small surface is their treasury window: two routes, one account, version 2.0.7 of the spec. The GET answers the intraday question — account 1234567890, a USD BDA addressed through the CHASUS33MCY BIC, holding matched INTERIM_AVAILABLE and INTERIM_BOOKED balances of 5,000.00 on its book date — while the inquiry POST answers the reconciliation question, returning CLOSING_AVAILABLE and CLOSING_BOOKED pairs for two consecutive book dates on the same account. The type vocabulary is ISO 20022's (the same INTERIM/CLOSING families camt.052 and camt.053 use), so balance-classification code built for bank reporting parses these without translation. Each response closes with cursor metadata — first and this pointing at the same page token, plus a goodUntil freshness stamp that differs between the two routes, one day apart.
Time horizon. The GET reports the interim view — the balances as they stand mid-day, available and booked in agreement at 5,000.00 — where the inquiry POST reports closing figures for two book dates, the shape a nightly reconciliation job consumes. The account is the same on both, so a client that calls the pair can be tested for exactly the join it performs in production: matching today's interim position against yesterday's close. The filters an inquiry body can carry are accepted but don't change the result; both responses are fixed.
Deliberately little — that's the product's point. The account type BDA marks it, but the balances read like any bank reporting API: typed amounts, book dates, a BIC-addressed institution. Client code doesn't touch a chain; it consumes conventional treasury data that happens to settle on one. What the mock lets you verify is that your integration treats BDAs as ordinary accounts in aggregation logic — no special casing, same parsers, same balance-type handling.
As a staleness contract to honor, not a value to assert. Each route carries its own fixed goodUntil (the inquiry's sits one day earlier than the GET's), representing how long the cursor remains valid for follow-up pages. Production consumers should re-query rather than page past it; the fixed dates here make an aged cursor easy to simulate, since both stamps are already in the past. The first and this tokens being identical also encodes the single-page case — pagination code must terminate on it rather than loop.
The Corporate Account Information template is the fuller treasury-reporting surface in the library — multi-account summaries, transaction detail, and statement retrieval down to a raw PDF body. This one is intentionally narrower: a focused fixture pair for teams adding blockchain-settled accounts to an existing cash-visibility integration, where the work is confirming the new account type flows through balance aggregation untouched.
Vendor names identify APIs represented by WireMock template sources. This page does not imply vendor endorsement, certification, partnership, or official integration status.