API integrations

Building the connection is rarely the hard part. The hard part is that two systems almost never mean the same thing by a customer or an order, and that one side will be down while the other carries on regardless. That's where the work is, and it's what I build for.

Based in Groningen, working across the Netherlands and remotely for clients worldwide.

Building the connection between two systems that need to know about each other. Including on the day one of them goes down.

Suitable when data moves between systems by hand today, or when the integration you have breaks more often than it should.

Good for

How I approach it

  1. Work out what each side actually means. One system calls someone a customer, the other calls them a contact, and they disagree about what should happen when the same person orders twice. I start by lining up which fields exist on both sides, which are required, and how to settle it when they contradict each other. It's dull, and it removes most of the surprises before a line of code is written.
  2. Build for the day it goes wrong. The other side goes down, sends the same event twice, or locks you out for an hour because you asked too fast. An integration that works on a good day isn't finished. A failed attempt retries on its own, processing the same event twice doesn't produce a duplicate invoice, and a burst gets throttled instead of knocking something over.
  3. You find out before your customer does. Integrations rarely fail loudly. They stop quietly, and three weeks later the books don't reconcile. You get an alert as soon as messages start queueing or failing, and a log you can look back through to see what went through and what got stuck.
  4. Yours afterwards. The integration sits in your own GitHub, the keys stay in your accounts, and I document there how the pieces fit. You agree a price per milestone, and after each step you decide whether we carry on.

Tech I work with

REST, GraphQL, webhooks, OAuth 2.0, Go, Python, TypeScript, Postgres, Redis, queues and retries, GitHub Actions, monitoring and alerting.

Frequently asked questions

Couldn't a tool like Zapier or Make do this?

Between two standard packages, often yes, and then it's the cheapest way to get there. It stops once one of the systems is something those tools don't cover, once the number of steps starts driving the monthly bill, or once you want to decide yourself what happens when something fails.

What happens when the integration breaks?

Third-party APIs change, so at some point it will. You get an alert when it does, and I write down where to look when that happens. You can leave the maintenance with me, pick it up yourself, or hand it to someone else.

Do we have to share our API keys with you?

I'd rather work in your own accounts, with keys you create and can revoke yourself. An NDA before we start is fine by me, if you'd rather have that on paper.

How do I know the data matches on both sides?

By checking rather than assuming. An integration that's running should come with a way to compare what's on one side against what arrived on the other, so a quiet mismatch shows up instead of surfacing at quarter end.

Can you take over an integration someone else built?

Yes. That starts with getting it running and working out what it actually does, before changing anything. How a handover like that goes is on the page about taking over existing software.

What does an integration cost?

It depends on how many systems are involved, how many flows run between them, and how strict the error handling has to be. Once I know which systems we're connecting, you get a fixed price per milestone before the work starts.

Two systems that know nothing about each other?

Tell me which two, and what's being done by hand right now. Then I can tell you whether it's straightforward or not.

Get in touch

Other services

Start a conversation