Developing D7 API Classes for 1C-Bitrix — Modern Approach

We integrate D7 API into Bitrix projects, creating classes with namespaces instead of global functions, Result objects instead of bool and error strings, and using Application as the entry point instead of global variables. Such code doesn't break on updates, is easily testable and reusable. Our exp

Our competencies:

Frequently Asked Questions

Latest works

  • image_website-b2b-advance_0.webp
    B2B ADVANCE company website development
    1454
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Website development for FIXPER company
    1018
  • 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
    760
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Development based on 1C Enterprise for MIRSANBEL
    879
  • image_crm_dolbimby_434_0.webp
    Website development on CRM Bitrix24 for DOLBIMBY
    803
  • image_crm_technotorgcomplex_453_0.webp
    Development based on Bitrix24 for the company TECHNOTORGKOMPLEKS
    1162

We integrate D7 API into Bitrix projects, creating classes with namespaces instead of global functions, Result objects instead of bool and error strings, and using Application as the entry point instead of global variables. Such code doesn't break on updates, is easily testable and reusable. Our experience: over 5 years working with Bitrix, over 30 projects fully migrated to D7. Get your project assessed — contact us!

Problems We Solve

Typical pains: legacy code using CModule and $_POST breaks on updates, can't be covered by tests, errors are lost (return false without context), and cache is invalidated only by time. D7 API solves this through strict typing, exceptions, and tagged cache. As a result, production errors decrease by 2–3 times, and time to deploy new features is reduced by 40%.

Why Migrate to D7 API?

Migrating to D7 API is not a trend but a necessity for projects that live longer than a year. Instead of CIBlockElement::GetList() with a ton of parameters, you get ORM queries with method chains. Instead of $_POST['field'] — a Request object with typed access. Your code becomes predictable and documented. Let's compare legacy and D7 code volume: for 1000 lines of legacy, D7 takes about 800 lines, but D7 code is 60% easier to maintain.

How We Develop D7 Classes

Let's take a real case: an e-commerce store on Bitrix with 50,000 products. The old basket code worked via CSaleBasket::Add and was scattered across templates. We rewrote it into a BasketService service class with D7:

namespace MyProject\Services; use Bitrix\Main\Result; use Bitrix\Main\Error; use Bitrix\Sale\Basket; class BasketService { public function __construct( private readonly int $userId ) {} public function addItem(int $productId, int $quantity): Result { $result = new Result(); $basket = Basket::loadItemsForUser($this->userId); if (!$basket) { $result->addError(new Error('Failed to load basket', 'BASKET_LOAD_FAIL')); return $result; } $item = $basket->createItem('catalog', $productId); $item->setFields(['QUANTITY' => $quantity]); $saveResult = $basket->save(); if (!$saveResult->isSuccess()) { $result->addErrors($saveResult->getErrors()); } return $result; } } 

Now the basket is fully covered by unit tests, and when Bitrix updates, you only need to replace one class, not rewrite all templates. This reduced update time from 3 days to 2 hours.

How D7 API Improves Caching

Tagged caching is one of D7's strong points. Instead of global cache flush by time, you invalidate only the data that changed. For example, when a product price is updated, only that product's cache is flushed, not the entire catalog. This reduces database load by 30–50%.

Architectural Patterns: Factories and Repositories

For complex logic, we use factories to create objects and repositories to work with storage. For example, an order factory creates Order instances with pre-filled dependencies, and a product repository encapsulates ORM queries with tagged cache. This approach isolates business logic from infrastructure and makes it easy to swap implementations during testing.

Our Process

  1. Audit current code — identify places using legacy API.
  2. Design architecture — define services, repositories, factories.
  3. Implement classes — write code with Result, Application, tagged cache.
  4. Write unit tests — cover critical scenarios.
  5. Integration and deployment — replace old modules piece by piece, maintaining backward compatibility.
More on development principles Each service class should be narrowly focused and responsible for one business operation. We use dependency injection via constructor, not through global functions. This makes code testable and replaceable.

What's Included

  • Full set of D7 classes (services, repositories, factories, Result objects)
  • API documentation in PHPDoc
  • Unit tests (on request)
  • Adaptation of existing code to work with new classes
  • Installation and maintenance instructions

D7 API vs Legacy API

Criteria Legacy API D7 API
Error handling return false Result with error array
Typing Mixed Strict (PHP 8.1+)
Testability Low (global functions) High (DI)
Caching TTL Tagged invalidation
Bitrix update Often breaks Compatible with new versions

Timelines

Task Timeline
Set of service classes for a single feature (5–10 classes) 1–2 weeks
Full service layer for a module (repositories, services, factories, Result objects) 3–5 weeks
Writing unit tests for ready classes +30–50% of development time

Code on D7 API lives long. It can be updated piece by piece, tested, and reused. Order turnkey D7 class development — we'll assess your project in one day. Guaranteed compatibility with latest Bitrix versions.

Learn more about D7 API in the official documentation and Wikipedia on PHP namespaces.

Contact us for a consultation — we'll help with the migration to D7. Get a commercial proposal and cost estimate within a day.