OdooBots
Loading
Integration · API

Odoo API integration

Most systems can be connected to Odoo, because Odoo exposes its entire data model over an external API rather than a curated list of endpoints. Anything you can do in the interface, a program can do too.

Which means the interesting questions are never "is it possible". They are what happens when the other system is down, which side wins when both change the same record, and who finds out when a message fails.

Karthik RajOdoo Technical Consultant, 10+ years| Reviewed by Arun Kumar| Updated 20 October 2026| Covers Odoo 16–19, Community & Enterprise
0Odoo projects delivered
0Consultants & developers
Any systemIf it has an API, it can connect
ChennaiAmbattur, Tamil Nadu

Businesses running Odoo with OdooBots

Dhanalakshmi Industries logo Sanjeev Autoparts logo Electro Flux Equipments logo Anchor Marine Equipment Company logo NEXG logo PV Constructions logo SESS logo
Definition

What is Odoo API integration?

Odoo API integration connects any system that can speak HTTP to Odoo’s external API, which exposes the full data model over XML-RPC and JSON-RPC. A call authenticates, then reads or writes records through the same ORM methods the interface uses — search_read, create, write, unlink. Outbound, Odoo can call another system when a record changes. The work is not the call; it is the field mapping, the conflict rules, the retries and the queue someone watches.

Because the API exposes the whole model, it is equally easy to build something fragile. An integration without retry handling, idempotency and a failure queue works in testing and diverges quietly in production.

XML-RPC / JSON-RPC
The two external endpoints Odoo exposes. Same capabilities; JSON-RPC is usually easier to work with.
External id
A stable reference linking an Odoo record to its counterpart elsewhere. The thing that makes re-running safe.
Idempotency
Running the same message twice without creating two records. Non-negotiable once retries exist.
Rate limit
How fast the other system will let you call it. Decides batching far more often than Odoo does.
What syncs

What moves between API and Odoo

Six things make up a custom integration, and only the first two are what people picture when they ask for one.

Reading records

search_read against any model with a domain filter and a field list, so an external system pulls exactly the records and columns it needs rather than everything.

search_readDomainsFields

Writing records

create, write and unlink through the same ORM the interface uses, so validation rules, computed fields and automations all still apply.

createwriteValidation

Authentication

Database, login and an API key rather than a user password, scoped to a dedicated integration user whose access rights are deliberately limited.

API keyScoped userRights

Outbound calls and webhooks

Odoo calling another system when a record changes, through automated actions or a custom module, with the payload and retry behaviour defined.

TriggersPayloadRetry

Bulk and batch

Large loads run in batches sized to the slower side’s rate limit, with checkpoints so a failed run resumes instead of starting again.

BatchingResumeCheckpoints

Error queue

Every message that failed, held with its reason and payload, replayable once the cause is fixed, with an alert when the queue grows.

ReplayReasonAlert
How it works

How a record travels between API and Odoo

The external system authenticates with an API key tied to a dedicated Odoo user, then reads or writes through the standard endpoints. Each record carries an external id so re-running a message updates rather than duplicates. A failure goes to a queue with its payload, an alert fires if the queue grows, and someone replays it once the cause is fixed.

That last part is what separates an integration that survives a year from one that quietly stops working in month three and is noticed at audit.

  • A dedicated integration user with deliberately limited access rights
  • External ids on both sides so a replayed message updates, not duplicates
  • Batch sizes set by whichever system has the tighter rate limit
  • Retries with backoff, and idempotency so a retry is always safe
  • A failure queue with the payload, an alert, and a named owner
Odoo api integration showing synchronised records between the two systems
Connected systems — how api and Odoo share one set of records.
Expertise · how we work

What we settle in week one of an Odoo API integration

These are the decisions that are cheap to make now and painful to reverse once two systems have been exchanging records for a month.

  1. Which system owns each field

    Decided field by field, not system by system. This is the whole integration, and every later argument traces back to it.

  2. The matching key

    Which identifier pairs a record on both sides, and whether it is stable. Matching on a name or an email is how duplicates start.

  3. Conflict rules

    What happens when both sides changed the same field since the last sync. Last-write-wins is a decision, not a default to drift into.

  4. Direction and trigger

    Push on change, pull on schedule, or both, and how often. This decides cost and load more than anything else.

  5. Rate limits and batching

    The slower system sets the pace. Designing for it up front avoids a rewrite when volume doubles.

  6. Authentication and scope

    A dedicated user with an API key and only the access rights the integration needs, never a shared administrator login.

  7. Failure handling

    Retry policy, the queue, the alert and the named owner. Agreed in week one, because nobody designs it after go-live.

Trust · honest advice

Where an Odoo API integration needs work

We would rather say this before you buy licences than after. These are the areas where we scope real development, recommend a different tool, or tell you the connector will not reach.

The other system’s API

Odoo’s side is rarely the constraint. What the other system exposes, how fast, and how well documented it is usually decides the scope.

Real-time guarantees

