When the invoice is in one system, the payment in a second and the stock in a third, employees copy data by hand. Integration turns that copying into a process. Each connection is estimated separately: we do not promise that “a ready-made connector exists”.

Free diagnostic Odoo: overview

JSON-2 APIWebhookFile exchangeSecurityMonitoring

Areas

Five areas: which systems Odoo talks to

Each area has its own page. It describes the requirements in Uzbekistan, what is in standard Odoo and what additional work is needed.

Electronic documents and tax

Electronic invoices and operators, electronic digital signature, IKPU (MXIK) code, online cash register, electronic waybill. This is where most local requirements are. Details →

Payments and banking

Click, Payme and other payment services, bank statement, matching a payment to an invoice, fiscal receipt. Details →

Messaging channels

Telegram, WhatsApp, SMS, email and social networks: customer notifications, internal messages, inquiries. Details →

Marketplaces and delivery

Local marketplaces, stock and order synchronization, delivery services and couriers. Details →

External systems and equipment

Data exchange and migration with amoCRM, MoySklad, 1C, Excel, cash register hardware, scanner, scales, biometric attendance. Details →

Connection methods

Six ways to connect to Odoo

The method determines how quickly the connection is ready, who maintains it and which hosting it runs on. We make the choice during the diagnostic, based on the requirements.

Method	What it does	When it fits	Limitation
File: import and export (CSV, XLSX)	Odoo loads records of any business object from a file. If there is an “External ID” column, reloading does not create a duplicate but updates the existing record	One-time migration; daily or weekly batch exchange	Not real time. A large file may hit the time limit: the documentation recommends splitting it into smaller parts
JSON-2 API	An external program calls a method of an Odoo model: reads a record, creates it, confirms an order	An external system has to write to Odoo or read from it; close to real time	Since Odoo 19. Depends on the subscription type. There are rules for keys, permissions and transactions
Webhook: Odoo sends a message	An automation rule sends a POST request with the selected fields when an event occurs. A trigger of the “External” type, in turn, receives an event from an external system	An external system needs to know right away what has changed in Odoo	The signature of an outgoing message is not described in the documentation. The incoming webhook address is secret (it is replaced with Rotate Secret). A misconfigured webhook can harm the database
A ready-made Apps Store module	A connector written by a third-party developer	The module fully matches your requirement and the author keeps updating it	Cannot be installed on Odoo Online. Depends on the version. Adapting to a new version may be delayed
A custom module that is safe to upgrade	Code that runs inside Odoo Enterprise: model, method, scheduled action	No ready-made solution exists or it falls short; hosting is Odoo.sh or your own server	Does not work on Online. Needs adapting for every new version
Middleware	A separate small program or integration platform between Odoo and an external system: converts the format, keeps a queue, resends on error	A complex connection on Odoo Online without a custom module; linking several systems	A separate server and monitoring are needed; someone must run it. This is a BUline recommendation, not an Odoo document

Odoo API

JSON-2 API: key, permissions, transaction and limits

Since Odoo 19.0 this is the official route for an external program. What follows is from the Odoo 20 documentation. Details: JSON-2 basics.

Item	Rule
Address	A POST request: /json/2/model/method. Model is the technical name of an Odoo table, method is the action (search, read, create, confirm). Parameters are passed in the JSON body, by name only
Key	Created in the user's settings: a description and a validity period are requested, and the key is shown on screen only once. The validity period does not exceed three months; a long-running key is replaced at least every three months
Permissions	Works with the permissions of the key owner. For a permanent connection, the documentation recommends creating a separate “bot” user. If its password is left blank, login with username and password is disabled
Database	If a server hosts several databases, the X-Odoo-Database header is added to the request
Transaction	Each call is a separate transaction: it is saved on success and rolled back on error. Several calls cannot be combined into one transaction, so related actions are gathered into a single method
Response and error	On success, 200. On error, 4xx or 5xx and an error object: name, message, arguments, context, debug. An invalid key returns 401
Document	The list of a database's models, fields and methods is on that database's /doc page. In the documentation this section is still marked “being written”
Subscription	According to the documentation, the external API is available only on the subscription type called “Custom”, and not on lower types. The exact terms are on odoo.com and in your contract: we check this at the start of the project
Call rate	Odoo's acceptable use policy describes roughly one call per second, without parallel calls, as acceptable for a non-sustained load. For large volumes, a separate mode is indicated on Odoo.sh

