# plaid-postman: a Postman collection for exploring the Plaid API without code > plaid-postman is a Postman collection and quickstart guide that lets you call the Plaid API from the Postman interface instead of writing code, with a preconfigured Sandbox environment where credentials and tokens are carried between requests automatically. It covers item creation, income flows, Check consumer reports, identity verification, Layer, production calls and webhook testing, and it is maintained by Plaid with the licence unstated. **plaid/plaid-postman** — Postman collection for the Plaid API - Repository: https://github.com/plaid/plaid-postman - Website: https://plaid.com/docs/ - Stars: 554 · Forks: 324 - Language: HTML - License: not declared - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/plaid-plaid-postman ## What the plaid-postman repository actually contains The repository is small and it is worth being precise about what is in it, because the name suggests more than there is. The top level holds a README, a How to contribute file, a link.html page, an images directory and an example_data directory. The collection itself is not a file you clone and open. It lives on Postman, in the Plaid API workspace, and the repository points at it directly so you can jump straight into the Postman interface. That makes this a documentation repository with a companion collection rather than a code project, and the primary language recorded for it is HTML, which is consistent with a repository whose main artefact is a hosted collection and a static page. The example_data directory is the one piece that behaves like a fixture set, holding sample data for the requests to use. The stated purpose is to give you a quick and easy way to get started with the Plaid API with no additional code. The guide invites you either to read the instructions or to go directly to the collection, and it points at a separate quickstart repository that does use code for anyone who prefers that route. There is also a three minute video and a fuller walkthrough video, so the same guide exists in three forms: prose, video and executable requests. The collection is kept up by Plaid, which is the detail that matters most for a project of this kind. A third party collection for a proprietary API goes stale within months, because endpoints get added and renamed. A collection maintained by the API vendor is more likely to match the current documentation, and the homepage link for the repository points at plaid.com/docs as the reference. The repository is not archived and the last push was on 2026-10-15, and it publishes no GitHub releases. ## Getting the collection into Postman and the keys into the environment The setup is three steps, and the first one is not about Postman at all. You sign up with Plaid to get a set of API keys, which are required for interacting with the API. The keys come from the Plaid dashboard, and the guide later points at the developer keys page specifically, so the account is the first dependency. The second step is the collection itself. You click the Run in Postman button and then click the Fork Collection button when prompted, and you will be required to create a free account with Postman to do it. Forking rather than running the shared copy is the important detail, because it means the environment and any edits are yours, and the collection you are pointed at belongs to a Plaid workspace on Postman that you should not be modifying in place. The third step is configuration, and it is where the design of the collection shows. The Plaid Postman collection uses Postman environment variables to simplify each API request. You select the Sandbox environment in the top right corner, click the eye icon to open the environment settings, and copy your Plaid API keys from the Plaid dashboard into each field, which are `client_id` and `secret_key`. Then you save and start making requests. Those two variables are the whole of the credential surface. The reason the collection can run with two keys is that the Sandbox environment it ships with already carries a preconfigured set of additional variables for the other credential types the Plaid API has, including access tokens and public tokens, and the collection wires the sandbox's test credentials into the requests for you. The practical consequence is that in Sandbox you are usually not pasting anything but the two dashboard keys, and every other field is a placeholder the collection fills in or the sandbox ignores. ## The sandbox token chain, step by step, without writing code The core of the guide is a walkthrough of how a request sequence works, and it is a good illustration of the Plaid data flow. The first move is to make sure the Collection pane is selected, then expand the Plaid API Endpoints folder on the left and drill into Plaid API Endpoints, then Items, then Item Creation, then Create Item [Sandbox Only]. The sandbox-specific suffix is there for a reason, and the guide explains it: the Sandbox test environment has special capabilities that let you bypass the client-side Link UI and make all of the requests via the backend. That is the shortcut that makes the collection usable. In production, a user goes through Link, a client-side flow, and the API surfaces a public token. In Sandbox, you create an item directly and get a `public_token` back without any user interface. The response body appears in Postman when you click Send, and the `public_token` returned will automatically be used in the next request. Then you select the Exchange token endpoint, click Body, and hit Send. An `access_token` is returned and is again used automatically in the next request. After that you pick a product endpoint. The guide suggests Balance as a simple example, since for Balance there are no other required fields to complete. You click Send and you receive a response containing your requested data. The chain is therefore Create Item, then Exchange token, then a product call, with the two tokens carried forward automatically by the environment. That is the whole demonstration, and it is exactly the sequence a real integration performs, which is what makes the collection useful as a reference rather than only as a sandbox toy. ## Income, Check consumer reports, identity and Layer need different paths The interesting part of the collection is where the flow stops being uniform. Income is the first branch. Testing the Payroll Income or Document Income flows requires modifying the steps above. Instead of calling Create Item [Sandbox Only], you go to the Income folder and call Create User Token, followed by Initialize User Token for Payroll Income [Sandbox only] or Initialize User Token for Bank Income [Sandbox only] as appropriate, and then finally Retrieve Payroll Income or Retrieve Bank Income. That is a four step chain with two variants, and it exists because income verification is a flow with its own state machine rather than a single endpoint. The same pattern reappears for Check consumer reports, where the project description notes a new custom addition, and for Identity Verification and Monitor, which have their own entry points in the collection. The Layer product is listed as its own section too, which suggests it is reached through a distinct set of endpoints rather than through the standard item and token sequence. The pattern across all of these is that the sandbox shortcut is the only thing that makes them exercisable without a browser. In production, each of these paths would begin with a Link session and a user granting permissions, and the interesting part of the API is what happens after that grant, which is precisely what the sandbox path lets you see. What the collection cannot show you is the Link user experience itself, and that is the one gap worth naming before you rely on it. You learn what the API returns, not what the consent flow looks like, how the redirect back to your application works, or how the webhook that signals completion behaves. The guide points at a separate section for making API calls with real data in Production, and at webhook testing tools, which are where the parts of the integration that the sandbox skips are covered. There is a table of contents covering getting started and configuration, the sandbox calls broken into Income, Check consumer reports, identity verification and Layer, production calls with real data, and the webhook testing tools. The last two sections are the ones to read before you go live. ## Where plaid-postman is the wrong tool The first limit is that it is a manual tool. Every request is a button click, which is fine for exploring an API and wrong for anything continuous. There is no retry logic, no scheduled polling, no structured error handling and no test suite that runs in your pipeline. If you need to verify that your integration still works after a Plaid release, a collection does not give you that, and the repository does not include a runner or an assertion layer. The second limit is the credential handling. The API keys go into a Postman environment, which for a shared Postman workspace means the keys live in a cloud service that other people in the team can see and that you cannot easily audit. For sandbox keys that is a normal trade. For production credentials it is not, and the guide's production section is where that boundary should be. The third limit is the link flow, as noted above. The sandbox bypasses the client-side Link UI, so the collection tells you nothing about the part of the integration that users actually touch, and nothing about how a Link session is opened and closed from your application. The fourth limit is scope of coverage. The collection follows the products Plaid has endpoints for, and it is a snapshot of the API as of the version it was published against. A new product endpoint will not appear until the collection is updated, and the collection is updated on the vendor's schedule rather than yours. Compare that with the Plaid quickstart repository, which the guide points to for people who want code. The difference in approach is that the quickstart is a program you run and read, which teaches you the shape of a real client, while the collection is a set of requests you fire, which teaches you the shape of the API. If your goal is to learn the API, the collection is faster. If your goal is to write the integration, the code samples are the better starting point, and the collection is better as a reference for the endpoint you are unsure about. ## Licence, contribution route and what to check before your first request The repository does not record a licence. That is unusual for a repository with a How to contribute file, and it means the terms of use for the collection and the documentation are not stated in a way you can point at, so if you intend to reuse the example_data fixtures or republish parts of the guide, you have to establish the position with Plaid directly rather than assume a permissive default. The project publishes no GitHub releases, so there is no version to pin. What you get is the current state of the Postman collection in the Plaid API workspace, which is the artefact that matters, and it is versioned on Postman's side rather than here. The last push was on 2026-10-15 and the repository is not archived. There is a link.html page at the top level, which is what the Run in Postman flow and the collection link resolve to for a visitor arriving from a search rather than from the repository itself. What to check before your first request is short. Create the Plaid account and take the keys from the developer keys page, then decide whether you are working in Sandbox or Production, because the guide is structured around Sandbox first and the production section assumes you already know the endpoint shapes from it. Fork the collection rather than editing the shared one, and set the `client_id` and `secret_key` fields in the Sandbox environment. Then run the three request chain from the guide, Create Item, Exchange token, then Balance, so that you can see the token handoff working before you try a product with more parameters. And before you move to production, read the webhook testing section rather than skipping it. Webhooks are how the integration learns that a background process finished, and they are the part of the Plaid API that a Postman collection exercises least well. ## Conclusion plaid-postman fits a developer or product manager who needs to see real Plaid API responses before writing any integration code, and it fits a team that wants a shared, executable specification of the endpoints rather than a document that drifts out of date. It does not fit as a production client, because a Postman collection is a manual tool rather than a library, and it does not fit a compliance-sensitive integration without reading the terms, since the repository does not state a licence. Before you start, sign up for Plaid API keys, fork the collection into your own Postman workspace rather than editing the shared one, and paste your keys into the Sandbox environment variables `client_id` and `secret_key` before you send the first request. ## FAQ ### What is the plaid-postman collection and what is it for? It is a Postman collection and quickstart guide maintained by Plaid for getting started with the Plaid API without writing any code. The collection lives in the Plaid API workspace on Postman and is forked into your own workspace, and the repository holds the guide, example data and images. ### How do I configure the Plaid Postman collection? Sign up with Plaid to get API keys, then click the Run in Postman button and the Fork Collection button. In Postman, select the Sandbox environment, open the environment settings with the eye icon, and copy your `client_id` and `secret_key` from the Plaid dashboard into the matching fields before saving. ### How do I make a first Plaid API call in the sandbox? Expand Plaid API Endpoints, then Items, then Item Creation, and call Create Item [Sandbox Only]. The returned `public_token` is used automatically in the next request, so you then call the Exchange token endpoint to get an `access_token`, and that is used automatically for a product endpoint such as Retrieve Balance. ### What licence does plaid-postman use? The repository does not record a licence, so the terms are not stated by a licence file you can point at. It publishes no GitHub releases, the repository is not archived, and the last push was on 2026-10-15. ### What does the sandbox environment let me skip? The Sandbox test environment can bypass the client-side Link UI so that all requests are made via the backend. That means you can create an item and get a public_token without a user going through the consent flow, which is what makes the whole token chain testable in Postman. ## Sources - [Issues](https://github.com/plaid/plaid-postman/issues) - [plaid/plaid-postman on GitHub](https://github.com/plaid/plaid-postman) - [Project website](https://plaid.com/docs/) - [README](https://github.com/plaid/plaid-postman/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/plaid-plaid-postman