API Integrations: Connecting Systems and Building APIs

When two systems have to exchange data without a person in between, an integration gets written. It shows up on a website, in a Windows program and in an Office add-in alike — but it is the same work everywhere and carries the same risk: half of the code depends on somebody else's system that you do not control and that changes without notice. That is why it is a separate service, with its own analysis and its own price.

What I do Why this is a job of its own
The other side

Half of the job is out of your hands

Code that I write, I can fix in an hour. The service on the other side has its own rules, its own quotas and its own outages, and there you wait. Everything that follows on this page is written because of that one sentence.

Everywhere

It runs through everything else I do

The same integration gets built into a website, a Windows program or an Office add-in. Only the screen around it changes; the weight of the work stays the same.

Evidence

You can see what was sent

Every integration gets a log: what was sent, what came back and when. Without it, every disagreement is argued without evidence; with it, you can see whose side the error is on in a minute.

What I do

Six kinds of work. The first three are the most common and the most represented in the portfolio.

Connecting to a third-party service

Your software calls somebody else's: card payments, an accounting service, a courier, a supplier's price list, SMS or email. The call gets written, along with the handling of the response, the behaviour when no response arrives, and a log that stays available for checking.

Two-way synchronization

Two systems hold the same data and both of them change it — a website and an ERP, a shop and a warehouse, a CRM and accounting. Most of the work here hides in the question of whose change is newer and what happens when both sides edited the same record.

Repairing an integration that stopped

It worked for years, then the other side retired an old version, changed how sign-in works or introduced a call limit. I go into the existing code, find what changed and bring the connection back, no matter who wrote it.

Your own API

When somebody else's software needs to take data from you — a partner, an app, a website or a client's system — your own API gets built: access keys, permissions, a call limit and documentation a third-party developer can work from without phoning you.

Payments and electronic invoices

Card payments, refunds and subscriptions, as well as filing to an electronic invoicing system. This is a special case, because an error costs money rather than time, so it is built with retries that cannot charge the same amount twice.

Data transfer and import

A one-off move from an old system into a new one, or a regular import of price lists and stock levels from a supplier. When the work is mainly in the database itself — schema, indexes, cleaning — that is database work.

Why this is a job of its own, not part of the build

When I build a screen, a database or a report, I know every participant and can fix all of them. With an integration that is not true, and that is why it is estimated, tested and charged differently. These six things turn up in almost every such job:

  • The documentation does not match reality. A field that always exists according to the manual sometimes arrives empty, and the example from the documentation returns an error. The first part of the job is establishing how the service actually behaves, not how it is described.
  • Sign-in and keys. A password, a token that expires, an OAuth window somebody has to click through, a certificate with an end date. Each of those is renewed differently and each can bring the connection down at three in the morning.
  • Call limits. Services count calls and either charge for them or refuse them. That is why a queue is built and what has already been fetched is remembered, instead of pulling everything every time.
  • The other side changes without notice. A version is retired, a field is renamed, the terms get stricter. The integration is written so that this becomes visible immediately and in one place, rather than three months later through a customer complaint.
  • Errors that come and go. The service is down for two minutes. The job must neither stop nor run twice — hence retries and the rule that the same order cannot be submitted twice.
  • The sandbox is not production. A test service often accepts what the real one rejects. Part of the work can therefore only be closed on your real data and your real accounts.

For all of those reasons an integration carries its own price on the other pages too — with Office add-ins, for instance, local work is separated from work with a connection to a third-party service. Here that part of the job is described in one place instead of five. Artificial intelligence integration is a special case of the same story: it is also a connection to somebody else's service, except that there the answer to the same question need not be the same twice, so it has its own page and its own analysis.

Delivered

Integrations run through the whole portfolio, because they appear in every kind of software I build.

  • All integrations — around fifteen projects, from accounting exchange to pulling data from suppliers.
  • Payments and e-commerce — Stripe Checkout, payments on a website and in a shop.
  • Business services — Xero for accounting, Dropbox for file exchange.
  • Automation — jobs that run on their own, at night, with nobody at the screen.

Two finished products grew out of exactly this kind of work: the SEF e-invoice add-in for Excel and the Word-GPT VSTO add-in.

See the integrations

How the work goes

  • You say which two systems need connecting and what ought to happen — for example, "when a customer pays on the website, the invoice should land in accounting".
  • Analysis of the other API. I read the documentation, make test calls with your account and establish what is possible at all. This is the one part that cannot be skipped, because without it neither the price nor the existence of a solution is known.
  • An offer for the agreed scope. After the analysis you get a fixed price and a list of the cases that are covered, including what happens when the other side does not answer.
  • Work on sandbox accounts wherever the third-party service offers them, then verification on your data before it goes live.
  • Handover. You get the code, keys in your own name, the call log and a short note on what to do when the other side changes the rules.

Pricing

The same arrangement as the other services: analysis first, then a piece of work with a known entry price, and small changes by the hour.

First step

The analysis is paid for and ordered first, and it is deducted from the price of the work if we continue. If it turns out that the third-party service does not allow what you need, you find that out after the analysis rather than after paid development.

Scopes of work

Smaller changes to an integration that already works do not have to go through a scope of work: for those there is hourly work, where you pay for the time spent. The complete price list is on the pricing page.

The full price list

What I commit to

What the price does not include

I write this so that you understand the price before ordering, not afterwards. Everything on the list is work I can do, but it is agreed and charged separately.

What to prepare before we start

Ownership and exit

  • Accounts and keys are in your name. You open the access to the third-party service, so the connection keeps working even if we never speak again.
  • The source code is yours, together with a description of every call that is used.
  • The log stays with you. Records of what was sent and received are kept on your server, not with me.
  • No middleman. Your software calls the third-party service directly; I do not introduce a server of mine that your data would have to pass through.

Frequently asked questions

Because that is where most of the uncertainty sits. Whether the third-party service gives the data you need at all, under what conditions and with what limit, is established through test calls rather than through reading. The amount is deducted from the price of the work if we continue, and if we do not, you keep a written statement of what is possible and can take it to any developer.

It happens, and it is not a fault in what was delivered. The integration is written so that such a change becomes visible immediately, in one place and with a clear message in the log. The adjustment itself is charged as a new change, usually by the hour, because it depends on what the other side altered.

Sometimes there is, through file export and import, email or a shared database. That is slower and more fragile than a real API, and I will tell you so, with an estimate of how long such a solution lasts before it starts to hurt. When even that is impossible, it is better not to start.

You do, and the account is in your name. Many services charge per call or per month, so the analysis includes an estimate of that cost — it can exceed the development itself if data is pulled more often than necessary.

You can, and that is usually how it goes. But it is kept as a separate item with its own price, because it carries a risk the rest of the work does not. That way you also see exactly what the connection to somebody else's system costs you, instead of it being hidden inside a lump sum.

Every integration gets a call log and, when we agree on it, an email notification when something gets stuck. A silent failure is the worst case: data stops arriving and nobody notices until a shortfall shows up in a report.

Which two systems need to talk to each other?

Write down which systems those are and what ought to happen. If the connection is possible, I will tell you how it is done and roughly what it costs; if it is not, I will tell you that too, before you pay for anything.

Send an enquiry

I usually reply the same day.

API integration and connecting business systems