Legacy interface

XML-RPC and JSON-RPC: what has been removed and what will be

First, we find out whether there are any connections of the old type. They are often not visible on anyone's screen: for example, a nightly backup script. Deadlines follow the Odoo 20 documentation. Migration procedure →

Service	Status	Duration
Database service (db)	Removed	Odoo 20 (per the documentation: autumn 2026) and Online 19.1
Common and object services	Deprecated, removal planned	Odoo 22 (per the documentation: autumn 2028) and Online 21.1 (per the documentation: winter 2027)
JSON-2	Current route	From Odoo 19.0

Honest scope

What Odoo includes as standard and what we add

Most connections do not work out of the box. This is especially true of Uzbekistan's government systems and local payment services. The information follows the Odoo 20 documentation; if your version differs, we check it during the diagnostic.

Goal	In standard Odoo	Extra work (BUline)
File import and export	Available: CSV and XLSX; reloading with an external ID updates the record	Column mapping, cleaning rules, duplicate record checks
External API	Available: JSON-2 (since Odoo 19); rules for keys, permissions and transactions. Depends on the subscription type	Bot user, permissions, call sequence, error handling
Outgoing message from Odoo (webhook)	Available: the “Send Webhook Notification” action in an automation rule	The receiving side, signature verification, protection against a duplicate message: not described in the documentation
Government electronic invoice	No: the Uzbekistan localization documentation does not mention e-invoicing; Uzbekistan is not in the list of Odoo e-invoicing pages	Connecting to an operator is a separate project. Details →
Local payment services	No: among the 21 payment providers in the Odoo 20 documentation there is neither Click nor Payme	Testing a ready-made module, or building the connection from the provider's documentation. Details →
Direct synchronization with a bank	The documentation lists providers (Salt Edge: “the whole world”), and Uzbekistan's banks are not named; this is checked during the diagnostic. File import is available (CSV, XLSX, OFX, QIF, CAMT.053). Synchronization requires an Enterprise subscription	Converting the bank statement to the Odoo format, reconciliation rules
Retry on error	Partly: the Odoo server itself repeats a transaction that was interrupted by a conflict, up to five attempts in total (in the source code)	The queue, duplicate protection, log and alerts for exchange with the external system are built on the side of your connection
Ready-made connectors	Not in Odoo itself: modules on the Apps Store that depend on their author	Selection, code review, testing, update plan. Checklist →

Hosting

How the hosting type limits an integration

We settle this question at the start of the project, because changing hosting later may require rebuilding the connection. Hosting types →

Odoo Online

Odoo runs the server and backups
Not compatible with custom modules and Apps Store modules; settings that do not require writing code work
The integration is built outside Odoo: an external program connects through JSON-2, or Odoo sends a webhook
A database on a major version must be upgraded once every two years

Odoo.sh

Odoo manages the platform, you manage the code: branch, build, staging
Custom and third-party modules can be installed
On upgrade, every module must be adapted to the new version, otherwise the database waits
The usage policy mentions a separate mode on Odoo.sh for high-volume calls

Your own server

Modules, backups, security and upgrades are your responsibility
The freest route: any custom connection is possible
Suitable if there is a strict requirement on where data is stored
We agree in writing at the start of the project who will run the server

The BUline Method

An integration project: five stages

The stages follow the general BUline Method. The timeline is agreed in writing after the diagnostic. Implementation process →

01Requirements and estimateDiagnostic, 1–2 weeks

Which system, which data, in which direction and how fast it is exchanged. The provider's documentation is reviewed, and the Odoo side (standard, Studio or module) and the hosting type are checked. Result: an integration item in the business requirements document (BRD).

02Data map and architectureArchitecture, 1–3 weeks

A field-by-field table: which field comes from where, in what format, and which system is the master. The method is chosen: file, API, webhook, module or middleware. Error paths, permissions and the key owner are documented.

