Postman collection for 1C-Bitrix: where verification diverges from API
A typical situation during integration: some exchange methods are described in documentation, some exist only in code and developer memory.
API verification for 1C-Bitrix is done manually — a request is assembled in the console or browser, the response is inspected by eye, and that is where it stops.
The divergence between the description and system behavior surfaces later, already in production, and manifests as errors during data exchange: duplicated orders, missing items in export, exchange that "sometimes fails."
The causes are usually minor and therefore unnoticeable. Documentation promises one date format, but the method accepts another. Some parameters are mandatory only under a certain combination of filters. An error comes with a success response code in the body.
The result depends on the component cache or the permissions of the user under which the request runs.
A Postman collection turns one-off manual request verification into a reproducible process: environments for staging and production, a shared token and base URL, create — read — update — delete chains, checks of response code and body structure. A run from the build pipeline shows what changed in the API before rollout to live data.
This way the divergence between the description and system behavior is caught on staging, not in prod. Next, we analyze how this is closed — from method inventory to a schedule of regular runs.
What changes after bringing order to integration checks
Before order was brought in, exchange verification looked like this: an engineer manually pulled methods, compared responses by eye, and kept in mind which scenarios had already passed.
One run took hours, and some chains — order intake, catalog synchronization, status export — were not tested at all before release. The error surfaced for the user, not on the test environment.
A collection in Postman turns this into a repeatable run: scenarios live as one set, environment variables substitute the addresses of the test and production environments, and responses are checked automatically by code and structure.
Integration verification time is reduced manifold — a full pass takes minutes, and it is not a pity to run before every deployment.
Pre-deployment verification becomes a mandatory step: the suite runs on the test environment, and divergences in formats and required fields are visible before changes go to production.
Due to this, the share of exchange failures drops — a changed response schema, a missing required parameter, or mismatched reference data are caught in tests, not at the moment of real export.
Data exchange stability rests on predictability: the same set of checks runs after every code or integration setting change, so regressions are visible immediately. A new engineer gets a ready scenario instead of verbal instructions — reproduces it and gets the same result.
Ways to store and pass verification requests in a team
Verification requests to the 1C-Bitrix API outlive a single task: the same call is needed during integration, during incident investigation, and during release acceptance.
The question is not where it is convenient to write them, but whether the request is reproducible on a second engineer's machine without messenger chat.
The choice comes down to four options that are actually chosen on projects.
| Option | When suitable | Limitations |
|---|---|---|
| Shared request collection in the project repository | several engineers and stands, exchange with external systems | requires environment and variable support, otherwise requests break when the stand address changes |
| Personal notes and saved requests | one-off task, single performer | when the project is handed over, requests are lost, history is not reproducible |
| One-off manual requests from the console | diagnostics here and now, testing one hypothesis | not kept in the project, assembled anew each time |
| Scheduled automated checks | critical exchange scenarios with 1С, availability monitoring | requires a maintained check suite, false positives when the stand is unavailable |
Environments and variables are what turn a request set into a working tool: the stand address, access key, and API version are moved into variables, and one collection works both on a local copy and on the test environment.
Storing verification requests next to the code gives one more thing: you can see which specific call stopped responding after a change — by a specific check, not by the performer's memory.
Setup order: from method analysis to handover to colleagues
A collection is assembled not by the documentation table of contents, but from real exchange scenarios: first we export the API call log for the working period and see what the portal actually calls, with which parameters and how often.
Then work proceeds iteratively — from grouping methods to a run on a copy of the production portal. Below is the order we follow during setup.
- API method analysis. We compare the call export with the module documentation, mark working methods, their required and optional parameters, and expected response codes. The collection includes what is used in exchange, not the entire reference.
- Exchange schema. We arrange methods into folders: catalog, orders, warehouses, contractors, files. For each call — an example request body and a reference response, so format divergence is visible immediately.
- Access rights to methods. For each group we create a separate user or integration point with minimally sufficient rights. The collection does not run under administrator, and this limits damage from a key leak.
- Environment setup. Portal address, token, infoblock and warehouse IDs are moved into variables. Switching between environments is done by changing the value set, without editing the requests themselves.
- Run on the test environment. We check exchange on a copy of the production portal: we record reference responses, and separately — handling of failures by authorization, rights, limits, and timeouts. We save checks as assertions inside the collection.
- Handover and training. The collection goes to the version control system together with the variable description and edit regulations. We conduct a walkthrough on a live example: how to add a method, update a token, roll back a failed change.
A new engineer after such a handover reproduces the exchange scenario and sees the cause of the error without reading the module source code.
What the team hands over after exchange implementation
Exchange with 1С lives longer than the project in which it was built. Six months later another developer and another integrator come to it, and the first question is which methods are called, with which rights, and on which environment.
Therefore, together with the code we hand over artifacts by which the exchange is set up and verified without messaging the author.
- Collection files — an exported request set arranged by exchange folders: catalog, orders, warehouses, webhooks. Request-level tests check the response code and body structure, while addresses and keys are moved into variables.
- Environment description — separate variable sets for each environment: development, test, production. Switching environment is one choice in Postman, not editing twenty requests manually.
- Access matrix — a table "method → rights → authorization source": where a webhook is sufficient, where a user with a limited role is needed, and which method is closed at REST level.
- Launch instructions — import the collection, select the environment, call order, expected response codes, and what to do on authorization failure.
- Test data set — infoblock IDs, test orders, and accounts by which the chain is verified from creation to confirmation.
- Update regulations — who and when edits the collection: when the exchange schema changes, an infoblock property is added, or the portal address changes. The rule is one — collection first, then code.
- Acceptance checklist — what we check before deployment: response codes, idempotency of repeat send, behavior when 1С is unavailable.
The collection lies in the same repository as the exchange code, so a method edit goes into the shared change set and passes review together with the implementation.
Case: exchange with an external system before and after bringing order
The customer is a wholesale supplier: catalog and stock live in an external accounting system, the storefront is on 1C-Bitrix, and there is constant API exchange between them.
Nomenclature export, order intake, status synchronization — three independent scenarios, each with its own headers, token, and response format.
How it was
Verification of one scenario took 40–60 minutes: the engineer assembled the request manually, substituted the token and test SKU, looked at the response in the console, then compared the result with the database.
Errors in response parsing and empty field handling surfaced already in production — up to a third of failures were noticed not by the developer but by the manager whose stock did not update. Fixing the exchange itself stretched to two days: half the time went to reassembling checks.
What changed
We assembled a Postman collection with environments for test and production, variables instead of hardcoded addresses and keys, data preparation scripts, and checks on response code and field structure.
Each exchange scenario got its own check set, and the entire collection runs with one command — before deployment.
Exchange verification was reduced from 40–60 minutes to 5–7, and failures reaching production — to isolated cases. A change in the exchange scenario is released in half a working day instead of two.
How manual browser verification differs from a request set
Manual browser verification answers one question: "does this scenario work right now".
The address, request body, headers, cookies, and authorization token live in the developer tools tab and disappear with it — repeating the check a day later or handing it over to a colleague is possible only from memory.
A request set records each call as an artifact: method, address, parameters, body, headers, authorization method.
Environment variables substitute the stand address and credentials, so the same Postman collection works on a local copy, test environment, and production environment without edits.
The difference between approaches shows on repeat tasks. A manual run is walked anew each time: out of ten calls three or four are remembered, and rare branches are skipped — that is exactly where regressions hide.
A saved set runs entirely and returns response codes and bodies, so before-and-after release comparison takes minutes instead of an hour.
Verification reproducibility is not convenience but a measurable property. Checks inside a request on response code, structure, and required fields turn the set into a regression contour: it passes equally for the developer, tester, and build server.
The collection lives in the repository next to the code and updates together with the API contract. A new method is an edit of one request, not assembling a scenario from scratch, so the investment pays off already on the first repeat run.
Questions about access, stands, and data exchange
Doubts around a collection are usually not about the requests themselves, but about the environment: a closed loop without external access, a database copy without live data, service user rights to the needed methods.
This is resolved before start — otherwise the collection will be assembled but will not run where needed.
A separate topic is the life of the collection after handover: methods in 1C-Bitrix change between updates, some are not described in documentation, and support goes to another team.
The test stand is closed and gives nothing outside — will it be possible to set up data exchange?
Yes. A collection is a set of files describing requests and environments; it does not need internet. We assemble it inside your perimeter or connect to an isolated environment through an intermediate node.
The required method is not described in documentation — what to do?
We capture behavior from a working instance: record actual responses, required fields, error codes, and limitations. We add response structure checks to the collection — deviation from the expected format fails on the first run.
How to hand over integration to your team and support it further?
We hand over the collection with scenario folders, an environment set, and a variable list — the access keys themselves remain with you. Plus instructions: how to run the suite, how to add a changed method, and where to look on divergence.
Let's discuss the task: what to describe in a request for exchange setup
To come back with a timeline estimate, not clarifying questions, we need a minimum of inputs on the environment. The more precisely the system composition and exchange directions are described, the fewer assumptions in the work plan — and the fewer edits after start. Below is a list of what speeds up review of an exchange setup request.
- System composition: which components are involved — site, portal, accounting system, external services — and which modules are used on them.
- Exchange directions: which entities are synchronized (catalog, orders, stock, contractors), in which direction and by which event — on schedule or on change.
- Test environment: whether there is a separate copy with depersonalized data or debugging will be done on the production system.
- Access rights: under which account calls are made, which methods are open, whether there are address restrictions and request limits.
- Frequency of changes: how quickly the data schema changes, who approves it, and whether several method versions need to be supported simultaneously.
- Integration history: what is already configured, where exchange logs are stored, and which divergences are known at the current moment.
From these inputs the work plan is assembled: sequence of stages, checkpoints, performers, and who on the customer side confirms the result at each step. Describe the task in free form — we will come back with a timeline estimate and stage composition.