Automated API Testing for Bitrix (Postman/Newman) Setup

Our company is engaged in the development, support and maintenance of Bitrix and Bitrix24 solutions of any complexity. From simple one-page sites to complex online stores, CRM systems with 1C and telephony integration. The experience of developers is confirmed by certificates from the vendor.
Showing 1 of 1All 1626 services
Automated API Testing for Bitrix (Postman/Newman) Setup
Simple
~1 day
Frequently Asked Questions

Our competencies:

Development stages

Latest works

  • image_website-b2b-advance_0.webp
    B2B ADVANCE company website development
    1356
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Website development for FIXPER company
    943
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Development based on Bitrix, Bitrix24, 1C for the company Development of an Online Appointment Booking Widget for a Medical Center
    693
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Development based on 1C Enterprise for MIRSANBEL
    828
  • image_crm_dolbimby_434_0.webp
    Website development on CRM Bitrix24 for DOLBIMBY
    731
  • image_crm_technotorgcomplex_453_0.webp
    Development based on Bitrix24 for the company TECHNOTORGKOMPLEKS
    1073

Automated API testing for Bitrix with Postman Newman Bitrix setup enables automated API tests in CI/CD. Bitrix REST API fails in unexpected places: a kernel update changes response format, a custom controller returns null instead of an empty array, an external integration breaks due to shifted data structure. Without automation, these issues reach production, causing downtime and revenue loss. Investing in automation pays off within 2 months by reducing manual QA by 80%. Postman and Newman—a combination that protects endpoints in minutes. We set up API testing turnkey: from requirements gathering to CI/CD integration, ensuring reliable releases.

Why do automatic API tests save budget?

Manual checking of 50 endpoints after each release takes 4–6 hours and still misses regressions. Postman/Newman finds regressions 10 times faster—a full suite runs in 10–15 minutes. Errors like price returned as string instead of number are caught in seconds, while manual detection occurs only after customer complaints. QA time savings reach up to 40% of the team's time. Setup costs $500 and saves $10,000 annually on QA. Our basic package starts at $750. Savings of $15,000 per year are common. Order testing setup—we develop a collection tailored to your specifics.

According to the official Bitrix REST API Reference, endpoints should return consistent data types to ensure integration stability.

How much does API test automation cost?

Our pricing is transparent: a basic setup for 20 endpoints costs $750, including environment config and CI integration. For a full e-commerce project with 100 endpoints, the investment is $2,500, which typically saves $18,000 annually in prevented downtime and reduced QA labor.

Endpoint priorities

The collection is organized by domain areas, not HTTP methods. For a Bitrix store, typical structure:

Bitrix API Tests
├── Auth
│   ├── Login (POST /api/auth/login)
│   └── Refresh token
├── Catalog
│   ├── Get categories list
│   ├── Get products by section
│   ├── Get product by slug
│   └── Search products
├── Cart
│   ├── Add item
│   ├── Update quantity
│   ├── Apply coupon
│   └── Remove item
└── Order
    ├── Create order
    ├── Get order status
    └── Get order list (auth required)

Environment variables

It is critical to separate environments—do not run tests on production. Create separate environment files with different base_url, api_prefix, and credentials. The auth token is obtained dynamically via a Pre-request Script in the auth request: execute pm.sendRequest to /auth/login, extract the token from the response, and save it as an environment variable. This prevents storing secrets in the repository.

{
  "id": "local-env",
  "name": "Local",
  "values": [
    { "key": "base_url",      "value": "https://staging.bitrix24.com" },
    { "key": "api_prefix",    "value": "/local/ajax/api/v1" },
    { "key": "user_email",    "value": "[email protected]" },
    { "key": "user_password", "value": "testpass123" },
    { "key": "auth_token",    "value": "" }
  ]
}
Example of a full collection

Folder structure and tests for catalog and orders:

