Helpful information ...
External Systems Integration Guide for Enterprises
A guide to integrating external systems for businesses
In brief:
- First, check whether your ERP supports API calls for writing orders, and define a single customer key.
- Successful integration is built on a phased rollout, testing, and monitoring critical system parameters.
First, check which API calls or export options your ERP actually supports, and define a single customer key, most commonly a tax ID. Once you know that, you have the foundation for every decision that follows. The goal of a successful integration is a single point of data entry: a customer and an order get entered once, and everything else syncs automatically.
Act immediately on these three steps:
- Get your ERP's API documentation and check whether the system supports writing orders (not just reading them).
- Set up a staging environment with anonymized data, separate from production.
- Define a phased plan: customers and basic data first, then orders, and finally accounting flows.
For this project, you'll need someone responsible in IT, a business contact who understands the operational processes, and an external integrator experienced with your specific ERP.
Table of contents
- Is integration the right decision for your business?
- Which technical integration methods are available?
- How does an integration project run, phase by phase?
- How to reconcile data between systems?
- How to test, monitor, and maintain an integration?
- Security and GDPR compliance in integration
- How much time and money does an integration project take?
- Templates and checklists for a fast start
- Moxy-web helps you from analysis to production
- Key takeaways
- What I've learned from integration projects
- Useful resources for further reading
- Frequently asked questions
Is integration the right decision for your business?
Integration pays off when at least one of these conditions applies to you:
- You sell through multiple channels (online store, B2B portal, physical retail) and the data isn't in sync.
- Your team manually transfers orders or stock between systems every day.
- Customers get incorrect information about availability or order status.
- You have B2B customers with individual price lists, discounts, or payment terms.
Don't start integration if your business processes are still non-standardized, or if you're planning to replace your ERP within the next six months. Automating poorly designed processes only speeds them up - it doesn't fix them.
Expert tip: Before deciding, run a short test: request test access to your ERP's API and check whether the system can handle writing orders. If it can't, a middleware database is probably the only realistic route.
Which technical integration methods are available?
Technical integration methods fall into three main approaches, each with its own advantages:
- Direct API (synchronous or asynchronous): the fastest response, suitable for real-time orders and payments. Requires a stable ERP and well-documented endpoints.
- A middleware database: the ERP and online store both write to a shared database that acts as a buffer. For high traffic or older ERPs, this approach reduces the risk of crashes and improves interface responsiveness.
- Batch file exchange (CSV, XML, EDI): suitable for data that doesn't change often, such as a product catalog or monthly settlements.
In practice, a hybrid architecture often works best: sync products and price lists overnight via files, refresh stock every 5-15 minutes through a middleware database, and route orders through the API in real time. This overview of integration types is also a useful reference for reviewing types of integrations in business systems.
| Method | Responsiveness | Complexity | When to choose it |
|---|---|---|---|
| Direct API | Real time | Medium to high | Orders, payments, statuses |
| Middleware database | a few minutes to a quarter hour | Medium | Stock, B2B price lists, older ERPs |
| File exchange | Hours to days | Low | Catalog, accounting, EDI |
Expert tip: When you check the API, immediately check the rate limits, whether the endpoints are encrypted (TLS), and whether the system supports write operations, not just reads.
How does an integration project run, phase by phase?
The integration process always follows the same logic, regardless of complexity:
- Process analysis: document which data flows between which systems and where errors or duplicate entries occur.
- Data mapping: determine which fields from the ERP correspond to fields in the store or CRM, and write down the rules for conflicts.
- Development in a test environment: develop every change on staging with anonymized test data, never directly in production.
- Integration testing: check individual scenarios (a new order, a cancellation, a stock change) and edge cases (an ERP outage, a duplicate customer).
- Pilot phase: roll out the integration for a smaller portion of traffic or for selected customers, and observe how it behaves under real conditions.
- Production and a rollback plan: before going into production, prepare a procedure for reverting. Document how to reproduce a bug and who's responsible for the rollback decision.
The recommended rollout order: first, align customer keys (tax ID), then one-way syncs for the most important processes, and only later two-way flows, once the processes are stable.
Expert tip: Prepare test data to cover every edge case in your business: B2B customers with individual price lists, orders with partial stock, and cancellations.
How to reconcile data between systems?

