A WireMock simulation of Chase JPMorgan's REST API — covering card-on-file update queries that surface replacement account numbers, with a status read and service health.
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 Health check - 200 OK
curl -s -X GET 'https://8134y.wiremockapi.cloud/healthcheck'POST Submit account update - 201 Created
curl -s -X POST 'https://8134y.wiremockapi.cloud/account-updates' \
-H 'Content-Type: application/json' \
-d '{}'Spec catalog — Account Updater API (1.3.4) · 3 endpoints
| Method | Path | Summary |
|---|---|---|
| POST | /account-updates | Query Account Updater service. |
| GET | /account-updates/{account-identifier} | Get information about an account update. |
| GET | /healthcheck | Health check for the Account Updater service. |
Unauthenticated WireMock Cloud demo sandbox for Chase JPMorgan — not an official Chase JPMorgan sandbox, and it returns simulated example data only.
Account Updater is the service that keeps a merchant's stored cards current when issuers reissue them, and the sandbox models its query as a same-call resolution: submit a card and the 201 answers with the updated credential inline. The response splits into the two halves an updater client has to reconcile — an oldAccountInformation block that reads the card number straight out of your request's accountInformation, and a newAccountInformation block carrying the replacement the network reported: a VISA ending 1234, paymentMethodChanged false, PAN as the account-number type. Around the swap sit the audit fields: reasonMessage NEW_ACCOUNT_AND_EXPIRY explaining what changed, a requestStatus of REGISTERED beside an overall SUCCESS, a responseId minted per call, a creation timestamp stamped at the moment of the request — and a requestId sourced from the request-id header, so correlation-id plumbing gets checked end to end. A healthcheck reporting UP completes the surface.
Because it comes from a header, not the body. The stub reads the request-id header and templates it into the response's requestId field — send the header and your value round-trips, omit it and the field renders as an empty string. That makes the route a quiet audit of your client's correlation discipline: if your integration stamps every outbound call with a request id, the response proves it arrived.
One: a successful account-and-expiry replacement. Every submission resolves to the same VISA ending 1234 with reasonMessage NEW_ACCOUNT_AND_EXPIRY, whatever card you send. The other outcomes an updater integration must handle — closed accounts, contact-cardholder responses, no-match, brand conversions — are one-stub-each additions in a private WireMock Cloud copy, where a request matcher on the submitted PAN can map specific test cards to specific outcomes, the way issuer test decks conventionally do.
No — the by-identifier read has a single stub, and it answers the ERROR / NOT_FOUND envelope for every id, including the responseId the intake just minted. It exists to exercise the miss path deliberately: your poller's handling of an update that has aged out or never existed. Since the intake already returns the outcome synchronously, the polling leg is redundant in the happy path here; treat the read as your error-branch fixture.
They're the two competing answers to card churn. Account Updater patches stored PANs after the fact — a batch-era contract this API wraps in REST — while network tokenization sidesteps reissuance entirely, since tokens survive the underlying card changing. The Optimization & Protection template models that alternative, token provisioning and lifecycle included; card-on-file architectures typically rehearse both and choose per portfolio.
Vendor names identify APIs represented by WireMock template sources. This page does not imply vendor endorsement, certification, partnership, or official integration status.