Integration & APIs
Making two systems
agree.
Every business past a certain size has two tools that should talk and don't. The work isn't connecting them: that's the easy afternoon. The work is what happens when one of them is down, rate-limits you, changes a field name, or returns something that isn't quite what the docs promised.
Open the integration demo
break the API on purpose, watch it recover, fully workingWhat the demo does. A live data pipeline moving records between three systems. You control the failures: throttle the API, force 500s, introduce latency, kill the endpoint entirely. Then watch the retry logic, exponential backoff, dead-letter queue and reconciliation do their jobs. Nothing is lost, and you can see exactly why.
That's the part most integrations skip, and it's the reason they quietly stop working four months after handover.
What this looks like in real work
- Undocumented and hostile APIs. I've written a full client against an admin API with no public documentation, reverse-engineered from network traffic, covering 170+ operations including payouts, refunds and fraud tooling. See the tooling section.
- Webhook infrastructure at scale. ~25 live endpoints for a single business, each with validation, idempotency, and retry semantics, so a duplicate delivery doesn't double-charge anyone.
- Sync that survives conflict. When both systems change the same record, something has to decide who wins. Getting that rule right is most of the job.
- Migrations without downtime. Moving data between platforms while the business keeps running on it.
Which two tools won't talk?
Tell me what's on each end and what needs to move between them. If there's a clean way to do it I'll say so; if the honest answer is "the integration isn't worth it, change the process instead," I'll say that too.