A WireMock simulation of Plaid's REST API — covering the pre-Link check that tells an app whether a user is already known to the Plaid network.
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 Static - /network/status/get
curl -s -X POST 'https://4075m.wiremockapi.cloud/network/status/get' \
-H 'Content-Type: application/json' \
-d '{}'POST Static - /profile/network_status/get
curl -s -X POST 'https://4075m.wiremockapi.cloud/profile/network_status/get' \
-H 'Content-Type: application/json' \
-d '{}'Spec catalog — The Plaid API (2020-09-14_1.688.6) · 2 endpoints
| Method | Path | Summary |
|---|---|---|
| POST | /network/status/get | Check a user's Plaid Network status |
| POST | /profile/network_status/get | Check a user's Plaid Network status |
Unauthenticated WireMock Cloud demo sandbox for Plaid — not an official Plaid sandbox, and it returns simulated example data only.
The smallest decision with the biggest UX payoff: before opening Link, an app can ask whether this user has connected a bank through Plaid before, and route the returning majority into a faster flow. Both stubs here answer that question the same way — network_status RETURNING_USER beside a request_id, nothing else — once under /network/status/get and once under /profile/network_status/get, the same check addressed through two API namespaces. The two-field response is the entire contract, which makes this sandbox the quickest of the Plaid set to integrate: one branch condition, tested in seconds.
Whether to hand the user Plaid's remembered-account experience instead of a from-scratch institution picker. The pre-Link branch in your code — check status, choose a flow, then mint a link token — is exactly what this sandbox pins down; the deterministic verdict means the returning-user branch runs on every test.
Not from this instance — both routes always report RETURNING_USER. Cover the opposite branch by copying the template into WireMock Cloud and editing one field, or by matching on request content so different test users draw different verdicts from the same route.
Whichever your integration generation uses — they coexist in Plaid's API and they coexist here, serving one payload from two addresses. That equivalence is itself testable: a migration from one namespace to the other can assert that both return the shape your handler parses.
Nothing here inspects one — the stubs key on the route, so an empty JSON body draws the verdict too. Whatever identifiers your production calls carry, keep genuine phone numbers and emails away from a shared instance; the natural next call after the check, minting a token for Link, belongs to the Link & Tokens template.
Vendor names identify APIs represented by WireMock template sources. This page does not imply vendor endorsement, certification, partnership, or official integration status.