Service
Custom API Middleware & Integrations
Two systems hold data that needs to be the same, and the thing keeping them in sync is a person with a spreadsheet. We build the small, unglamorous services that sit between them and remove that person from the loop.
The integration nobody sells you
Large platforms sell connectors for the pairings that are common enough to be worth productising. What they do not cover is your specific vendor's portal, your particular ERP version, or the internal tool somebody built in 2016 that the business now depends on.
That gap gets filled by a person. They export a CSV from one system, reformat it, and import it into another, every morning. It works, it is invisible in any process diagram, and it stops entirely when they are on holiday.
Middleware in this context is not a platform. It is a small service that does one transfer correctly, runs unattended, and is boring enough to forget about.
What separates a service from a script
The difference between a working script and something you can rely on is almost entirely in how it handles the unhappy path. These are the properties we build in, because retrofitting them later usually means starting over:
- Idempotency
- Running the same sync twice must not create two records. Every write is keyed so a retry is safe, which is what makes automatic recovery possible at all.
- Bounded retries with backoff
- Transient failures are normal. A retry policy that gives up eventually — rather than hammering a struggling endpoint forever — is what keeps one outage from becoming two.
- Dead-letter handling
- Records that fail repeatedly go somewhere visible with the error attached, instead of vanishing. You should always be able to answer what did not sync and why.
- An audit trail
- What was written, when, from which source, and by which run. When two systems disagree, this is the only thing that settles the question.
- Schema contracts
- The shape of the data is asserted at the boundary, so an upstream change surfaces immediately rather than corrupting records quietly for a fortnight.
Working with systems that were not built for this
Plenty of business software predates the assumption that anything else would talk to it. The integration surface might be a SOAP endpoint, a nightly flat-file drop, a database you are allowed to read but not write, or nothing at all beyond the web interface.
Each of those is workable. A flat-file drop is a perfectly good integration point if the contract is clear. A read-only database replica is often the most stable source available. Where there is genuinely no interface, portal automation becomes the connector, and the middleware treats it as a source like any other.
The decision worth making deliberately is push versus pull. Webhooks give you near-real-time updates but need an endpoint that is always available and tolerant of duplicates. Scheduled polling is simpler, easier to reason about, and usually fast enough. We would rather pick the simpler one and be right about it.
Kept small on purpose
A service that does one thing can be understood, tested, and replaced by someone who has never met the person who wrote it. A platform that does everything cannot.
That matters more than it sounds. Integration code tends to outlive the engagement that produced it, and the useful question is not how sophisticated it is but whether your team can maintain it in two years. We build accordingly, and hand over the source, the deployment, and the runbook.
Common questions
Frequently asked
Can you integrate with our ERP if it has no public API?
Usually. Depending on what the system exposes, the integration point might be a database replica, a scheduled file export, a SOAP endpoint, or the web interface itself via portal automation. The first step is establishing what surface exists — that determines the approach more than anything else.
Real-time sync or scheduled batches?
Scheduled polling is simpler, cheaper to operate, and sufficient far more often than people expect. Webhooks are worth the extra complexity when minutes genuinely matter. We would rather ask what latency the business actually needs than default to real-time.
What happens if the integration fails overnight?
Transient failures retry automatically with backoff. Records that keep failing land in a dead-letter queue with the error attached, and an alert goes out. The failure mode we specifically design against is the silent one — a sync that reports success while moving nothing.
Who runs the service once it is built?
Either of us. It can run in your cloud account with your team owning it, or we can operate it. Either way you get the source, the deployment configuration, and documentation — the intention is that you are never locked in.
Can you connect to Google Sheets or Excel?
Yes, and it is often the right answer. If your operations team already works in a spreadsheet, delivering there means the automation changes nothing about how they work. The data simply stops needing to be typed in.
Have a workflow like this to automate?
Send us the portal, the document, or the spreadsheet you are tired of filling in by hand. We will tell you within a day whether it is automatable — and what it takes.