A WireMock simulation of Chase JPMorgan's REST API — covering counterparty onboarding, external account linking, invoices and payables, and pay-in/pay-out transactions with cancel and refund.
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 counterparty entity - POST /counterparty-entities
curl -s -X POST 'https://dge4v.wiremockapi.cloud/counterparty-entities' \
-H 'Content-Type: application/json' \
-d '{}'POST Update counterparty entity - POST /counterparty-entities/update
curl -s -X POST 'https://dge4v.wiremockapi.cloud/counterparty-entities/update' \
-H 'Content-Type: application/json' \
-d '{}'POST Create counterparty user - POST /counterparty-users
curl -s -X POST 'https://dge4v.wiremockapi.cloud/counterparty-users' \
-H 'Content-Type: application/json' \
-d '{}'Spec catalog — J.P. Morgan Concourse (1.1.8) · 25 endpoints
| Method | Path | Summary |
|---|---|---|
| POST | /card-account-authorizations | Authorize a Card |
| POST | /counterparty-entities | Create a Counterparty Entity |
| POST | /counterparty-entities/update | Update a Counterparty Entity |
| POST | /counterparty-users | Create a Counterparty User |
| POST | /counterparty-users/update | Update a Counterparty User |
| POST | /external-accounts | Create an External Account |
| POST | /external-accounts/{externalAccountAliasId}/authorizations | Authorize an External Account |
| POST | /external-accounts/update | Update an External Account |
| POST | /invoices | Create an Invoice |
| POST | /invoices/{invoiceNumber} | Update an Invoice |
| POST | /invoices/search | Search for Invoices |
| POST | /payables | Create a Payable |
| POST | /payables/{payableNumber} | Update a Payable |
| POST | /payables/search | Search for Payables |
| POST | /payins-payouts | Create a Financial Transaction |
| POST | /payins-payouts/{confirmationNumber}/cancel | Cancel a Payin Financial Transaction |
| POST | /payins-payouts/{confirmationNumber}/refund | Refund a Payin Financial Transaction |
| POST | /payments/search | Search for Pay-In Payments |
| GET | /programs/{programId}/counterparty-entities/{counterpartyEntityAliasId}/ | Get a Counterparty Entity |
| GET | /programs/{programId}/counterparty-entities/{counterpartyEntityAliasId}/counterparty-users/{counterpartyUserAliasId}/ | Get a Counterparty User |
| GET | /programs/{programId}/payins-payouts/{confirmationNumber} | Retrieve the Details of a Pay Out Transaction |
| GET | /programs/{programId}/payments/{confirmationNumber} | Get a Pay-In Payment |
| POST | /session-transfer | Create a Session Transfer |
| POST | /webhook | transactionStatus |
| POST | /zelle-inquiry | getZelleToken |
Unauthenticated WireMock Cloud demo sandbox for Chase JPMorgan — not an official Chase JPMorgan sandbox, and it returns simulated example data only.
Concourse is J.P. Morgan's embedded-payments back office, and the sandbox runs its two central ledgers as working stores. Submitting a pay-in or pay-out mints a twelve-character confirmation number, and reading it back returns the body you submitted wrapped in the server's contribution — status Scheduled, a createDateTime stamped at the moment of the request, and a valueDate set to the next calendar day, so settlement-date logic always sees a live tomorrow. Counterparty entities go further: created records read back with an ACTIVE status attached, the update route rewrites named fields while leaving the rest in place, and unknown aliases on both stores draw a dedicated not-found stub answering an empty errors array. Around those cores sit the onboarding fixtures — a Mary Smith counterparty user, a Deposited ACH payment for a negative five thousand dollars, and the AR/AP documents INV000123 and AP000123.
Two stores are real. Pay-ins and pay-outs persist under their minted confirmation numbers, and counterparty entities persist under the alias id you choose — including edits, since the update route folds new values into the stored record (the GET path's program id, notably, is decoration; the alias alone is the key). Everything else is fixed: created counterparty users never resolve — reads always answer Mary Smith — invoice and payable searches return their single canonical documents whatever the criteria, and the payments routes serve one Deposited ACH debit regardless of path id.
Cancel and refund are acknowledgment-only verbs. Cancel accepts any confirmation number — registered or invented — and answers with a body that is just an X-Request-Id field holding the sandbox's fixed UUID; refund always returns the REF-001-REFUND confirmation. Neither touches the stored record, which stays Scheduled on every later read. Treat them as contract checks that your client addresses the right route at the right moment, and build genuine Scheduled-to-Cancelled transitions as scenario stubs in a private WireMock Cloud copy.
Creating a payable returns payableAmount as the string "100.00"; searching returns the same document with the amount as the JSON number 100.0. Real multi-team APIs ship exactly this kind of drift between endpoints, and a deserializer pinned to one numeric representation breaks on the other — cheaper discovered here than in reconciliation. The same lesson hides in the payment fixture, whose amount is the string "-5000", and in the user record's all-lowercase registrationstatus field.
Half of it. POST /webhook is an inbound receiver that answers 200, so the outbound leg of your integration — signing, posting, retry-on-non-200 — has a target to fire at. The sandbox never emits events of its own, though; to feed your consumer real payloads, replay Concourse event bodies at it from your test harness. When the payment happening at a checkout is the thing under test rather than the back office behind it, the Online Payments template is the Chase surface built for that.
Vendor names identify APIs represented by WireMock template sources. This page does not imply vendor endorsement, certification, partnership, or official integration status.