Let's Build Your Next
Big Thing.
No spam. No pressure. Just a quick discovery call with our experts.
ERP API integration connects enterprise resource planning software with mobile applications, e-commerce platforms, Industrial IoT systems, customer portals, payment services and existing business software.
A reliable integration does more than transfer data from one database to another. It defines which system owns each record, validates every transaction, handles temporary failures, prevents duplicates and protects sensitive business information.
Direct answer: The safest ERP integration architecture uses a controlled API or middleware layer between the ERP and external systems. Use synchronous APIs when the user needs an immediate response, asynchronous queues for high-volume or failure-tolerant workflows, webhooks for event notifications and scheduled batch integration for non-urgent bulk data.
This guide explains how to design ERP API integration for Odoo, mobile applications, factory machines and legacy software.
ERP API integration is the controlled exchange of data and business actions between an ERP and another application through an application programming interface.
An API can allow an authorised application to:
The external application does not require unrestricted access to the ERP database. It receives only the information and actions permitted by the integration contract and authenticated user or system identity.
ERP software often becomes the central system for sales, procurement, inventory, manufacturing, accounting and workforce operations. However, employees and customers may use several other applications.
Common connected systems include:
Without integration, users repeatedly enter the same information into different systems. This creates delays, duplicate records, inconsistent stock figures and uncertainty over which system contains the correct information.
A maintainable architecture normally contains the following layers:
A simplified data flow is:
Mobile app, website or IoT platform → Secure integration API → Validation and business rules → ERP → Confirmed response or event
For factory integrations, the flow may be:
PLC or machine → Industrial gateway → IIoT platform → Integration service → ERP
Industrial devices should not normally communicate directly with the ERP database.
| Integration method | Best suited for | Advantages | Limitations |
|---|---|---|---|
| API request and response | Stock checks, login, order validation and user-driven actions | Immediate result and clear error response | Caller may be affected if the ERP is slow or unavailable |
| Webhook | Notifying another system when an event occurs | Reduces repeated polling | Requires secure delivery, retries and duplicate handling |
| Message queue | Orders, machine events and high-volume asynchronous work | Buffers demand and separates system availability | Adds operational and monitoring complexity |
| Scheduled batch | Daily masters, reports or non-urgent bulk updates | Simple for large, non-real-time transfers | Information is not immediately current |
| File exchange | Older applications supporting CSV, XML or fixed formats | Works when no modern API is available | Requires validation, secure transport and reconciliation |
| Direct database integration | Rare controlled read-only reporting scenarios | May provide fast bulk access | Can bypass ERP security and business rules; tightly coupled to database changes |
Direct database writes should generally be avoided. They can bypass validation, inventory rules, accounting logic, access controls and audit processes implemented by the ERP application.
In a synchronous flow, the external system sends a request and waits for the ERP or middleware to respond.
Use it when:
The application should use timeouts and should not wait indefinitely when the ERP is unavailable.
In an asynchronous flow, the request is accepted, assigned an identifier and processed separately. A queue can buffer transactions until the ERP is available.
Use it when:
Microsoft’s queue-based load-levelling pattern describes using a queue to buffer demand and reduce the impact of intermittent processing peaks.
If processing fails temporarily, the order can be retried without asking the dealer to submit it repeatedly.
Every important field should have one authoritative owner.
| Information | Typical system of record | Other systems |
|---|---|---|
| Customer master | ERP or CRM, according to the business process | Receive approved customer information |
| Product and price list | ERP | Display cached or synchronised versions |
| Inventory balance | ERP or warehouse-management system | Request or receive availability |
| Sales order | ERP after acceptance | Store external reference and status |
| Raw machine telemetry | IIoT or time-series platform | ERP receives selected events and summaries |
| Maintenance work order | ERP or maintenance-management system | Mobile app displays and updates assigned work |
| Mobile offline queue | Temporary local application storage | Synchronised with the authoritative backend |
| Accounting transaction | ERP accounting system | External systems submit approved source information |
When two systems can independently update the same field, the integration must define priority, conflict resolution and audit rules. Otherwise, each synchronisation can overwrite a valid change made by the other system.
Odoo 19 introduced the external JSON-2 API for accessing approved models and methods over HTTP.
The official Odoo 19 external API documentation describes:
/json/2 endpointOdoo states that external API access is available on Custom pricing plans and not on One App Free or Standard plans. Edition, subscription, hosting and deployment architecture must therefore be confirmed before selecting an integration method.
Odoo 19 documentation also states that the older XML-RPC and JSON-RPC external endpoints are scheduled for removal in Odoo 22, expected in 2028.
Businesses using older integrations should:
Custom Odoo controllers are treated separately from the external RPC deprecation notice. The correct migration path depends on how the existing integration was implemented.
A mobile application should normally connect to a purpose-built mobile backend or middleware API rather than exposing the complete ERP interface.
The mobile backend can:
Learn more about Tech4Lyf’s mobile app development services for ERP-connected field, factory and customer applications.
Industrial IoT systems generate a different type of data from normal business applications. A PLC or sensor may produce information every second, while ERP operates using manufacturing orders, maintenance requests, stock movements and quality records.
An integration layer should convert machine data into business events.
| Machine or IIoT event | Possible ERP action |
|---|---|
| Verified production cycle completed | Update the quantity associated with a manufacturing order |
| Machine fault persists beyond threshold | Create or prioritise a maintenance request |
| Digital measurement received | Populate an approved quality-check record |
| Energy summary completed | Associate an energy summary with a production period or costing report |
| Machine becomes unavailable | Notify production planning or maintenance |
Do not send every PLC tag directly to ERP. Keep high-frequency time-series data in the IIoT platform or historian and send validated transactions, exceptions and summaries to ERP.
Tech4Lyf’s smart-factory services cover PLC connectivity, industrial gateways, IIoT platforms and ERP integration.
Legacy software may not provide a REST-style or modern external API. It may support:
A legacy integration should isolate old formats behind a stable middleware interface.
For example:
Legacy application → File or legacy connector → Validation and transformation service → Modern ERP API
This prevents every modern application from needing to understand the legacy system’s internal format.
Idempotency means that retrying the same request does not create an unintended duplicate result.
Every important external transaction should carry a unique identifier. Before creating a new ERP record, the integration checks whether that identifier was already processed.
This is essential for sales orders, payments, stock movements, production entries and maintenance requests.
Temporary failures may justify a retry. The integration should wait between retries and impose a maximum attempt count.
Do not retry permanent errors such as an invalid product code or unauthorised user. These require correction rather than repeated processing.
If the ERP repeatedly fails, the integration should temporarily stop sending new synchronous requests instead of continuing to overload it.
The application can return a controlled status, queue appropriate work or inform the user that processing is temporarily delayed.
Messages that cannot be processed after the permitted retries should move to a separate error queue. Support teams can then inspect, correct and safely resubmit them.
A correlation ID follows a transaction across the mobile app, API, queue and ERP. It helps support teams trace the complete request without searching unrelated logs.
Integration monitoring should answer:
Successful HTTP responses alone do not prove that all business data is reconciled.
Most integration problems come from differences in how systems represent the same business information.
| Mapping area | Questions to resolve |
|---|---|
| Identifiers | Does each system use the same product, customer and machine code? |
| Units | Are quantities recorded in pieces, kilograms, metres or packages? |
| Dates | Which time zone and timestamp format are used? |
| Taxes | How are GST, HSN/SAC and tax-inclusive values represented? |
| Currency | Which currency and exchange-rate date apply? |
| Status | What do draft, confirmed, completed, cancelled and failed mean in each system? |
| Decimal precision | How are quantity, price and measurement rounding handled? |
| Null values | Is a missing value different from zero or an empty string? |
| Attachments | Where are files stored and how are permissions checked? |
Create a written data contract before development. The contract should define fields, types, required values, validation rules, examples and errors.
ERP APIs can expose customer, inventory, employee, pricing and financial information. Security must be applied to every operation and every record.
The OWASP API Security Project identifies risks including broken authentication, broken object-level authorisation, unrestricted resource consumption, security misconfiguration and unsafe consumption of external APIs.
A salesperson may be authorised to use the customer-order API, but that does not mean the salesperson can access every customer record.
The API must confirm that the authenticated user is permitted to view or modify the specific customer and order requested. Checking only that the user is logged in is insufficient.
ERP models, fields and workflows change over time. An integration that works today may fail after an ERP upgrade or module change.
A maintainable API process should include:
Do not make an unannounced field or status change in production. External applications may depend on the existing contract even if the change appears minor inside ERP.
Testing only the normal successful flow leaves the most expensive integration problems undiscovered.
Document the complete process, users, approvals and expected outcome. Do not begin by selecting endpoints.
Assign ownership for every master, transaction and status.
Confirm ERP version, hosting, subscription, authentication, available models, rate limits and custom modules.
Define request fields, response fields, validation, identifiers, errors and examples.
Choose synchronous API, webhook, queue, batch or a combination based on response-time and reliability requirements.
Define identities, roles, record permissions, credential storage, encryption, logging and revocation.
Create operational views for successful, pending, retried and failed records.
Test duplicates, timeouts, downtime, invalid records and recovery before production deployment.
Begin with one workflow, team, branch or machine group and verify business results.
Maintain architecture, field mapping, credential ownership, support procedures and upgrade dependencies.
Cost depends on workflow complexity and reliability requirements, not only the number of endpoints.
| Cost factor | Why it matters |
|---|---|
| Number of systems | Each platform adds authentication, mapping and testing |
| API availability | Legacy systems may require custom connectors |
| Data complexity | Products, taxes, units and statuses may require extensive mapping |
| Transaction volume | High volume can require queues, scaling and performance testing |
| Offline operation | Local queues, synchronisation and conflict handling are required |
| Security | SSO, certificate management and detailed permissions add scope |
| Attachments | Photos and documents need secure storage and transfer rules |
| Monitoring | Operational dashboards and alerts reduce long-term support risk |
| ERP customisation | Custom models and workflows require additional development |
| Upgrade support | Long-term maintenance and regression testing must be planned |
A reliable quotation should include discovery, implementation, security, testing, documentation, deployment and post-launch support.
Ask the provider:
The provider should understand the business workflow, not only API development. A technically successful connection can still create incorrect inventory or accounting records if ERP rules are misunderstood.
Tech4Lyf combines ERP implementation, Odoo development, mobile applications and Industrial IoT integration.
This supports projects requiring:
Read Tech4Lyf’s guide to unified ERP, IoT and mobile app architecture for a broader view of connected factory systems.
ERP API integration is the secure exchange of approved data and business actions between ERP software and external applications through an application programming interface.
Yes. A mobile backend can securely exchange approved data with Odoo. The exact method depends on Odoo version, hosting, edition, subscription and custom modules.
Yes. Odoo 19 introduced its external JSON-2 API. Odoo documentation states that external API access is available on Custom plans and not on One App Free or Standard plans.
Odoo 19 documentation states that its external XML-RPC and JSON-RPC endpoints are scheduled for removal in Odoo 22, expected in 2028. Existing integrations should be audited and migrated before removal.
Yes, but PLC information should normally pass through an industrial gateway and IIoT layer. ERP should receive validated business events and summaries rather than every raw machine signal.
A controlled mobile backend is normally safer and easier to maintain. It can protect ERP credentials, simplify data, apply mobile permissions and support offline synchronisation.
The integration should use timeouts, controlled retries and queues where appropriate. Users should receive a clear pending or failed status instead of unknowingly submitting the same transaction several times.
Middleware sits between systems and handles authentication, validation, transformation, routing, queues, error management and monitoring.
Direct database writes can bypass ERP business logic, access controls and audit rules. They also create tight dependency on the current database structure.
Assign every external transaction a unique identifier and design the integration to recognise previously processed identifiers before creating another ERP record.
Reliable ERP API integration begins with process mapping, data ownership and failure planning. Selecting an API technology before answering these questions often creates a fragile point-to-point connection.
Tech4Lyf can assess your ERP, mobile application, Industrial IoT platform or legacy software and design a controlled integration architecture.
Need to connect Odoo or another ERP with your business systems? Contact Tech4Lyf to discuss the workflow, systems and data involved.
