Midoriweb develops ERP integrations for ecommerce and business applications. We can connect orders, customer records, products and operational updates around the rules your business actually uses. We work through the exceptions with you, so the connection has a clear response when information is missing, a record is rejected or a supplier service is unavailable.
Our Magento specialism is useful where commerce is part of the project, but the discussion extends beyond the storefront. We look at the complete handover between the website, ERP and the people who operate them.
ERP integration work we can deliver
Explore this area ↗Connecting a trade order without losing its meaning
Explore this area ↗Model the order lifecycle, not just order creation
Explore this area ↗ERP integration work we can deliver
We can scope new connections, extend an existing integration or investigate one that regularly needs manual correction. Work may include order exports, customer matching, product updates, agreed pricing information and status synchronisation, depending on the systems and supported interfaces.
We do not assume that every field should travel both ways. We help you decide which system owns each piece of information and how the other system should use it. That protects the business rules you depend on and makes the connection easier to support.
Where a connector or middleware product already meets much of the requirement, we can assess the remaining gaps. If custom development is appropriate, we define its responsibilities clearly. You should know which behaviour Midoriweb is delivering and which features depend on the ERP or another provider.
Connecting a trade order without losing its meaning
Consider a trade customer placing an order online with account-specific terms. The website and ERP need to agree on the customer identity, items and applicable commercial information. A successful transfer of a JSON payload does not establish that agreement.
We would map the relevant values, confirm which system makes each decision and test the resulting records. If the customer is not recognised or a product code is invalid, the order should enter a useful exception process rather than silently adopt a default that changes its meaning.
That is the detail we bring to integration work: not only moving data, but helping your team trust what arrived and understand what still needs attention.
Model the order lifecycle, not just order creation
Sending a new order is only one part of the process. The integration may also need to handle amendments, cancellations, partial fulfilment, returns or a rejected customer account. Different systems may use different statuses and may not allow the same changes at the same point.
We define how those states correspond and what happens when the expected transition is not available. That may involve an automated update, an exception queue or a task for a member of staff. It is better to identify a rule requiring human review than to automate an assumption that later produces incorrect records. The integration should support the lifecycle your business actually uses.
Map products, customers and prices carefully
A shared product code is helpful, but it does not remove every mapping issue. Variants, units of measure, customer-specific terms and inactive records can all affect how information should move. Tax and currency handling may also require agreement between the systems and your business processes.
We examine the relevant fields and representative records before finalising the mapping. Required values, transformations and rejected inputs should be documented. Where existing data contains inconsistencies, the project needs a decision about correcting it or handling it explicitly. An integration should not silently turn a data-quality problem into a larger set of mismatched records.
Choose a suitable synchronisation approach
Some updates need to arrive quickly; others can be processed in batches. The right approach depends on business urgency, the interfaces available and the limits of the connected systems. We assess these factors before recommending webhooks, scheduled jobs, queued processing or another supported method.
We also consider volumes and peaks. A connection that works during a small test needs to cope with a backlog after an outage or a larger import. Request limits, timeouts and the order of processing can affect that behaviour. The proposed design should explain how the integration catches up and how operators can see whether it is keeping pace.
Make failures visible and recoverable
External systems will occasionally reject information or become unavailable. A dependable integration needs to distinguish temporary failures from records that require correction. Retrying every error indefinitely can create noise; retrying an operation without checking its effect can create duplicates.
We plan controlled retries, useful status information and a way to reconcile the result. Where the receiving system supports it, identifiers and duplicate protection can help make repeated requests safer. Logs should provide enough context to investigate without unnecessarily exposing sensitive information. Your team should be able to identify an affected record and understand the next action.
Work with your ERP supplier and existing systems
ERP interfaces vary, and access to documentation or a test environment may require help from the supplier. We establish those dependencies early so that the project plan reflects them. We can work alongside your internal team or provider to clarify the supported integration route and the responsibilities on each side.
Existing middleware or connectors may already cover part of the requirement. We assess whether they can be configured or extended before assuming a complete custom connection is needed. Where custom development is appropriate, the scope should make clear which behaviours are delivered by Midoriweb and which remain the responsibility of the ERP or another service.
Test with business scenarios and reconcile before launch
Technical connectivity is an early check, not the final acceptance test. We use agreed scenarios that reflect your operations: representative products, customer types, order changes and failures. The test should establish that the resulting records mean the same thing to each system.
Before launch, we agree the treatment of existing records, any initial import and the changeover sequence. Post-release checks should confirm that expected updates are arriving and exceptions are visible. Handover can include the mapping, operational procedures and ownership of ongoing support, giving your team a practical basis for running the connection.
If you are still preparing the brief, our ecommerce integration planning guide can help you organise the systems, data and decisions to bring to the conversation. You do not need to resolve every technical detail before contacting us.
Questions about your ERP connection
Do you need our ERP supplier involved?
Sometimes. Documentation, a supported interface and access to a suitable test environment may require their help. We identify those dependencies early and can work with the supplier to clarify responsibilities.
Can you repair an existing integration?
We can assess the behaviour, code and available logs, then identify an appropriate correction scope. We may need to distinguish a mapping issue from a provider limit or a problem with the source data.
Can we connect only one process first?
Yes. An initial order or product flow can be a practical starting point if the surrounding rules are understood. We plan the boundaries so later flows can be added coherently.
Let’s talk about your project
Tell us which ERP and website or application you use, and where your team currently has to intervene. We will help you identify the connection that would make the most useful difference.