Copy from one screen, key it into two more, and hope all three agree by Friday. When they don't, the discrepancy surfaces wherever it does the most damage. Real interfaces close that gap: APIs, pipelines, and queues that move the record once, retry when the far end is down, and raise a flag the moment they stop.
Each one is a point where two systems meet and a person fills the gap between them.
It arrives by email, goes into the ERP, then the WMS, then the customer's portal. Three chances to be wrong, and no one owns the difference.
Inventory says one number, the ERP says another, and everyone has a favourite. Nobody has ever written down which one is authoritative.
You found out today, from a customer. Nothing was watching the job, so a silent failure sat there quietly aging for a week.
Everyone does. The question is whether it exposes the fields you need, at the volume you need, without a per-call fee that ruins the case.
Written years ago, still running, still the most reliable thing you own. Nobody knows what happens the day the file arrives twice.
Someone exports from one system, tidies it in Excel, and imports it into the next. That is a scheduled job being run by a person.
Whatever the transport, three things have to hold: it retries, it can't duplicate a record, and a failure raises an alarm rather than waiting to be discovered.
A modern front door on a core that was never designed to have one.
Moving data out of the operational systems into somewhere you can query it.
The unglamorous half of integration: what happens when the other end is down.
Connecting the tools you already pay for, so nobody's job is copy-and-paste.
The first: you almost certainly do not need an integration platform. Five interfaces between systems you'll still own in ten years want five interfaces — not a hub, a canonical model, and a renewal date. We'll build the small thing, and we'll tell you where the threshold genuinely sits so you can spot it if you ever cross it.
The second: integration cannot settle an argument between two systems. Somebody has to name the system of record for inventory, for pricing, for the customer — and that call belongs to the business, not to the sync job. What we can do is put every conflict on one page, show who writes which field, and build the interface after the direction is decided rather than before.
Some partners will only ever send a PDF or an email. That's an extraction problem, not an interface problem — different tool, same goal.
A pipeline is only worth building if someone reads the result. Power BI and reporting are the reason most of these get funded.
Exception queues, mapping tables, and a replay button are custom software. Without them, every failure becomes a call to us.
Integrations are hard to describe and easy to recognize — the project write-ups show what we actually built and what it replaced.
Almost certainly not, and this is worth hearing before a licence gets signed rather than after. A hub starts earning its keep when endpoints arrive faster than anyone can name them — dozens of systems, new partners every month, somebody employed to keep the mappings current. Short of that, you have taken on a second platform to run on top of the interfaces you still have to write. Our preference is to write the interfaces and leave you nothing extra to renew.
No, and it is the ordinary case rather than the unlucky one. We work at whatever level the system honestly offers: a supported API if one exists, the database directly if it does not, a file interface it already produces, or in the worst case the same screens your staff use. The point is to put one documented boundary in front of it so everything downstream integrates with that boundary — which means the core can be replaced later without breaking every consumer.
Sometimes, and less often than people assume. A nightly file drop that runs every night beats a real-time interface that fails on Fridays, and plenty of processes genuinely do not care whether the data moved four seconds ago or four hours ago. Ask what decision the freshness changes. If nobody acts on it until morning, batch is not a compromise — it is the correct design, cheaper to run and far easier to re-run when something goes wrong.
Not on its own. Someone has to decide which system is authoritative for each piece of data — inventory, customer records, pricing, credit terms — and that is a business decision, not a technical one. We bring the conflicts to the surface, show you where each field is written and by whom, and build the sync once the direction is settled. Wire two systems together before that conversation and all you have done is spread the disagreement faster.
Related, but not the same job. EDI is integration with your trading partners over X12 or EDIFACT, with routing guides, certification cycles, and chargebacks attached — that has its own page, and it is deeper water. This page is about your internal systems and the SaaS tools you already own. If the work is WMS, TMS, or 3PL-specific, the logistics systems page is the better starting point. Plenty of projects touch all three.
Because something told you, rather than a customer. Every interface we build gets a heartbeat, a record of what it processed, and alerting on both failure and suspicious silence — a feed that normally carries two hundred orders and today carries none is also a failure. Messages that cannot be processed land in a dead-letter queue you can inspect and replay, and the replay is documented so your own team can do it without calling us.
Describe the handoff — what gets re-keyed, from where, to where. You'll get back the shape of the interface, what building it involves, and whether a nightly file would have done the job.