API integrations are near real time. A system that genuinely needs sub-second consistency needs a different architecture.

Very large volumes

Beyond a certain throughput this becomes a queueing and infrastructure question as much as a mapping one.

Legacy systems without an API

File drops or direct database reads are sometimes the only route. They work, and they are more fragile, and we will say so.

Version upgrades

A custom integration is code, so it is part of your upgrade scope. Building it as a proper module is what keeps that cost small.

Unmaintained integrations

The common failure is not a bad build. It is nobody owning the queue two years later, which is why the handover includes who watches it.

Our services

Our Odoo API integration process

Connecting API to Odoo is less about the connector than about agreeing what is true where, and what happens when a record will not go through.

  1. What you are connecting

    Understand which systems you are connecting, what their APIs expose, the volume and direction of data, and what has to happen when one side is unavailable.

  2. Field and direction mapping

    Agree the owner of every field, the matching key, conflict rules, trigger and batch size in writing, then build against that rather than discovering it in testing.

  3. Build and configure

    Connect API to Odoo using the standard connector where one fits, and build only what the connector genuinely cannot reach. See Odoo customization.

  4. Test with your own data

    Your records, in a test database, including the awkward ones — the cancelled order, the partial refund, the product that exists on one side only.

  5. Error handling and alerts

    A queue for failed records with a named owner and an alert, because an integration nobody watches diverges quietly and the divergence is found at audit.

  6. Go-live and monitoring

    Cutover with a reconciliation on both sides, then hypercare, then ongoing support and AMC.

Trust · what it costs

What an Odoo API integration costs

We do not publish one integration price, because the same connector costs very differently depending on the factors below. We do publish what moves the number, and the price is fixed in writing before work starts.

  • Number of systemsEach connected system is its own mapping, auth and failure path.
  • Field count and complexityTransformations and lookups cost more than straight copies.
  • The other API’s qualityA poorly documented or rate-limited API is the usual source of extra work.
  • Two-way versus one-wayBidirectional sync needs conflict rules and roughly doubles the testing.
  • Volume and frequencyHigh throughput needs batching, queueing and monitoring.
  • Error handling depthA replayable queue with alerting is real work, and it is the part worth paying for.
Why us

Why choose OdooBots for your Odoo API integration

We quote the error handling as a line item rather than hiding it, because that is the part that decides whether the integration still works in a year. Anyone can make the first call succeed.

Based inAmbattur, ChennaiTamil Nadu 600053, India
Phone+91 98414 81435Mon–Sat, business hours IST
Delivered630+ Odoo projects30+ consultants and developers
Versions supportedOdoo 16 – 19Community and Enterprise
FAQ

Odoo API integration: frequently asked questions

What is Odoo API integration?
Connecting another system to Odoo through its external API, which exposes the full data model over XML-RPC and JSON-RPC. A call authenticates with an API key and then reads or writes records using the same ORM methods the interface uses, so validation rules and automations still apply.
Which applications can be integrated with Odoo ERP?
Practically any system with an HTTP API: CRMs, ecommerce platforms, payment gateways, logistics and courier systems, accounting tools, business intelligence, marketing platforms, mobile apps and in-house software. Where a system has no API, file-based exchange is sometimes the only route and it is more fragile.
Does Odoo use REST, XML-RPC or JSON-RPC?
Odoo’s external API is exposed over XML-RPC and JSON-RPC rather than as a conventional REST API. Both give access to the same models and methods, and JSON-RPC is usually easier to work with. A REST-shaped wrapper can be built as a custom module where another system requires one.
Is Odoo API integration secure?
It is when configured properly: a dedicated integration user with an API key rather than a password, access rights limited to the models the integration actually needs, HTTPS, and credentials held outside the code. Using a shared administrator login is the common mistake and it is worth refusing.
Can Odoo API integration synchronise data in real time?
It is near real time rather than instant. Records typically move within seconds to a minute depending on the trigger and the other system’s rate limits. Anything needing genuine sub-second consistency needs a different architecture, and we would say so rather than promise it.
What happens when the other system is down?
Messages retry with backoff and then land in a queue with their payload and the reason they failed, with an alert when the queue grows. Because every message is idempotent and carries an external id, replaying it updates the record rather than creating a duplicate.
Will a custom integration survive an Odoo upgrade?
If it is built as a proper module against stable models, yes, with a review as part of the upgrade. Integrations that patch core behaviour or depend on internal details are the ones that break, which is why we build them as modules from the start. See Odoo migration.
Can you develop custom Odoo API integrations?
Yes, including two-way sync with conflict rules, outbound webhooks from record changes, batch loads with resume, and the replayable error queue that keeps the whole thing maintainable. See Odoo customization.
References

Sources and official documentation

Product capabilities stated on this page are documented by Odoo. The mapping advice, failure handling and limitations come from our own integrations.

Ready to connect API to Odoo?

Tell us which systems you want connected and whether the data has to travel both ways. Those two answers decide the scope, and the diagnosis call is free.