System Integration: Connecting ERP, Accounting, Shipping and Marketplaces into One Flow via API
If the order is in one place, the stock in another and the invoice in a third, a copy-paste loop is inevitable. System integration turns that chain into an automatic flow. We explain integration types, data flow design, error handling and a checklist for proper planning.
In brief: System integration means making separately running software (an e-commerce site, ERP, accounting/e-invoicing, warehouse, shipping, marketplaces, CRM, payments) share data automatically. The aim is to end entering the same information by hand again and again, reduce errors and see current and consistent data in every system. What makes an integration successful is not “making the connection” but a well-designed data flow: which system is the “source of truth” for which data, in which direction and how often does data flow, what happens when something fails, and who finds out? In this article we go step by step through integration methods, typical scenarios, error handling and a planning checklist.
Last updated: October 2026
The hidden cost of missing integration
In many businesses this picture is familiar: Orders land on the e-commerce site and the marketplaces; someone downloads them and types them into the ERP; stock is kept separately in a warehouse sheet; the invoice is issued in the accounting program; shipping details are entered from another panel. The result:
- Double and triple data entry (lost time)
- Stock inconsistency (selling items you do not have, showing items you do have as “out”)
- Wrong or late invoices and shipments
- Reports whose numbers do not match each other
- An operational load that grows as you grow
Most of these problems are solved by establishing an automatic and reliable flow between systems. To move out of a spreadsheet-based process, you can also read our moving from Excel to custom software article.
What is integration, and by which methods is it done?
There are several common integration methods:
| Method | How does it work? | Advantage | Watch out for |
|---|---|---|---|
| API (REST/SOAP) | One system sends requests to another through a standard interface | Flexible, instant, controlled | The other side's API must be adequate and documented |
| Webhook | When an event occurs (such as a new order), the system calls you automatically | Instant, efficient | Needs security (signature verification) and reprocessing of missed events |
| File-based (CSV/XML/FTP) | Files are produced and imported at certain intervals | Works with legacy systems | Delayed, hard to track errors |
| Database connection | Direct database access between systems | Looks quick to set up | High security and maintenance risk; generally not recommended |
| iPaaS / automation tools | Ready-made connectors with tools such as n8n, Make, Zapier | Quick start, low code | Scale, cost and complex business rules can be limiting |
| Custom integration (middleware) | A service you write connects the systems | Full control, complex rules | Development and maintenance load |
Practical rule: If the other system offers a solid API, use API/webhooks; if it only provides files, use files; for simple, low-volume jobs, an automation tool; if the business rules are complex and critical, a custom integration is more suitable. We compare automation tools and custom integration further below.
Typical integration scenarios
1. E-commerce ↔ ERP/accounting
- Orders are transferred from the e-commerce site to the ERP.
- Products, prices and stock flow from the ERP to the site.
- Invoices/delivery notes are produced from the ERP or accounting and linked to the order status.
2. E-commerce ↔ marketplaces
- Product information and stock are spread to marketplaces from a single center.
- Orders coming from marketplaces are gathered in the central system.
- Price and stock updates are managed so as to prevent overselling.
3. Order ↔ shipping/logistics
- When an order is ready, a shipping label is created automatically.
- The tracking number is written to the order and the customer is notified.
- Delivery status flows back into the system.
4. Accounting and e-invoicing
- Invoices are produced in line with e-invoice/e-archive requirements through the Revenue Administration portal or a private integrator, and matched with the ERP/accounting.
- Collections and account records are posted to the relevant system.
5. CRM ↔ other systems
- Form and order data are posted to the customer card.
- Sales and support history become visible in one place. For details, see our CRM system guide.
6. Warehouse and stock systems
- Receipt/dispatch movements and count results update the stock record instantly. Our inventory management guide is useful in this context.
7. B2B dealer portal
- Price, stock and account data flow from the ERP to the portal; orders flow from the portal to the ERP. For the details of the topic, see our B2B dealer portal article.
Design the data flow first, then make the connection
Determine the “source of truth”
Each data type should have a single authoritative system:
| Data | Typical source of truth | Why? |
|---|---|---|
| Product card and price | ERP or product management system | Managed from one place |
| Stock | ERP / warehouse system | Real movements occur there |
| Customer and account | ERP / accounting (and CRM) | Financial accuracy |
| Order | The channel that receives it → ERP | Record integrity |
| Invoice | Accounting / e-invoice system | A legal document |
Leaving a piece of data editable by hand in both systems creates conflicts. The rule is simple: data flows in one direction and is changed in the source system.
Data direction and frequency
- One-way or two-way? Two-way flow is more complex and requires conflict management.
- Instant or periodic? Stock and orders are usually instant or very frequent; the product catalog can be daily. Consider the business impact of delay.
- Batch or event-based? Batch for large data, event-based flow is preferred for critical events.
Data mapping
Systems give different names to the same thing: product code, barcode, SKU, stock code… There may be different units (piece/case), currencies, VAT rates and status names (“hazırlanıyor” / “processing”). Prepare the mapping table in writing from the start and have the business units approve it.
8 technical principles of a reliable integration
Integrations are easy on a “normal day”; the difference shows on days when things go wrong. These principles provide robustness:
- Retryability and queues: If the other system is temporarily down, the request must not be lost; it should be queued and retried.
- Idempotency: If the same order is sent twice, the second must not be saved again. Use a unique reference number.
- Error handling and alerts: Failed transfers should be visible in a panel and notify the right person; they must not vanish silently.
- Logging and traceability: Which order went to which system when, and with what result?
- Speed and limits: Respect the other APIs' request limits (rate limits); send bulk jobs in pieces.
- Version management: APIs change. Follow the other side's versioning policy; be ready for change announcements.
- Security: Store keys securely, do not put them on the client side, verify webhook signatures and share only the data needed. For details, see our web application security guide.
- A test environment: A sandbox where you can test without touching live data, and realistic test scenarios.
The 6 most common integration problems
| Problem | Cause | Precaution |
|---|---|---|
| The same order reached the ERP twice | No duplicate check on retry | Unique order reference + idempotent operation |
| An out-of-stock item was sold | Stock update is delayed or wrong | Update frequency, safety stock, sharing rules between marketplaces |
| The price looks different | Manual price changes in more than one place | A single source for price, one-way flow |
| Invoice/delivery note does not match | The order-invoice reference is missing | A common reference number, status mapping |
| Data silently disappears | No error logging and alerts | Queue, log, error panel, notification |
| The other API changed and everything stopped | Version and changes are not monitored | Contractual version tracking, monitoring, testing |
Ready-made tool or custom integration?
| Criterion | Ready-made connector / automation tool | Custom integration |
|---|---|---|
| Speed to start | Fast | Longer |
| Business-rule complexity | Simple to medium | Can be complex |
| Volume and scale | Low to medium | High |
| Cost structure | Subscription / per transaction | Development + maintenance |
| Control and flexibility | Limited | Full |
| Maintenance | Depends on the vendor | Your / the developer's responsibility |
A realistic approach: start with ready-made tools for low-risk, standard flows; strengthen flows that are critical to the business, high in volume or complex in rules with custom development. Always verify with a pilot whether a ready-made connector fits your business rules.
Planning checklist for an integration project
- Which systems will be connected? Does each have an API/file/webhook capability and documentation?
- Has the source of truth and direction been determined for each data type?
- Is the data mapping table (product code, unit, status, VAT…) ready?
- Have the need for instant/periodic flow and the acceptable delay been clarified?
- Are error, retry and notification rules defined?
- Is there a test environment and test scenarios (cancellation, return, partial shipment, zero stock, etc.)?
- Security: have keys, permissions and the scope of data sharing been determined?
- Have the other systems' vendors' API fees, limits and change policy been learned?
- Is the go-live plan (pilot, parallel run, rollback plan) ready?
- Has someone been assigned to monitoring and maintenance?
How do you measure success?
- Weekly hours spent on manual data entry
- Error and correction rate (wrong orders, invoices, stock differences)
- Average time from order to shipment to invoice
- Stock accuracy rate and number of cancelled orders
- Number of failed transfers in the integration and time to resolve
Measure baseline values before the integration; only then can you show the gain. The baseline-measurement method in our AI investment ROI article applies here too.
Integration projects with Aktaş Digital
We treat integrations not as “a small job that makes a connection” but as a system designed together with data flow and error handling: we first clarify the process and the source of truth, then develop API/webhook-based, queued and traceable integrations. We offer solutions for connecting your e-commerce, ERP, stock and operations systems to one another and adding a new face to them, such as a dealer/customer portal.
Related services: ERP systems, inventory tracking systems, B2B and B2C e-commerce platform, product and inventory management and warehouse management systems. If you describe your current systems and the flows you want to connect through our quote form, we will produce a first roadmap with a scope and cost breakdown.
Frequently Asked Questions
Does the other system have to have an API for integration?
An API is the healthiest route. If there is no API, file-based (CSV/XML) transfer, in some cases a ready-made connector offered by the vendor, or a third-party middleware layer can be used. Connecting directly to the database is generally risky and may conflict with the vendor's terms.
How long does an integration take?
It depends on the number of systems to be connected, the quality of the APIs, the complexity of data mapping and testing needs. A simple one-way flow can be set up in a short time; a multi-system, two-way, rule-heavy structure takes longer. A definite timeline requires analysis.
What is the biggest risk in stock sync with marketplaces?
Overselling (selling an item you do not have) because of delayed stock updates. Update frequency, safety stock and stock-sharing rules between channels reduce this risk.
Can I start with a ready-made automation tool and move to custom development later?
Yes; many businesses make a quick start and later move critical flows to a custom integration. But if you keep the data mapping and business rules in writing from the start, the move is much easier.
What happens if the other system changes its API?
A well-designed integration shows this quickly through error logs and alerts. Following the vendor's announcements and versioning policy should be part of your maintenance plan.
Is integration secure?
Done properly, yes: storing keys securely, limiting permissions, encrypted communication, signature verification and transaction logging are the basics. If personal data is shared, also take KVKK obligations into account.
Conclusion
A good integration is less about “connecting” systems than about giving data a single correct flow. Determine the source of truth and the data direction, prepare the mapping table, design for errors and retries, try real scenarios such as cancellation, return and partial shipment in the test environment and go live in a controlled way. The first thing you can do today: draw a flow diagram of where an order enters your systems, which paths it goes through and who enters data by hand at each step.
