Skip to main content
The Plaid API in Sandbox, for agents that link bank accounts, read balances and ACH numbers, or keep a ledger in step with Transactions Sync. Plaid’s own Sandbox is real but uncooperative: its Items update on their own schedule, a pending charge posts when it posts, and an ITEM_LOGIN_REQUIRED or a BALANCE_LIMIT cannot be summoned for a test. This twin answers with Sandbox’s own envelopes, token shapes and replay rules, and moves when the environment advances. Slug: plaid

What it models

Advancing the environment finishes open Link sessions (an update-mode one repairs an Item waiting on its user), delivers a fresh Item’s history, completes refreshes, builds requested asset reports and lands statement refreshes, and posts pending transactions (the pending one is removed, the posted one added with pending_transaction_id). Transfers move only through Sandbox’s simulations, as on Sandbox. Directives — set_item_error, repair_item, set_rate_limit, set_product_ready, queue_transaction_change, set_sync_mutation — create the states no Sandbox call can.

Not modelled

Products Sandbox refuses this application, so there is nothing live to hold the twin to: Beacon, Identity Verification, Monitor, Bank Transfer, Wallet, processor tokens, Signal, Income, Employment and Consumer Report. Also recurring transfers and test clocks, the Assets PDFs, Link’s browser UI and the Link UI events of a session, webhook delivery retries, institutions outside Sandbox’s test catalog, and any test user or institution other than user_good at ins_109508 as an Item. Where Sandbox answers from a model the twin cannot reproduce — fuzzy Identity Match scores, enrichment of arbitrary descriptions — the call answers not-modelled rather than a guess. An operation Plaid has that the twin has not built answers an explicit 501 with error_code: NOT_MODELLED, never a plausible response; a path Plaid does not have gets Plaid’s own 404 NOT_FOUND.