Case 01 / 06 · Systems integration · 2026
Ecommerce ↔ ERP Integration
Sinister Diesel · private production system
The storefront and the ERP were connected through a paid third-party middleware subscription the team didn’t own or fully control. I replaced it with an integration I designed, built, deployed and still run.
Context / problem
What existed
Sinister Diesel’s storefront and ERP were connected through a paid third-party middleware subscription. It worked, but the team didn’t own it and couldn’t fully control it — behaviour that mattered to the business lived inside somebody else’s product, and years of it had never been documented.
Replacing it meant reproducing that undocumented behaviour exactly — SKU matching, discount handling, invoice timing — and cutting over without disrupting live orders.
My role
I designed and built the replacement end to end — architecture, code, deployment and the monitoring dashboard — and I run it in production.
Architecture
Five flows on one rail
A Node.js service polls Miva and NetSuite every five minutes across five flows. Every write is idempotent against local JSON ledgers, so re-processing an order never creates a duplicate.
How data moves
Poll, resolve, check, write
The service polls both systems on a five-minute cycle. An order picked up from Miva is resolved against NetSuite over its REST API using TBA OAuth 1.0a; Miva is read and written through its JSON API. Before any write, the flow checks a local JSON ledger for that record — if it has been processed, nothing happens. That is what makes a replay safe rather than destructive.
The same pattern covers shipments, deposits and invoices, product identifiers and customers. Five flows, one cycle, one ledger discipline.
Deep dive
Idempotency, in practice
The ledger is the reason a five-minute poll is safe. Open the core to see what a second pass over the same order actually does.
The order is not in the ledger. The flow creates the record in NetSuite and writes the identifier to the ledger in the same step.
Five minutes later the same order is still in the polling window. It is found in the ledger, so nothing is written. No duplicate order, no error, no manual cleanup.
If a run stops midway, the ledger records exactly how far it got. The next run resumes from there rather than starting the batch again.
Every sync run is visible in a status dashboard served behind Nginx, so “did it run and what did it do” is answerable without reading logs.
Engineering decisions
Every write is checked against a local JSON ledger first. Re-processing an order never creates a duplicate.
A five-minute poll across both systems, chosen because it degrades predictably: a missed window is picked up on the next run rather than lost.
NetSuite over its REST API using TBA OAuth 1.0a; Miva over its JSON API.
SKU matching, discount handling and invoice timing were reconstructed from the middleware’s observable behaviour before cutover, not guessed at afterwards.
Deployment & operations
Deployed under PM2 on a self-managed Linux server, with a live status dashboard behind Nginx. The cutover had to happen without disrupting live orders, so the replacement ran against real data and was verified flow by flow before the middleware subscription was retired.
Result
The middleware subscription was retired. Internal documentation puts the recurring cost at $17,797/year. The team now owns the integration outright, with full visibility into every sync run.
Marketplace Order Automation
The source changes from a storefront to a marketplace — and a gate appears on the write path.