# binance-api-postman: generated collections, and the X-MBX-APIKEY step that trips everyone up > The binance-api-postman repository ships Postman collections and environment JSON files for Binance's REST API, auto-generated with OpenAPI Generator. Its real value is the environment template that puts the API key header and the signature parameter in the right place; its real limitation is that it is a generated artifact you import by hand and cannot meaningfully patch yourself. **binance/binance-api-postman** — Postman collection for Binance Public API, including spot, margin, futures, etc. - Repository: https://github.com/binance/binance-api-postman - Stars: 1,646 · Forks: 930 - Language: Unknown - License: MIT - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/binance-binance-api-postman ## Two directories, collections and environments The repository root is small and its shape explains how it works: .gitignore, .prettierignore, .prettierrc, CHANGELOG.md, LICENSE, README.md, an assets/ folder holding the screenshots the README embeds, and then two content directories, collections/ and environments/. Those two directories are the whole product. Collections are the request definitions, the folders of endpoints you can fire from the Postman sidebar. Environments are the JSON files holding variable values, which is where your credentials go. The project description names the coverage as spot, margin, futures and so on, so this is a read-and-trade surface rather than a single-endpoint sample. The README frames the value proposition as speed rather than capability: Binance offers several Postman collections and environments, as JSON files, for a quicker and easier usage of their RESTful APIs, and the setup claim is that you only need to import and set up your own API and secret keys to begin. That is accurate as far as it goes. What the collections buy you is the shape of every signed request: which headers are present, which parameters are mandatory, and in what order the signature parameter has to appear. The .prettierrc file is worth noting. A repository of JSON request definitions formatted by Prettier implies the collections are treated as generated artifacts with a formatting contract, which matches what the contributing section later says about code generation. ## Import is a folder selection, then a dropdown choice There is nothing to build or install. The whole onboarding procedure is inside the Postman GUI, and the README walks through it step by step with a screenshot for each stage. You download the repository, click Import (at the top left on Postman for Mac), and on the Import page select the root folder of the downloaded repository rather than a single file. Postman then shows you which collections and environments it found, and you choose what to bring in before clicking Import again. The step that people miss comes next. You select the Environments tab on the left, choose an environment, and set your API and Secret Key by editing the Current Value column. Then, and this is the part that produces most support questions, you pick that newly added environment from the environment dropdown at the top right, to the left of the eye icon. That last action is not cosmetic. The README's first FAQ entry is why no response comes back at all, and the answer is that you either never imported the environment file or imported it without selecting it from the dropdown. A collection that is not bound to an environment sends empty variables, and an empty API key produces an authentication error rather than market data. ## The three error messages and what each one actually means The FAQ section is the most useful part of the README because it maps specific API error strings to specific mistakes in the collection setup. An empty response, covered above, means the environment is missing or unselected. The error `API-key format invalid.` has three listed causes: the API key is not set, the API key is not correct, or `X-MBX-APIKEY` is not selected in the Postman Headers tab. That third cause is the interesting one, because it means the header is part of the request definition and has to be enabled in the Headers tab of the request. A key pasted correctly into the environment still fails if the header that carries it is switched off. The error `Signature for this request is not valid.` lists three causes: the secret key is not set, at least one parameter is empty, or `signature` is not last in the parameters list. The signature parameter has to come last, and an empty parameter in the middle of the query string changes what gets signed. A fourth case, `Mandatory parameter 'xxxx' was not sent, was empty/null, or malformed.`, is not a collection bug at all. The answer is to consult the API documentation and double check the mandatory parameters. For debugging generally, the README points at Postman's console to see a request's parameters and URL, and suggests editing the Pre-request Script tab. That is where you inspect what actually went on the wire rather than what the collection says should have. ## Generated code means your edits will not survive The contributing section is short and unusual enough to quote. The repository contains auto-generated code using OpenAPI Generator, and the requested workflow is two steps: open a GitHub issue to discuss the idea or report a bug, then allow maintainers to implement the necessary changes through the code generation process. The implication is straightforward. Hand-editing a collection or an environment in Postman and saving it back into your fork is possible, but the change will not exist in the upstream specification that OpenAPI Generator reads, so the next regeneration discards it. If a request is missing a header or a parameter, the route is an issue, not a patch. This also shapes how you should think about drift. A CHANGELOG.md exists at the root, but the README does not describe its format or how to read it against the exchange's API. The repository is not archived and the last push was on 2026-10-15. Its default branch is `master`. ## The safety list is the part worth reading twice Before the FAQ, the README gives account safety practices. Two are generic hygiene: do not use collections obtained from an unknown source, and review the environment JSON file before using it, and do not use any code you do not understand. The advice to read the environment file is sensible precisely because of the generation point above, since a Pre-request Script in a generated collection is code that runs before every request. Two are specific to this exchange. Make sure the withdrawal permission is not enabled for your API keys. And when you finish trying out the API, delete your API keys. That last pair is a deliberate narrowing of blast radius for a tool whose whole purpose is to make placing orders easy. A Postman collection that lets you fire a signed order against a live account is one misclick away from a real trade, and the collection cannot enforce a read-only mode on your key. The permission setting on the key is the control that matters, and it lives on Binance's side, not in the collection. The disclaimer reinforces the same point from the other direction. The collections are provided as is and as available, at your own risk, with no representation or warranty as to operation, accuracy, reliability, completeness, or fitness for a particular purpose, and no liability for losses including financial losses from errors, bugs, interruptions or inaccuracies. Use of the collections to access the platform is subject to the Binance API Key Terms and the Binance Terms of Use, which prevail in the event of any conflict. You are stated to be solely responsible for any orders or transactions executed through the platform using them. The repository licence is MIT, which covers the collection and environment JSON as files. It does not reach the exchange terms that govern what you do with them. ## Where this sits against generating a client yourself The obvious alternative is to skip Postman and generate a typed client from the same source, or to write the handful of signed requests you actually need by hand. The difference in approach is worth being clear about, because it determines whether this repository is a tool or a reference. Postman plus these collections is a manual, exploratory workflow. You pick a request from a tree, fill in variables in the URL, path or body tab, hit send, and read the response. There is no error typing, no compile-time check, and no reusability beyond the environment file. Its advantage is that it requires no language, no build step, and no SDK to keep in step with the exchange. A generated client inverts those properties. You get typed parameters, but you take on dependency management. Given that the README for this repository already states that the collections are generated with OpenAPI Generator, running that generator yourself into a language client is a small conceptual step up from importing the JSON. The remaining niche for the collections is the signed endpoints, where the failure modes are fiddly rather than structural. The `Signature for this request is not valid.` case, with signature needing to be last and empty parameters changing what gets signed, is exactly the class of problem where clicking through a working example teaches you the ordering faster than reading a signing specification. ## Conclusion Use binance-api-postman if you want to explore the Binance REST surface by hand in Postman, especially the signed endpoints, because the environment template saves you from assembling the header and the signature ordering yourself. Do not build automation on top of it: the repository is auto-generated, the README asks contributors to open an issue and let maintainers regenerate rather than hand-edit, and there are no GitHub releases, so a change you make locally will not survive the next regeneration. Verify first that the environment is selected in the dropdown and that your key has withdrawals disabled, since those two checks resolve most of the errors the README documents. ## FAQ ### Why do I get no response when using the Binance Postman collections? Either you have not imported the environment file, or you imported it without selecting it from the environment dropdown menu at the top right. The README gives no other cause for a completely empty response. ### What causes the error API-key format invalid in binance-api-postman? Three listed causes: the API key is not set, the API key is not correct, or X-MBX-APIKEY is not selected in the Postman Headers tab. The third is the one people miss, since the header has to be enabled on the request itself. ### Why is my signature invalid when I send a Binance request from Postman? The README lists three causes: the secret key is not set, the request was made with at least one empty parameter, or signature is not the last parameter in the parameters list. One cause is an unset secret key; the other two concern request assembly. ### Can I edit the collections in binance-api-postman and contribute my changes? The repository contains auto-generated code using OpenAPI Generator, and the contributing section asks you to open an issue and let maintainers implement changes through the generation process. Hand edits to the JSON would not survive the next regeneration. ## Sources - [binance/binance-api-postman on GitHub](https://github.com/binance/binance-api-postman) - [Issues](https://github.com/binance/binance-api-postman/issues) - [License: MIT](https://github.com/binance/binance-api-postman/blob/master/LICENSE) - [README](https://github.com/binance/binance-api-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/binance-binance-api-postman