03Build and verification in a test databaseImplementation, 8–16 weeks

The connection is developed on a copy of Odoo. The test database is opened with external actions disabled. The provider's test mode is used. Edge cases are tested: a duplicate message, an interruption, incorrect data.

04Go-liveWithin implementation

First on one flow or one branch with real data (pilot), then on the rest. Keys for the production database are issued separately. Acceptance testing is carried out with the customer.

05Monitoring and ongoing support30 days + ongoing

After launch, 30 days of intensified support, then agreed ongoing assistance. The log, alerts and the key expiry calendar are in operation. When Odoo or the provider is updated, the connection is tested again.

Security

Key, data and signature: what we protect

A connection key must be treated like a password: whoever gets hold of it can act on behalf of the user. Storing keys →

Key and permissions

A separate bot user and a separate key for each connection; the connection name goes into the key description
Permissions only for the models and actions needed: the key cannot do more than its owner
A new key is created first, and the old one is revoked once every service has switched to it
The key is not written into code, email or a shared chat. Permissions →

Network and data

The debug field in the error object is not passed outside; it is written to the internal log (a BUline rule)
The test database is neutralized: emails, payments and delivery orders do not go out
Article 27¹ of the personal data law requires biometric data, genetic data and the data of telecommunications operators' users to be stored on the territory of Uzbekistan. Details →

External service side

The electronic signature key is not shared between employees: the law requires the owner to take all measures to keep the private key secure, and in a legal entity the head is responsible
Card data is not stored openly on your server: Payme's documentation strictly forbids it, and Odoo creates a payment token when tokenizing
Receiving endpoints (for payments and messages) are protected and work only with the verification described in the provider's documentation

Retry on error

What we do on error: a table of situations

No response does not mean the request was not executed. The HTTP standard (RFC 9110) does not recommend automatically resending a non-idempotent request unless its idempotency, or the fact that the original request was not applied, is known. A JSON-2 call is a POST: a check is needed before resending. Idempotency →

Status	What it means	What we do
401: invalid key	The key is wrong or has expired	We do not retry. We send an alert and the key is replaced
Other 4xx: error object	A data or permission error; resending does not change the result	We write the name and message fields to the log, put the record on the “failed” list, and the responsible employee sees it
500, network interruption, no response	The request may or may not have been executed	First we check by external ID whether the record exists, then resend with an increasing delay
Two processes changed the same record	The Odoo server repeats the action itself, up to five attempts in total (in the source code)	The integration is also ready for this error: it retries after a short interval
The webhook message did not arrive or arrived twice	The sender may resend or may not send at all	Each message is processed only once, by its identifier. Once a day we compare the two systems through the API
The external service was temporarily unavailable	The provider's server does not respond	Records are kept in a queue and sent in order once the service recovers; after a set period, a signal goes to a person

Monitoring

How we know the connection is working

The most dangerous fault is a silent one: the connection stops, nobody notices, and a few days later the figures no longer match. That is why we build monitoring together with the connection and do not leave it for later. Odoo's upgrade documentation also lists testing connections with external programs in a test database.

A log table: for every call, the time, direction, document identifier and status
A list of failed records inside Odoo: the responsible employee reviews and corrects them
An alert through Telegram or email to the responsible employee
A key expiry calendar: a replacement date is set ahead of the three-month limit
Daily comparison: the number and totals of documents in Odoo and the external system are checked through the API
The connection is tested again on a test upgrade of Odoo and when the provider changes

—

Honest scope

What we estimate and connect, and what we do not promise

An integration commitment rests on the provider's documentation, the Odoo subscription and the hosting type. We do not say “it will connect” without having examined them.

We estimate and connect

Connections via Odoo JSON-2 and webhook
File exchange and import rules
Connections where the provider has open documentation
An Apps Store module: selection, code review, testing

Estimated separately each time

Government systems: an operator, a cash register tool, documentation and a contract are required
Local payment services: a contract and a test environment are needed
Hardware: depends on the model and driver
Marketplace: API availability is confirmed with the provider

We do not promise

The claim “a ready-made connector exists”
A capability that is not in the provider's documentation
A solution that needs a custom module on Odoo Online
An API that the subscription type does not allow

