A WireMock simulation of Chase JPMorgan's REST API — covering consumer profile CRUD, address and communication maintenance, stored payment methods, 3-D Secure status, and bulk-import tracking.
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 - GET /healthcheck
curl -s -X GET 'https://lo8y2.wiremockapi.cloud/healthcheck'POST Create consumer profile - POST /consumer-profiles
curl -s -X POST 'https://lo8y2.wiremockapi.cloud/consumer-profiles' \
-H 'Content-Type: application/json' \
-d '{}'POST Add payment method - POST /consumer-profiles/{consumer-profile-id}/payment-methods
curl -s -X POST 'https://lo8y2.wiremockapi.cloud/consumer-profiles/your-consumer-profile-id/payment-methods' \
-H 'Content-Type: application/json' \
-d '{}'Spec catalog — Consumer Profile Management API (2.3.1) · 18 endpoints
| Method | Path | Summary |
|---|---|---|
| GET | /bulk-import/status | Retrieve the status of a bulk import file |
| POST | /consumer-profiles | Create a consumer profile |
| DELETE | /consumer-profiles/{consumer-profile-id} | Delete a consumer profile |
| GET | /consumer-profiles/{consumer-profile-id} | Retrieve a consumer profile |
| PATCH | /consumer-profiles/{consumer-profile-id} | Update a consumer profile |
| POST | /consumer-profiles/{consumer-profile-id}/addresses | Add a new address to an existing consumer profile |
| DELETE | /consumer-profiles/{consumer-profile-id}/addresses/{address-id} | Delete an address |
| PATCH | /consumer-profiles/{consumer-profile-id}/addresses/{address-id} | Update an address on an existing consumer profile |
| POST | /consumer-profiles/{consumer-profile-id}/communication | Add a new communication to an existing consumer profile |
| DELETE | /consumer-profiles/{consumer-profile-id}/communication/{communication-id} | Delete a communication method |
| PATCH | /consumer-profiles/{consumer-profile-id}/communication/{communication-id} | Update a communication attributes based on communication id provided; either email or phone |
| PATCH | /consumer-profiles/{consumer-profile-id}/communication/{communication-id}/default | Update a communication method to default on an existing consumer profile |
| POST | /consumer-profiles/{consumer-profile-id}/payment-methods | Add a new payment method to an existing consumer profile |
| DELETE | /consumer-profiles/{consumer-profile-id}/payment-methods/{payment-method-id} | Delete a payment method |
| PATCH | /consumer-profiles/{consumer-profile-id}/payment-methods/{payment-method-id} | Update a payment method on an existing consumer profile |
| PATCH | /consumer-profiles/{consumer-profile-id}/payment-methods/{payment-method-id}/default | Update a payment method to default on an existing consumer profile |
| GET | /consumer-profiles/{consumer-profile-id}/payment-methods/{payment-method-id}/status | Retrieve 3DS status |
| GET | /healthcheck | Health check for CPM API |
Unauthenticated WireMock Cloud demo sandbox for Chase JPMorgan — not an official Chase JPMorgan sandbox, and it returns simulated example data only.
The top-level profile resource runs the complete CRUD cycle, and every verb means it. Creation accepts any body — empty included — and mints a six-character profile id alongside two UUIDs, storing whatever fields you sent; PATCH folds new values into the record and the merge holds on every later read; DELETE removes the record outright, so the next GET answers the dedicated profile-not-found body. Around that live store sit the fixtures: all eleven address, communication, and payment-method routes reply with one canonical profile — John Doe of Glen Mills, PA, profile id PACJGQ, one phone, one email, one shipping address named "Work" — and the 3-D Secure status read reports a card authenticated successfully for any payment-method id. A bulk-import status route rounds out the surface with a completed 1,000-record file, 950 processed and 5 errored, its tokenization counters at one hundred percent.
Only the ones aimed at /consumer-profiles itself. Top-level create, PATCH, and DELETE all mutate real state — a renamed profile stays renamed, a deleted one 404s. The sub-resource routes are theater by comparison: they accept any body and answer the John Doe fixture, whose profile id doesn't even match the one in your path — the giveaway that nothing was written. Adding an address, then re-reading your profile, shows the addresses array still empty; assert sub-resource contracts against the fixture and profile state against your own minted record.
Every sub-resource verb, deletes included, responds with the full canonical profile rather than a 204 — the API's way of handing back the post-operation view of the record. Since the fixture is static, the profile you get is always PACJGQ's, whatever id you addressed. Client code that parses the delete response should tolerate a populated body, and integration tests wanting delete-then-verify semantics get them one level up, where profile deletion genuinely removes the record.
No — the read is pinned to success: responseCode AUTHENTICATED, a fixed transaction identifier and authentication id, for any payment-method id you name. That makes it a clean fixture for the post-challenge happy path. The authentication sequence that produces such a result — initiation with ACS method data through the completed challenge — lives in the Optimization & Protection template, which models that two-step flow as a real state transition.
The end-state of a file-processing dashboard. One response carries the merchant file name, COLUMN_BASED format and version, totals of 1,000 records with 950 processed and 5 errored, an overall COMPLETED_SUCCESSFULLY verdict, and a tokenization block reporting ten request files fully sent and received. Note the completion percentages arrive as strings — "100", not 100 — so progress-bar code that does arithmetic on them needs the cast a real integration would need too.
Vendor names identify APIs represented by WireMock template sources. This page does not imply vendor endorsement, certification, partnership, or official integration status.