Integrations rarely fail on a good day. They fail when the other side is down, slow, or sends something unexpected. We build interfaces that assume all of that and recover on their own.
A growing company does not buy its systems all at once. Sales picked one tool, finance another, the warehouse got its own program, and the webshop came from somewhere else again. Every choice was right at the time. The problem only appears when one order has to pass through all four and somebody does it by hand — copying a number from one window into another.
An integration is therefore not a technical project but a decision about where the data actually lives and who is allowed to change it. Leave that question unanswered and the integration connects two systems while creating a third version of the truth. We start from that question rather than from the API documentation.
Most integrations fall into one of six groups. What differs is how much the other side cooperates — and that, rather than the code, is usually what sets the cost.
If your system has no interface to talk to it through, we build one. Versioned, documented with an OpenAPI description, and with authentication that isn’t a shared password.
Connecting an external service to yours along with everything that comes with it: retries, rate limits, version changes, and what happens when the other side answers slowly or wrongly.
Synchronising customer and business data with the larger platforms — Salesforce, HubSpot, SAP, Microsoft Dynamics, NetSuite — so that every system holds the same customer rather than four similar records.
Creating shipments, selecting parcel machines and real-time tracking. Omniva, DPD, Venipak, Smartpost, DHL and UPS — including making sure an order’s status doesn’t hang when a carrier’s interface is down.
Stripe, PayPal, Apple Pay, Google Pay and Estonian bank links. Payments are where a retry must never mean charging twice — idempotency and reconciliation are part of the job here, not an extra.
Connecting language models and machine-learning services to an existing system where they pay off. With cost control, a fallback path, and a clear boundary on what may be sent to the model.
The interface style is chosen by what the other side offers rather than by what is newer. With legacy systems that often means SOAP and file exchange — and done properly, that is perfectly reliable.
The case for an integration is not that systems could talk to each other. These four are measurable before and after — and if none of them applies, the integration isn’t needed.
The biggest cost isn’t a licence; it’s the human time spent moving a number from one system into another.
When every system holds its own version of a customer, no single one of them can be trusted for a decision.
An integration whose failure you hear about from a customer is worse than no integration at all, because you believe it is working.
Partners change their APIs. The only question is whether you find out before or after.
An integration always looks simple in a proposal, because the hard part isn’t connecting — it’s failure. So ask what happens when the other side is down: does the message queue up, or is it lost. Ask how the same order is prevented from being processed twice. Ask where you can see that the integration is working — if the answer is “the customer tells us”, there is no monitoring.
And ask what happens when the partner changes their API. A versioned contract and a simulated partner in the tests are the difference between catching that change in staging and catching it on a Friday in production.
We assume the other side will be down, slow or wrong. Queues, retries and idempotent writes are the starting point, not a later fix.
We simulate the partner’s interface so your team can test at any time, including when the partner’s sandbox is closed or doesn’t exist.
Every integration hands over with alerting. You learn about an outage before a customer can call about it.
When there is no proper API and it comes down to file exchange or browser automation, we’ll build it — but we say upfront what it will cost you in maintenance.
API keys, repositories and cloud accounts are yours. An integration must never be the reason you can’t change supplier.
We are in Tallinn, in the same timezone and the same contractual framework. Data can stay entirely inside the EU.
The message goes into a queue and is retried with increasing back-off. Nothing is lost and nothing is processed twice, because writes are idempotent. If the outage persists you get an alert before a customer calls.
Yes. File exchange, database views, email parsing and, where necessary, browser automation are all workable. We’ll be honest about which of them is fragile and what it will cost you in maintenance.
Two to four weeks for a well-documented API, including tests and monitoring. With a poorly documented or unstable partner, most of the time goes on establishing how the partner actually behaves rather than on code.
That isn’t our decision — it’s set by what the other side offers. REST is today’s default: simple, cacheable, and everybody knows it. GraphQL earns its place when a client needs a different slice of the same data on every screen and the number of round trips would otherwise explode. SOAP turns up in banking and government systems and, done properly, is entirely reliable — it isn’t a bad choice, just an older one.
Alongside those sit webhooks, for when the other side wants to announce things rather than wait to be asked, and file exchange, which in many older systems is the only route in. When we’re building the API on your system, the answer is usually REST with an OpenAPI description.
We don’t use shared passwords or keys that never expire. Machine-to-machine traffic runs on OAuth2 client credentials with a limited lifetime that can be rotated without touching code. Every integration gets its own credentials and only the permissions it actually needs, so one leaked key doesn’t open the whole system.
Secrets live in a key vault rather than in a configuration file or a repository. Everything runs over TLS, calls are logged with who and when, and fields holding personal data are filtered out of those logs.
It happens, usually without proper notice. The protection is two layers. First, the contract is versioned, so a partner’s new version doesn’t replace the old one the moment it ships. Second, contract tests compare the partner’s actual response against what our code expects — those fail in staging rather than in production.
If a change does get through anyway, the queue retains the failed messages. Once the fix is deployed they are replayed and the data arrives; nothing is lost in the meantime.
Yes, and it’s designed that way. The code is in your repository, the API keys and cloud accounts are in your name, and the integration hands over with an OpenAPI description, a runbook and the monitoring configuration. Handover is an access change, not a migration project.
If you prefer, we continue on a support retainer where we watch the monitoring and track partner changes. Both are normal and the choice is yours — we don’t build integrations that need us in order to be maintained.
Describe your situation in a couple of sentences. We reply within one working day.