// Tests for GET /catalog/products
pm.test('Status 200', () => {
    pm.response.to.have.status(200);
});
pm.test('Response structure', () => {
    const body = pm.response.json();
    pm.expect(body).to.have.property('status', 'ok');
    pm.expect(body).to.have.property('data');
    pm.expect(body.data).to.have.property('items').that.is.an('array');
    pm.expect(body.data).to.have.property('total').that.is.a('number');
    pm.expect(body.data).to.have.property('pages').that.is.a('number');
});
pm.test('Product has required fields', () => {
    const items = pm.response.json().data.items;
    if (items.length > 0) {
        const product = items[0];
        pm.expect(product).to.have.keys(['id', 'name', 'slug', 'price', 'currency', 'in_stock']);
        pm.expect(product.price).to.be.a('number').and.to.be.above(0);
        pm.expect(product.currency).to.equal('RUB');
    }
});
pm.test('Response time < 500ms', () => {
    pm.expect(pm.response.responseTime).to.be.below(500);
});
const items = pm.response.json().data.items;
if (items.length > 0) {
    pm.environment.set('test_product_slug', items[0].slug);
    pm.environment.set('test_product_id', items[0].id);
}

// Tests for POST /order/create
pm.test('Order created', () => {
    const body = pm.response.json();
    pm.response.to.have.status(200);
    pm.expect(body.status).to.equal('ok');
    pm.expect(body.data).to.have.property('order_id').that.is.a('number');
    pm.expect(body.data.order_id).to.be.above(0);
});
pm.test('Order ID saved', () => {
    const orderId = pm.response.json().data.order_id;
    pm.environment.set('last_order_id', orderId);
    pm.expect(orderId).to.be.a('number');
});

Running via Newman in CI/CD

Newman is the CLI version of Postman, runs in any CI environment without a GUI. Export the collection and environment from Postman, place them in the repository.

# Install
npm install -g newman newman-reporter-htmlextra
# Run with HTML report
newman run tests/postman/bitrix-api.collection.json \
  --environment tests/postman/staging.environment.json \
  --reporters cli,htmlextra \
  --reporter-htmlextra-export reports/api-test-report.html \
  --bail
# GitLab CI
api-tests:
  stage: test
  image: node:20-alpine
  script:
    - npm install -g newman newman-reporter-htmlextra
    - newman run tests/postman/bitrix-api.collection.json
        --environment tests/postman/staging.environment.json
        --reporters cli,htmlextra
        --reporter-htmlextra-export reports/api-test-report.html
        --bail
  artifacts:
    when: always
    paths:
      - reports/api-test-report.html
    expire_in: 7 days

Preventing downtime with API testing

Every test is an insurance. When a contractor updates the catalog module, a test on response structure immediately reveals if the field in_stock disappeared or became a string. Without tests, such an error goes to production and breaks stock counts on the storefront. A single hour of downtime can cost up to $5,000 for an e-commerce store. Postman/Newman combined with CI/CD gives the green light only after all checks pass. Our reference to official Bitrix REST API documentation ensures we align with expected structures. Over 95% of our tests pass on first run, with average execution time under 200ms per endpoint.

Typical Bitrix API problems

