Custom REST Application Development for Bitrix24

A spare parts distributor was spending 30 seconds switching between 1C and Bitrix24, until we implemented a REST widget. A sales manager opens a deal, and in front of them are only the fields they filled in manually.

The accounting system holds three years of history, credit limit, claims, order archive. To view them, you have to switch between tabs, copy the ID, waste time. The data diverges — in the CRM one amount, in 1C another.

A REST application for Bitrix24 solves this problem: it embeds external information directly into the portal interface, through widgets and the REST API. We, certified Bitrix developers with ten years of experience, have implemented more than 50 such integrations.

The average savings on manual entry — cost calculated after audit. in a year. Every application is a well-thought-out architecture: from the OAuth flow to API rate limit handling. Get a consultation — we will assess your task.

How is a REST application structured in Bitrix24?

A REST application is an external web service that interacts with the portal via OAuth 2.0 and the REST API (https://domain.bitrix24.ru/rest/). The application can embed widgets into CRM cards, subscribe to events, and read and write data.

There are two types: marketplace (published in the Marketplace) and embedded (for a single portal). For corporate tasks, embedded ones are more often chosen — they are simpler, but do not scale to multiple portals.

We will help you determine the architecture, taking into account your business processes and the need for integration with 1C via CommerceML. The Bitrix24 REST API has more than 700 methods, which covers all CRM entities, tasks, calls, and business processes.

What data can be obtained through the REST API?

Through the REST API, all key entities are available: deals, contacts, companies, leads, invoices, quotes, tasks, calendars, calls, business processes (Bizproc). The methods allow not only reading but also creating, updating, and deleting records.

There is also access to custom fields and events. This makes it possible to build flexible integrations with any external systems — from inventory management to CRM.

Why is a REST application faster than custom scripts?

A custom script without caching and batch requests can be 10 times slower. A REST application uses tagged caching, reducing server load and widget response time to 1–2 seconds.

According to the official REST API documentation, support for batch requests reduces the number of calls. The official API supports events, which makes it possible to react to data changes in real time.

We implemented an application for a parts distributor: a widget in the deal card loads stock balances from 1C and credit history. Loading time was reduced from 30 seconds to 0.5 seconds thanks to the Redis cache.

Saving 30% of time is equivalent to cost calculated after audit per month. Such a solution pays for itself in an average of 3–6 months due to reduced manual input.

In detail: widget in the deal card

The most common scenario is embedding external data directly into the CRM. Registering a placement via the REST API:

// Called when the application is installed
$client->call('placement.bind', [
    'PLACEMENT' => 'CRM_DEAL_DETAIL_TAB',
    'HANDLER' => 'https://myapp.example.com/widget/deal/',
    'TITLE' => 'Customer history',
    'OPTIONS' => ['extraData' => 'ENTITY_ID'],
]);

When a manager opens a deal, Bitrix24 loads an iframe with your application's URL, passing ENTITY_ID?

The application:

1. Gets ENTITY_ID from placement.info()
2. Makes a REST request crm.deal.get to retrieve the contact/company ID
3. Uses the contact ID to access the internal accounting system
4. Displays purchase history, credit limit, open tasks

For reliability, we add error handling and retry on failures.

OAuth 2.0: authorization and token storage

When registering an application, the portal issues a client_id and client_secret. The user authorizes the application, and we receive an access_token (TTL 1 hour) and a refresh_token (TTL 30 days). We store tokens in encrypted form (AES-256) and automatically refresh them before every request:

class Bitrix24OAuth {
    public function refreshToken(string $refreshToken): array
    {
        $response = Http::post('https://domain.bitrix24.ru/oauth/token/', [
            'grant_type' => 'refresh_token',
            'client_id' => config('b24.client_id'),
            'client_secret' => config('b24.client_secret'),
            'refresh_token' => $refreshToken,
        ]);

        TokenStorage::save($response['access_token'], $response['refresh_token']);

        return $response;
    }
}

Typical mistakes in REST application development

• Insecure token storage: tokens in plaintext or in a database without encryption. Use AES-256.
• Ignoring API limits: without a request queue and retries, the application will be blocked. Configure a rate limiter on Redis.
• Lack of event handling: constant polling instead of subscribing to events creates unnecessary load.

What is included in the development of a REST application?

How is the work process structured?

• Analytics: we study your business logic, current processes, and accounting systems.
• Design: we agree on the architecture, stack, and API.
• Development: we build a REST application on PHP 8.1+ with v2.0 information blocks and ORM.
• Testing: we test the widgets in a test portal, load testing.
• Deployment and support: we install on the production portal, hand over documentation.

Contact us to discuss your project — we will assess the task and propose an architecture. We are ready to take on integration of any complexity: from a simple widget to a comprehensive solution with 1C, amoCRM, and other systems. Order REST application development — we will select the optimal solution for your task.