The key points
- List the data that moves, in which direction, and how fresh it must be.
- The ERP stays the source of truth for prices, stock and invoices.
- Your ERP's API, not the website, usually decides what is possible.
- Failed syncs need an owner and an alert, not a silent log file.
What data should flow between a website and an ERP?
Only the data a customer or salesperson actually needs on the website, and nothing more. For most manufacturers that's a short list: products and stock, customer-specific prices, orders going in, and status, invoices and documents coming back out.
Picture a distributor's buyer logging in at seven in the morning to reorder bearings. They want to see whether the part is in stock, what their contract price is, and when the last order shipped. Every one of those answers lives in the ERP. If the portal shows yesterday's stock or the list price instead of their negotiated price, they phone your sales office anyway, and the portal has saved nobody any time.
Write the list down as a table before anyone talks about tools: each data item, which direction it moves, how fresh it has to be, and who's affected if it's wrong. That one page settles most of the arguments that come later.
- ERP to website: product master data, stock or availability, customer price lists and discounts, credit status
- Website to ERP: new orders, quote requests, new customer or delivery-address requests
- ERP to website, after the order: order confirmation, dispatch status, tracking, invoices and credit notes
- Usually not needed online: full accounting ledgers, payroll, production schedules
Which system should be the source of truth?
The ERP, for anything financial or operational: prices, stock, customers, orders and invoices. The website is a window onto that data and a way to submit new requests, not a second database that people edit.
Problems start when both systems can change the same thing. A sales rep updates a customer's delivery address in the ERP, the customer updates it differently on the portal, and the next sync overwrites one of them. Decide field by field which side wins. Product marketing content (long descriptions, photos, application notes) is the common exception: it often lives in the website's CMS or a product information system, because ERPs are poor at storing it.
What are the main ways to integrate a website with an ERP?
There are four patterns, and most real projects use one main pattern plus a fallback; the table further down compares them. The right one depends less on your website than on what your ERP version exposes and how much your process differs from the standard.
What does each common ERP offer for integration?
It varies by product and, just as much, by edition and hosting. Check the documentation for your exact version before trusting any proposal.
Microsoft Dynamics 365 Business Central publishes a REST API (version 2.0) covering entities such as items, customers, sales orders and sales invoices. Oracle NetSuite offers SuiteTalk, including REST web services, alongside its SOAP interface and scripting. Odoo exposes an external API that lets other systems read and write its records. SAP Business One provides a Service Layer for web-style integration, though older on-premise installations sometimes rely on its DI API instead. In India, TallyPrime is common among manufacturers and distributors, and Tally documents integration through XML, JSON and ODBC.
Two warnings from real projects. First, an on-premise ERP in a server room has to be reachable securely from the internet, or you need a small agent or middleware inside your network. Second, heavily customized ERPs often store the thing you care about (a customer-specific price rule, a special unit of measure) in custom fields that the standard API doesn't expose. Find those early.
How often should the website and ERP sync?
As often as the business consequence demands, and no more. Orders going into the ERP should move within minutes. Stock for fast-moving parts may need near real-time checks. Product descriptions can sync overnight.
A useful middle path is a scheduled sync for the catalog plus a live lookup for the two or three numbers that change fast, such as stock and the logged-in customer's price, at the moment the page or cart loads. That keeps the ERP from being hammered by every page view while still showing a buyer the number they'll actually be invoiced.
What goes wrong, and how do you plan for it?
Syncs fail. The ERP is down for an update, a product code is missing, a customer's credit is on hold, or an API limit is hit at month end. The question is whether anyone notices before the customer does.
Build in the boring parts from day one: a queue so orders are never lost when the ERP is unavailable, retries with a limit, a clear error message to the buyer when something can't be confirmed, and an alert to a named person when a record fails. Keep a log you can search by order number. And agree who fixes what, because a failed sync at a manufacturer is usually a data problem (a missing price, a blocked customer) rather than a code problem.
How should the connection be secured?
Give the integration its own account with the minimum permissions it needs, never a staff login. Use the ERP's supported authentication (OAuth or API keys, depending on the product), keep credentials in a secrets store rather than in code, and encrypt traffic end to end.
Limit what the portal can ask for. A customer should only ever be able to retrieve their own prices, orders and invoices, and that check belongs on the server, not in the browser. Price lists are commercially sensitive; one badly scoped endpoint can hand a competitor your whole discount structure.
ERP integration patterns compared
| Pattern | How it works | Good fit | Watch out for |
|---|---|---|---|
| Ready-made connector | A plugin or app that links a specific e-commerce platform to a specific ERP | Standard processes on popular platform and ERP pairs | Breaks or limits you when your pricing or ordering rules are unusual |
| Middleware or iPaaS | An integration platform maps and moves data between systems | Several systems to connect, a team that wants visual mapping | Another subscription and another place for errors to hide |
| Custom API integration | Code written against the ERP's API, often with a queue | Customer-specific pricing, complex rules, live lookups | Needs ongoing maintenance when either system upgrades |
| File or EDI exchange | Scheduled exports and imports, or EDI messages with trading partners | Older ERPs, large customers who already order by EDI | Delays between runs, and silent failures if files stop arriving |
How to plan a website-to-ERP integration
Map the data
List every data item, its direction, its required freshness and its owner. Mark which fields must never be edited outside the ERP.
Check what your ERP exposes
Confirm the API or interface available for your exact edition and hosting, including any custom fields and rate limits.
Choose the pattern
Pick connector, middleware, custom API or file exchange based on the map and the ERP's limits, not on what the website platform prefers.
Design for failure
Add queuing, retries, alerts and a searchable log. Decide who is notified and who fixes data errors.
Test with real records
Run real customers, price rules and awkward orders through a test company or sandbox before go-live, not just sample products.
Launch with a fallback
Go live with a small group of customers first and keep the old ordering route open until the sync has been reliable for a few weeks.
ERP integration readiness checklist
- Do you have a written list of data items, directions and freshness?
- Is the ERP named as the source of truth for prices, stock and invoices?
- Have you confirmed the API for your exact ERP edition and hosting?
- Are customer-specific price rules stored in fields the API can read?
- Will orders queue safely if the ERP is unavailable?
- Is a named person alerted when a record fails to sync?
- Can each customer only ever see their own prices and documents?
Sources
Rules and guidance this answer relies on. Policies change, so check the current version before acting on it.