In a technical meeting, you'll often hear the sentence: "this will go through an API." Most SME leaders nod at this point and hope it means everything will be fine — without really understanding what their team or partner is taking on. You don't need to be a developer for this article; the goal is for you to understand what an API integration actually means, and which questions to ask before you say yes to a project.

An API, simply put: an agreement between two systems

Picture an API like a restaurant menu shared between two systems. Your system can't reach into the other system's internal workings — it can't see how it stores data or processes requests — it can only do what the menu offers: "look up the order status," "create a new customer," "update stock." The API is exactly this menu: a precisely defined list of what can be requested, and what you'll get back in response.

This framing matters to you as a decision-maker because it shows where the limits are. If an integration tries to do something that isn't on the menu — because the other system simply doesn't offer that capability — then the integration isn't possible, no matter how skilled your developer is. This is the first, most important question at the start of every integration project: does the other system actually offer, via API, the function we need? This always needs clarifying at the start of the project, not discovered at the end.

What actually makes an integration reliable

Connecting two systems is rarely the "flip a switch and done" task it sounds like at first. One of the most important, often underestimated questions is what happens when something doesn't succeed — the other system isn't responding, is slow, or returns an error. A well-designed integration doesn't lose the data in that case — it retries, or at least signals that something failed, so you can handle it after the fact. A poorly designed integration, by contrast, quietly loses the order or the data, and no one notices for weeks, until someone comes looking for something that's missing.

The other important question is authentication and permissions: how does the other system know it's really you asking, and what you're allowed to access. Good practice says the integration should only be able to reach the data and functionality it actually needs — not the whole system. If a webshop integration gets access to the entire customer database when it really only needs order management, that's an unnecessary risk that will eventually come back to bite you.

Questions you can ask in the meeting

You don't need to get into technical detail to make good decisions — a few concrete questions and paying attention to the quality of the answers is enough. Ask what happens if one of the systems is unavailable — if the answer is vague or dodges the question, it's a sign that error handling hasn't been thought through yet. Ask how long it takes for a change to propagate to the other system — instant, a few minutes, or hours of delay — because this is what you'll actually experience in your daily operations.

If a developer can't explain in plain language what happens when there's an error, the integration will probably work — right up until the first time something goes wrong.

Finally, ask how you'll know if something breaks — is there alerting, or does it only surface once a customer complains. This last question is the one that reveals the most about how seriously long-term operations were thought through — not just the first, successful test run.

If you're about to start an integration project and would like someone on your side to think through the risks with you, reach out to us — we're happy to help you ask the right questions.