Quick Answer
Custom odoo integration services typically use Odoo’s XML-RPC or JSON-RPC APIs to connect external systems, since these are the two primary methods Odoo exposes for programmatic access to data and business logic.
REST API access is available through Odoo’s newer web service endpoints and third-party modules, while webhooks handle event-driven integrations like real-time payment confirmations.
Most custom API integrations cost $6,000 to $20,000 and take 2 to 6 weeks, depending on how many endpoints and data types the integration needs to cover.
Introduction
Every Odoo integration eventually comes down to one technical question: how does data actually get from Odoo to the other system, and back. This guide answers that question directly, covering the specific technical methods Odoo supports and when each one fits.
It complements the broader picture in Odoo integration services and the guidance on hiring the right technical help in Odoo integration consultant. This guide goes one level more technical, covering the actual mechanisms behind custom integration work.
How Odoo Exposes Data for Integration
Odoo provides two primary programmatic access methods: XML-RPC and JSON-RPC, both of which allow an external system to read, create, update, and delete records in Odoo’s database remotely.
These have been Odoo’s core API mechanisms for many years and remain fully supported across current versions.
XML-RPC uses XML-formatted requests and responses, and it’s the more established of the two methods, with broad language support since XML-RPC libraries exist for virtually every programming language.
JSON-RPC works similarly but uses JSON formatting instead, which many developers find more convenient to work with given JSON’s prevalence in modern web development.
Both methods require valid Odoo user credentials or an API key, and both operations run subject to the same access rights and security rules that apply to a regular Odoo user session.
This means an integration can only do what the API user account is permitted to do, which is an important security consideration when setting up integration credentials.
REST API Access
A true REST API in the conventional sense is not Odoo’s native architecture, since Odoo was built around XML-RPC and JSON-RPC rather than REST principles from the start.
Businesses specifically wanting REST-style access typically achieve this through community or third-party modules that wrap Odoo’s native RPC methods in a more REST-like interface, or through custom development that builds REST endpoints on top of Odoo’s controller framework.
Confirm which approach a specific integration project actually needs before assuming REST access exists natively. Many integration requirements are fully served by JSON-RPC directly, without needing an additional REST wrapping layer.
Webhooks and Event-Driven Integration
Webhooks allow an external system to notify Odoo, or Odoo to notify an external system, when a specific event occurs, rather than requiring the other system to repeatedly check for changes.
This is particularly useful for real-time scenarios like payment confirmation, where waiting for a scheduled check would introduce unacceptable delay.
Odoo’s core does not include a universal, built-in webhook framework for every possible event, so webhook-based integration frequently involves custom development, either building outbound webhook calls triggered by specific Odoo automation rules, or building an inbound endpoint that receives and processes webhook calls from an external system.
Payment gateway integrations commonly rely on webhooks specifically for confirming that a payment was successfully processed, since this confirmation needs to reach Odoo immediately rather than on a delayed polling schedule.
A well-built payment integration always includes proper webhook signature verification to confirm the webhook genuinely originated from the payment provider, rather than trusting incoming data without validation.
Common Custom Integration Patterns
CRM Sync Between Odoo and External Tools
CRM sync integrations connect Odoo’s CRM app with an external marketing or sales tool a business isn’t ready to fully replace with Odoo’s own CRM. This typically involves bidirectional sync of contacts and leads, using either scheduled polling through the RPC API or webhook-triggered updates for more real-time synchronization.
Conflict resolution deserves specific design attention in any bidirectional sync, since both systems can potentially update the same record independently. A clear rule, such as which system is the authoritative source for which specific fields, prevents sync conflicts from silently overwriting legitimate updates.
Payment Gateway Integration Patterns
Payment gateway integration generally involves two directions: sending payment requests from Odoo to the gateway, and receiving confirmation back through either a direct API response or a webhook callback. Building this correctly means handling not just the successful payment path but also failed payments, timeouts, and duplicate webhook deliveries that some payment providers send as a reliability measure.
E-commerce and Inventory Sync
Integrations syncing inventory levels between Odoo and an external storefront typically run on a scheduled basis using the RPC API, checking for stock changes at a defined interval rather than real time, unless the specific platform supports webhook-based stock update notifications. The right frequency depends on how quickly stock changes need to reflect across both systems to avoid overselling.
Choosing the Right Technical Approach
The choice between XML-RPC, JSON-RPC, a REST wrapper, and webhooks depends on what the external system supports and how real-time the data sync genuinely needs to be.
Most integration projects end up using JSON-RPC for standard data operations, supplemented by webhooks specifically for time-sensitive events like payment confirmation.
A skilled odoo integration consultant evaluates these options against the actual business requirement rather than defaulting to the most technically impressive approach. A simple, well-built JSON-RPC integration on a scheduled sync often serves a business better than an over-engineered real-time webhook system for data that doesn’t genuinely need instant updates.
Security Considerations for API Integration
API credentials should use a dedicated integration user account with access rights scoped specifically to what the integration needs, rather than a full administrative account.
This limits the damage a compromised credential could cause and makes it easier to audit what an integration is actually doing within Odoo.
Webhook endpoints receiving data from external systems should always validate the source, typically through signature verification the external system provides, before trusting and processing incoming data.
An unvalidated webhook endpoint is a genuine security risk, since anyone who discovers the endpoint URL could potentially send fraudulent data.
API credentials and webhook secrets should never be hardcoded directly into custom module code, and should instead be stored securely and referenced through Odoo’s configuration parameters or environment variables.
This matters both for security and for making credential rotation straightforward without requiring a code deployment.
Common Mistakes in API Integration Projects
Assuming REST API access exists natively without checking. Odoo’s core architecture uses XML-RPC and JSON-RPC, not REST, and assuming otherwise leads to scoping confusion early in a project. Confirm which access method a specific requirement actually needs before development begins.
Using an overly permissive API user account. A full administrative integration account creates unnecessary security exposure if credentials are ever compromised. Scope the integration user’s access rights specifically to what the integration genuinely requires.
Skipping webhook signature verification. An integration endpoint that trusts incoming webhook data without validating its source is vulnerable to fraudulent or malicious requests. Always verify the signature or authentication method the external system provides.
Not handling duplicate or failed webhook deliveries. Many external systems, particularly payment gateways, occasionally send duplicate webhook calls as a reliability measure. Build integration logic that handles duplicates gracefully rather than assuming each webhook call is unique.
Hardcoding credentials directly into custom module code. This creates both a security risk and a maintenance headache when credentials need rotation. Store credentials in Odoo’s configuration system or environment variables instead.
Who Needs This Level of Technical Detail
Developers and technical leads actively scoping or building a custom Odoo integration benefit most from understanding these specific mechanisms before development begins.
This technical grounding helps set realistic expectations with whichever consultant or team handles the actual build.
Business decision makers evaluating a quote for custom odoo integration services benefit from understanding enough of this technical landscape to ask informed questions, even without building anything themselves.
Knowing the difference between a scheduled sync and a webhook-driven integration helps clarify what a proposal is actually offering.
This level of technical detail matters less for a business still deciding whether they need custom integration at all, versus a pre-built connector covering their need. That earlier decision belongs in the broader Odoo integration services overview before this technical detail becomes relevant.
Frequently Asked Questions
Does Odoo have a native REST API?
Not in the conventional sense. Odoo’s core architecture uses XML-RPC and JSON-RPC, and REST-style access typically comes through third-party modules or custom development built on top of these native methods.
What is the difference between XML-RPC and JSON-RPC in Odoo?
Both allow remote access to Odoo’s data and business logic, with XML-RPC using XML formatting and JSON-RPC using JSON. JSON-RPC is often preferred by developers today given JSON’s prevalence in modern web development, though both remain fully supported.
When should an integration use webhooks instead of scheduled polling?
Webhooks fit scenarios needing real-time notification, such as payment confirmation, where delay would create a poor user experience. Scheduled polling through the RPC API suits data that doesn’t need instant synchronization, like periodic inventory level checks.
How do I secure an Odoo API integration?
Use a dedicated integration user account with access rights scoped to only what’s needed, validate webhook sources through signature verification, and store credentials in configuration settings rather than hardcoding them into module code.
Can Odoo sync data bidirectionally with an external CRM?
Yes, through the RPC API or webhook-triggered updates, though bidirectional sync needs clear conflict resolution rules defining which system is authoritative for which fields. This prevents simultaneous updates from silently overwriting each other.
What happens if a payment gateway sends duplicate webhook calls?
This is common practice among payment providers as a reliability measure, and integration logic should be built to handle duplicate deliveries gracefully rather than assuming each call represents a unique event.
Key Takeaways
Custom Odoo integration work centers on two native access methods, XML-RPC and JSON-RPC, supplemented by webhooks for time-sensitive, event-driven scenarios like payment confirmation.
REST-style access exists through third-party modules or custom development rather than natively, which is worth confirming early in any project scope.
Security discipline, scoped API credentials, webhook signature verification, and properly stored secrets, protects an integration from becoming a vulnerability rather than a convenience.
Choosing the right technical approach depends on genuine business need for real-time data, not defaulting to the most complex available option.
Confirm which specific API method your integration actually needs before requesting a technical scope from any developer.