Integrations and APIs

Two systems that should exchange data often cannot: one has no programmatic interface, the other has one but a poor one, and between them sits a person moving data by hand. We remove that person: we build a bridge the data crosses on its own.

When a system has no API

The usual answer to “connect our systems” is “enable the API or an export”. And if there is none? Then the data is taken from wherever the system does expose it, its format is parsed, and a durable layer is built on top. “No API” here means a system you have a lawful right to access — we work with your data and within the rules of the services we connect to.

“Sent” is not “delivered”

A fragile integration reports success by the status code and loses data when the network blinks. We count an operation as done by its consequence — the data actually being in place — not by a promise. Retries with growing pauses, honest statuses instead of a cheerful “ok”, protection against double processing. The reasoning behind these choices is in our work.

Built to survive the source changing

Someone else’s system changes without warning: a redesigned page, a new export format, an updated protocol. An integration held together with tape breaks that day. We assume the source will change, and we tell you how many outside systems the result depends on — so you know the cost of ownership in advance.

What we need from you

Access and a description of what to connect to what. If the work needs access to personal data, we sign a processing agreement — that is a legal requirement, not a formality.

We work in stages with payment after the result. The source code is yours.