Preparation

What to gather before we start

This list speeds up the diagnostic. We can start even if not everything is ready.

Systems

A list of the systems to connect and the owner of each
Current connections, including old XML-RPC scripts

Data

Which fields are exchanged and which system is the master
Codes: IKPU (MXIK), barcode, internal item number

Contract and permission

A contract and a test environment with the provider (operator, bank, payment service)
The owner of the electronic signature keys
Whether your subscription type includes the external API

FAQ

Frequently asked questions

Can any program be connected to Odoo?

Technically, most can be connected through JSON-2 or a file. But it depends on three things: whether the external system has an open interface, whether your Odoo subscription provides the external API, and which hosting type you have. In the diagnostic, each connection is estimated separately.

Can integration be done on Odoo Online?

Yes, but without a custom module inside Odoo. An external program connects through JSON-2, or Odoo sends a webhook; in a complex case, middleware is built. Custom and Apps Store modules are not compatible with Online. Odoo Online →

What happens to our connections written in old XML-RPC?

The database service was removed in Odoo 20, and the other two services are planned for removal in Odoo 22 and Online 21.1. We will list them and plan the move to JSON-2 together with the version upgrade.

Does an integration make upgrading the database harder?

The database is not upgraded until custom and third-party modules are adapted to the new version. If the external system connects through JSON-2, there is less dependency, but the connection must still be tested in a test database at every upgrade.

Webhook or API: which one do we choose?

If an external system needs to be told right away about a change in Odoo, use a webhook. If an external system needs to read from Odoo or write to it, use the API. Often both are used together: the webhook gives the signal, and the API checks the state. Webhook →

Does BUline need access to our keys?

The key is created under a bot user in your Odoo database and is limited in time. It is replaced when the work is finished. An NDA is signed on your request, and the scope and results are set out in a written contract.

How much does the service cost and how long does it take?

The Odoo license depends on the number of users and apps (terms on odoo.com); the external API is available only on some subscription types. The scope of BUline's services depends on the number and complexity of connections, users, branches, apps, customization, data volume and training. The exact cost and timeline are given in a written proposal after the free diagnostic.

Sources

Data sources

Odoo

Related sections

BUline servicesBUline servicesImplementation, integration, training BUline servicesIndustries13 areas, 109 industries BUline servicesElectronic documents and taxE-faktura, e-signature (ERI), MXIK, cash register, waybill BUline servicesPayments and bankingClick, Payme, bank statement, fiscal receipt

← PreviousTransport and logistics Next →Electronic documents and tax

Free diagnostic

Let’s decide together which Odoo apps to start with

During the diagnostic, we review your processes and tell you where standard Odoo is enough and where configuration is needed — with an app list, edition and phases.

Submit a request Message us on Telegram OR CALL US+998 77 275 36 15

Free diagnostic

Savdo

Ombor va ishlab chiqarish

Boshqaruv

Texnologiya

Oʻzbekiston

BUline bilan

Ilovalar

Platforma

Oʻzbekiston uchun

BUline bilan

BUline xizmatlari

Savdo va avtomatlashtirish

Aloqa kanallari

Nazorat va AI

Integratsiyalar

BUline bilan

Asoslar

Yoʻnalishlar

Amaliyot

Strategiya va kontent

Reklama kanallari

Organik oʻsish

Oʻlchov va analitika

Savdo va mijozlar

Operatsiyalar

Ichki ish

Tamoyillar

Продажи

Склад и производство

Управление

Технологии

Узбекистан

С BUline

Приложения

Платформа

Для Узбекистана

С BUline

Услуги BUline

Продажи и автоматизация

Каналы связи

Контроль и AI

Интеграции

С BUline

Основы

Направления

Практика

Стратегия и контент

Рекламные каналы

Органический рост

Измерение и аналитика

Продажи и клиенты

Операции

Внутренняя работа

Принципы

Sales

Inventory and manufacturing

Management

Technology

Uzbekistan

With BUline

Apps

Platform

For Uzbekistan

With BUline

BUline services

Sales and automation

Communication channels

Control and AI

Integrations