Without a single key, synchronization gets stuck on duplicate or mismatched records. A tax ID is the most common shared key for customers, SKU for products, and an internal order number for transactions.

| Entity | ERP key | Store key | CRM key | Note |
|---|---|---|---|---|
| Customer | Tax ID | Email / ID | CRM ID | Tax ID as the primary key |
| Product | SKU / code | SKU | Not relevant | Keep the original ERP SKU |
| Order | Order number | Order ID | Opportunity | Mapped through the middleware database |
| Payment | ERP document | Payment ID | Not relevant | One-way from ERP |
When importing existing data, run deduplication first: find customers with the same tax ID and merge them before starting synchronization. The rule for conflicts needs to be clearly written down: which system "wins" when the same record exists in two systems with different values.
Keep the original ERP identifiers as a reference in the middleware database. When an error occurs, you'll know exactly which record in the ERP is the source of truth.
Expert tip: Add meta-fields for business rules: customer type (B2B/B2C), allowed payment terms, default warehouse. These fields rarely exist in standard plugins, but they're essential for correct behavior.
How to test, monitor, and maintain an integration?
Testing isn't a one-time task. Your strategy needs to cover three levels:
- Unit and integration tests: check every API call and every data transformation individually.
- End-to-end scenarios: simulate the entire order flow, from entry in the store through to confirmation in the ERP.
- Failure behavior: what happens when the ERP is unreachable? Do orders get queued?
After launching in production, set up monitoring for these metrics: API call latency, the failed-sync rate, and the time since the last successful stock sync. Alerts should trigger whenever any metric crosses an agreed threshold.
For failed syncs, introduce a retry policy with exponential backoff: the first retry after 1 minute, the second after 5, the third after 30. After three failed attempts, the record goes to manual review. Reconcile stock and orders between systems weekly with an automatic report and human review of any discrepancies.
Expert tip: Connect integration monitoring with your business analytics. When you see a drop in store conversions, you'll immediately know whether the cause is a stock sync issue.
Security and GDPR compliance in integration
Any integration that transfers personal data needs to comply with the GDPR. In the Slovenian context, this means:
- All API calls run over TLS (HTTPS); never transfer data over unencrypted channels.
- Access tokens (API keys, OAuth tokens) are stored in a secure vault, not in configuration files.
- The principle of least privilege: the integration account only has access to the data it actually needs.
- Document the processing of personal data in your record of processing activities (GDPR Article 30) and arrange a data processing agreement with your external provider.
- Audit trails: log every data transfer with a timestamp, source, and destination. Your log retention policy should align with your industry's requirements.
Before going into production, run a security review: check that all endpoints are protected with authentication, that test data is anonymized, and that the integration account has minimal permissions.
Expert tip: Require a signed data processing agreement (DPA) from your external integrator before development starts, not after.
How much time and money does an integration project take?
Realistic expectations are key to project success. Timelines vary based on complexity:
| Type of integration | Duration | Typical resources |
|---|---|---|
| Simple (one system, one-way) | a few weeks | 1 developer, an IT contact |
| Medium (two systems, two-way) | a few months | Developer, analyst, IT, business |
| Complex (multiple systems, B2B rules) | several months | A team, external integrator, test environment |
Costs include development hours, possible ERP customizations (billed by the ERP vendor), middleware platform licensing, and post-launch maintenance. Simpler cases take a few weeks, while complex integrations require several months of planning.
- Internal IT: a significant share of project time for coordination, testing, and documentation.
- External integrator: essential for architectural decisions and building middleware layers.
- Business analyst or commercial contact: essential for validating business rules.
Expert tip: Include milestones in your contract with the integrator, with clear criteria for moving between phases. Without this, projects often drag on with no clear reason.
Templates and checklists for a fast start
Before talking to an integrator, prepare a technical specification. The required sections are:
- Scope: which systems, which data, which direction of flow.
- Entities and fields: a list of every entity with field mapping and conflict rules.
- API endpoints: URLs, methods, authentication, rate limits.
- Security requirements: TLS, token storage, audit trails.
- SLA and monitoring: agreed response times, alerts, procedures for outages.
A mapping checklist for every entity:
- Core fields and their value conversions (e.g. order status in the ERP ↔ status in the store).
- Handling missing values: default values, or reject the record?
- Merge rules for duplicate records.
Before going into production, check: test data covers your edge cases, the rollback procedure is documented and tested, a security review has been done, and monitoring is active.
Expert tip: Tailor these templates for each ERP individually. What applies to Pantheon doesn't necessarily apply to SAP Business One or Microsoft Dynamics.
Moxy-web helps you from analysis to production
Companies that take on integration without an experienced partner often spend months solving problems a good integrator would have anticipated in the first week. Moxy-web approaches every project by analyzing your ERP's actual capabilities, preparing a technical specification, and developing custom middleware layers that account for your specific business rules, not just standard plugins.
Ziga and the Moxy-web team have already carried out integrations of online stores with ERP systems, including complex B2B scenarios with individual price lists and multi-warehouse operations. Every project wraps up with a testing phase, documentation, and support after going into production.
Start with a free review of your ERP's API capabilities: get in touch through moxy-web.com and receive a feasibility assessment and a proposed project approach within a week.
Key takeaways
Successful integration of external systems requires first checking your ERP's API capabilities, defining a single customer key, and a phased rollout that starts with basic data and only later expands to orders and accounting flows.
| Point | Details |
|---|---|
| Start with an API review | Check whether the ERP supports writing orders before deciding on the architecture. |
| A single customer key | A tax ID is the most common shared key; without it, synchronization fails. |
| A phased rollout | Customers and basic data first, then orders, then accounting flows. |
| A hybrid architecture | API for orders, a middleware database for stock, files for the catalog, often works best. |
| Moxy-web | Analyzes ERP capabilities, prepares a technical specification, and builds custom solutions for Slovenian businesses. |
What I've learned from integration projects
Most integration projects don't fail because of the technology. They fail because nobody checked whether the ERP could actually do what the sales rep promised, or because the business processes were chaotic and automation just sped up the chaos.
Three lessons keep repeating: first, never start development before you have test access to the API and at least one successful test call. Second, a phased rollout isn't a sign of caution - it's the only way a team can actually adopt a new system. Third, communication between the client and the provider needs to be structured: a weekly progress review, clear responsibilities, and criteria agreed on in advance for moving between phases. Without this, projects drag on and costs climb.
Companies that treat integration as a strategic decision, not just a technical project, get results faster and with fewer surprises.
Useful resources for further reading
For IT teams and integrators:
- How to connect an ERP with external systems without replacing the ERP: a practical overview of integration methods from the perspective of the ERP's technical capabilities.
- When an API isn't enough: a middleware database as the more reliable solution: when and why to choose a middleware database over a direct API.
- Integration tailored to the business process: why standard plugins often aren't enough for complex B2B scenarios.
For business teams and project managers:
- Connecting online stores with ERP systems: the business impact of integration, and how accurate stock information increases customer trust.
- ERP systems and online stores: rollout recommendations: the recommended rollout order and why a gradual approach is key.
Integration succeeds when both sides understand it: IT knows what the system can do, and the business side knows which processes the system needs to support. Without this shared understanding, no technical solution works in the long run.
Frequently asked questions
What's the most important first step in integration?
Check whether your ERP supports API calls for writing orders, and define a single customer key, most commonly a tax ID. Without this, you can't plan your architecture.
When is a middleware database better than a direct API?
With older ERPs or high traffic, a middleware database reduces the risk of crashes and ensures the last known stock status, regardless of the ERP's availability.
How long does a simple integration take?
A simple one-way integration between two systems takes 2-6 weeks; more complex two-way integrations involving multiple systems require 2-6 months or more.
Which security requirements are mandatory?
All API calls need to run over TLS, access tokens need to be stored securely, and the integration account should only have minimal access permissions. A data processing agreement with the external provider is also mandatory.
How does Moxy-web help with integration?
Moxy-web analyzes your ERP's API capabilities, prepares a technical specification, develops custom middleware layers that account for your business rules, and provides support after going into production.
Recommended