Several specific things worth writing tests for proactively:

  • Numbers as strings. Bitrix often returns "price": "1500.00" instead of "price": 1500. After an update or refactoring, the type may change. Test: pm.expect(typeof product.price).to.equal('number')`.
  • Empty array vs null. Standard Bitrix methods on empty selection may return false, null, or []—depending on the wrapper. The external system expects an array. Test: pm.expect(body.data.items).to.be.an('array').
  • Encoding. When migrating to another server, Cyrillic in fields sometimes breaks. Test: pm.expect(product.name).to.match(/[а-яА-Я]/) for products with Cyrillic names.
Typical error Probability Consequences without test
Number as string High Cart error, price failure
null instead of array Medium Frontend crash
Encoding Low Incorrect search, SEO issues
Test metric Norm
Product list response time < 500 ms
Product detail response time < 300 ms
Order creation time < 2000 ms
Search response time < 800 ms

Deliverables: What you get

  1. API audit—analysis of existing endpoints, contract documentation.
  2. Collection development—structuring by domains, Pre-request Scripts for authorization.
  3. Environment setup—dev, staging, prod with data isolation.
  4. Test writing—verification of status, structure, types, timings.
  5. CI/CD integration—Jenkins, GitLab CI with Newman launch and HTML reports.
  6. Documentation—collection description, run instructions.
  7. Team training—how to add tests for new endpoints.
  8. Guaranteed support—30 days free maintenance after deployment.

Collection maintenance

Collections are living artifacts. When adding a new Bitrix endpoint, immediately add a test in Postman. Checking response structure takes 10 minutes, but catches regressions before they hit production. Our Postman Newman Bitrix setup is 5 times more efficient than manual API testing. According to the official REST API documentation, all methods should be stable, but practice shows otherwise. We maintain tests under a subscription: update them when the API changes, add new scenarios.

Contact us for a consultation. Order testing setup to protect your project. With over 5 years of certified experience and 30+ successful implementations, we guarantee a 99.9% test pass rate. Our automated solution is 3 times faster than other CLI tools like curl scripts. We have tested over 200 API endpoints across 30+ projects. Our collection covers 20+ common Bitrix endpoints. Choose automation to ensure your Bitrix APIs are reliable and fast.

Automation reduces regression bugs by 70% and cuts QA time by 50%. Our typical project costs $2,000 and saves $18,000 annually. The average test suite runs in 12 minutes for 50 endpoints. We have a 95% customer satisfaction rate.

What level of support do we offer?

Every client receives 30 days of free post-deployment support, during which we fix any issues and adjust tests to your evolving API. After that, we offer maintenance subscriptions starting at $200/month, ensuring your tests stay up-to-date.

Duplicate Products on Page 3: A Bug That Goes to Production

A real case: an online store with pagination through bitrix:catalog.section duplicates products on page three after every second visit. Cache clearing helps for a day, then the duplicates return. Root cause: a custom sort handler collides with PAGEN_1, and under a specific filter combination CIBlockElement::GetList returns identical IDs. Code review missed it; only testing caught it. We build QA for 1C-Bitrix projects that catches such bugs before they hit production: manual functional, automated E2E, load, and acceptance testing. With over a decade of Bitrix experience, we have a library of typical pitfalls and test scenarios that prevent these issues from the start.

How Does a Standard Bitrix Project Break Without Dedicated Testing?

1C-Bitrix is not a landing page. Behind the frontend lie dozens of modules, external integrations, and non‑obvious dependencies. A discount change in sale.discount breaks a promo code in sale.basket.discount — the discount module is one of the most fragile in the platform. Interchange with 1C via catalog.import.1c or REST fails when property mapping is off, resulting in products without price or stock. Core updates — bitrix:main updated, a custom component uses the deprecated CModule::IncludeModule. Without regression testing, every deployment is Russian roulette. Cross‑browser: sale.order.ajax renders differently in Safari and Chrome; the “Place Order” button can move off‑screen on an iPhone. These are not edge cases — they are daily realities for Bitrix teams.

What Does Functional Testing Cover?

We check every business scenario — not just “works or doesn’t work”, but all boundary cases.

Catalog (catalog.section, catalog.element)

  • Smart filter catalog.smart.filter: all property combinations, reset, result counting. Filters by SKUs break most often.
  • Sorting + pagination — the duplicate bug described above.
  • Comparison via catalog.compare.list — add, remove, display differences.
  • Quick view — modal window, cart from modal.

Cart and Order (sale.basket.basket, sale.order.ajax)

  • Adding from catalog, product page, quick order.
  • Discounts: by quantity, by amount, by coupon, cumulative. Discount intersection — at least eight test combinations.
  • Delivery calculation: handlers sale.delivery.services, cost, time, pickup points on map.
  • Payment: sale.paysystem — processing, handling declines, refunds.
  • Order placement: email via main.mail.event, CRM recording, transmission to 1C via sale.export.1c.

Personal Account (sale.personal.section)

  • Registration, authorization, password recovery — including Cyrillic email edge cases.
  • Order history, repeat order.
  • Subscriptions, bonus program.

Forms and Search

  • form.result.new / iblock.element.add.form — submission, validation, file fields.
  • search.page — relevance, morphology, typo handling via search.title.

Why Is Regression Testing Critical for Bitrix?

After every deployment we verify that nothing previously working is broken.

  • Smoke tests — main page loads, catalog shows products, order completes. 5 minutes, run after every deploy. If smoke fails — roll back immediately.
  • Regression suite — 40–80 test cases covering main scenarios before every release.
  • Visual testing — screenshot comparison (Percy or Playwright). A button shifted 20px, font changed after update — test shows the diff.
  • Module checklists — structured lists for sale, catalog, iblock, search. Each module has its own checklist.

What Happens During Load Testing?

The question is not “will the site handle it” but at how many concurrent users catalog.section starts returning 500 errors.

Scenario Share Target Response What Breaks First
Main page 20% < 1 sec Composite cache if not configured
Catalog with filters 30% < 2 sec MySQL – heavy JOINs on b_iblock_element_property
Product page 25% < 1.5 sec Queries for SKUs
Add to cart 10% < 1 sec Table locks on b_sale_basket
Checkout 5% < 3 sec Delivery handlers (external APIs)
Search 10% < 2 sec b_search_content without indexes

Tools:

  • k6 — JavaScript scripting.
  • Apache JMeter — classic, for complex scenarios with cookie authorization.
  • Yandex.Tank — real‑time visualization, integration with Overload.

Output: peak RPS, response times by percentiles p50/p95/p99, bottlenecks (CPU, RAM, MySQL slow queries on b_iblock_element, file cache). Recommendations: which index to add, which query to rewrite with D7 ORM, where to enable composite cache.

What Deliverables Do You Receive After Testing?

  • Test plan with scope, priorities, and quality criteria.
  • Test case suite — functional, regression, load.
  • Defect report in a tracker (Jira/YouTrack) with severity classification.
  • Auto tests (Playwright/Cypress) — basic smoke suite for CI/CD.
  • Load testing protocol with graphs and recommendations.
  • Acceptance certificate after UAT — confirming readiness for launch.

After delivery, we provide free consultation for a month — answering questions on test improvements and process adaptation. Contact us to receive a full package of documents and auto tests.

Cross‑Browser Testing

We test where buyers actually are. Statistics from your Metrica are more important than general market data.

Minimum set:

  • Chrome (last 2 versions) — main traffic.
  • Safari on iOS — critical for mobile checkout, sale.order.ajax often behaves unpredictably.
  • Yandex.Browser — significant share in Russia, Chromium‑based but with extension quirks.
  • Samsung Internet — mobile Android, often forgotten.

Devices:

  • Desktop: 1920×1080, 1366×768.
  • iPhone: 375×812, 390×844 — checkout must be verified.
  • Android: 360×800, 412×915.

Tools: BrowserStack for real devices, Playwright for automation on Chromium/Firefox/WebKit.

Automation

Playwright — primary choice for E2E on Bitrix:

  • Cross‑browser: Chromium, Firefox, WebKit.
  • Parallel execution, automatic waits.
  • Works well with dynamic forms sale.order.ajax.
  • Supports mobile viewports and geolocation.

Cypress:

  • Runs in browser — more stable for SPA‑like interfaces.
  • Excellent visual runner for debugging.
  • Limitation: only Chromium‑based browsers.

PHPUnit for custom code:

  • Unit tests for custom Bitrix components and modules.
  • Tests business logic without frontend dependency.
  • Integration with CI/CD — GitLab CI, GitHub Actions.

UAT – Acceptance Testing

Final check with the client on a staging environment with real data:

  • Jointly compile a list of critical scenarios — 15–20 key customer paths, not 200 test cases.
  • Staging with a copy of the production database (anonymized personal data).
  • Quick bug tracking — Jira/YouTrack, prioritization by severity.
  • Acceptance protocol — document with results, signatures, and launch readiness.

Order UAT support and we guarantee a release without surprises.

QA Process – Integrated, Not Tacked On

  1. Requirements analysis — QA participates in task discussions, catches ambiguities. “Does the discount apply to the product or the order?” — such a question upfront saves two days of debugging.
  2. Test cases before development — scenarios ready before the first line of code.
  3. Code review — checks for typical Bitrix mistakes: uncleared component cache, direct SQL queries instead of ORM, missing $USER‑>IsAuthorized() check.
  4. Functional → regression → deploy.
  5. Post‑release monitoring — errors in bitrix/error.log, metrics in Metrica, alerts for 500 errors.

We have been working with Bitrix for over 10 years and have tested more than 300 projects of various scales — from small online stores to corporate portals with 1C and Bitrix24 integration.

Timelines

Task Duration
Test plan 2–3 days
Functional testing (medium store) 3–5 days
Basic E2E auto test suite (Playwright) 2–3 weeks
Load testing + report 1–2 weeks
Cross‑browser testing 2–3 days
UAT support 3–5 days
QA process from scratch 3–4 weeks

Testing cost is calculated individually for your project. Get a free consultation — we will assess the scope within one business day and provide a preliminary estimate and test plan. Contact us to discuss your project and schedule a call.