Start with the business and technical reality
An integration is part software and part operational process. APIs time out, files arrive late, identifiers do not match, users amend orders after export and upstream systems can be unavailable during critical periods. A reliable integration anticipates these conditions rather than treating the happy path as the complete specification.
We start by identifying systems of record and business events. For each flow we define what triggers it, which fields are required, how duplicates are prevented, what happens when validation fails and who needs visibility. That design work is often more important than the transport technology.
Where a manual process already exists, we can automate in stages so staff retain a clear exception route while confidence in the integration grows.
When clients bring us in
- Orders are copied manually between website and ERP
- Stock updates are delayed or inconsistent
- Supplier product files need repeated manual cleaning
- Marketplace data is managed separately from the main catalogue
- Shipment and tracking updates do not return to customers reliably
- Several point-to-point integrations have become impossible to understand
What good delivery should leave behind
A successful engagement should improve more than the immediate feature or incident. It should make the system easier to understand, safer to change and more visible to the people responsible for operating it.
- Clear technical ownership and responsibilities
- Maintainable code and configuration
- Visible failures rather than silent data loss
- Controlled release and recovery paths
- Documentation for future developers and operators
- A sensible next-step roadmap rather than permanent firefighting
Technical depth across the parts that matter
The exact scope depends on the existing environment and commercial priorities. We focus on the areas that materially affect reliability, maintainability and delivery rather than adding process for its own sake.
Data ownership
Agree which system is authoritative for products, prices, inventory, customers, orders and fulfilment.
Interfaces
Use APIs, webhooks, queues, SFTP/files or middleware according to source-system capability.
Validation
Reject or quarantine incomplete data before it damages downstream workflows.
Reliability
Design retries, idempotency, ordering and timeout behaviour for expected failure modes.
Observability
Log transactions and surface errors in a form that operational teams can act on.
Reconciliation
Provide a way to compare systems and recover missing or inconsistent records.
Common failure patterns that create unnecessary cost
Many technical problems are recurring patterns rather than isolated defects. Identifying them early helps avoid repeatedly paying to treat the visible symptom.
- Silent failures creating missing orders
- Duplicate records after automatic retry
- Stock races between warehouse and storefront
- Different systems using different customer or SKU identifiers
- Batch jobs that cannot resume safely after interruption
- No audit trail explaining why a record was rejected
A controlled route from uncertainty to production
We prefer visible, reviewable delivery. The exact sequence changes with the project, but the principle is to reduce uncertainty early and keep each production change understandable.
Technology is part of the answer, not the starting question
We are comfortable with REST and GraphQL APIs, webhooks, queues, scheduled jobs, SFTP/file transfer and database-driven workflows where appropriate. The transport is secondary to a clear integration contract and operational recovery model.
Where specialist capability comes from our wider engineering team, we are transparent about the proposed delivery model and match the person or team to the actual requirement rather than presenting a long list of technologies as if every project needs all of them.
Design for the day something fails
A useful integration specification should be able to answer a simple operational question: if this transaction fails at 3pm on a busy Monday, how does the business know, what state is each system in and what is the safe way to recover it? If the answer is “a developer checks the logs”, the integration is usually not complete from an operational perspective.
We therefore design dashboards, status fields, error queues or reconciliation reports where the volume and importance justify them. The objective is not to expose technical noise to business users; it is to make the small number of exceptions that require human intervention clear and actionable.
Useful information for an initial assessment
- Source and destination systems for each data flow
- System-of-record decision for each entity
- Expected transaction volumes and timing
- Available APIs, webhooks or file interfaces
- Existing manual recovery and reconciliation process
- Business owner for exceptions and failed transactions
Use the level of ownership that fits your team
Defined project
Midoriweb owns an agreed scope with clear milestones, acceptance criteria and release responsibilities.
Specialist workstream
Bring us into one technically difficult area while your existing team or agency owns the wider programme.
Team augmentation
Add developers to your existing process for a fixed period or an ongoing roadmap.
Ongoing technical partner
Combine support, maintenance, monitoring and planned improvement under continuing technical ownership.
Questions worth answering before work starts
Do all integrations need real-time APIs?
No. Real-time is useful when the business outcome requires it, but scheduled or queue-based processing can be simpler and more resilient for other flows.
Can you integrate systems that only support CSV or SFTP?
Yes. File-based integrations can be reliable if validation, sequencing, archival and retry behaviour are designed properly.
How do you prevent duplicate orders?
We use stable identifiers and idempotent processing so a safe retry does not create a second business transaction.
Can you add monitoring to an existing integration?
Often, yes. We can review the current flow and introduce logging, alerting and reconciliation around it.
Can you automate manual supplier feeds?
Yes. Product, price and stock files can be validated, transformed and imported with controlled exception handling.
Can you coordinate with third-party vendors?
Yes. Integration projects often require joint specification and testing with ERP, WMS or other software suppliers.
Continue exploring
Have a requirement in this area?
Send the current situation, desired outcome, platform or systems involved and any important deadline. We can review the detail first or discuss it in a short consultation.