Somewhere in a meeting, a developer says "we'll just use the API" and everyone nods, and at least one person at the table is nodding at two syllables they've been politely not asking about for years.
If that's ever been you, this article is your amnesty. You don't need to become a developer to commission an integration well. You do need to know what you're buying, what can go wrong and which questions to ask, because the difference between a good integration and an expensive liability is almost entirely in the operational decisions, and those are yours.
An API is a defined set of requests one system can make of another: fetch this customer record, create this order, update this booking status. The provider publishes what's available, what data each request needs, and how the answers come back. That's genuinely it.
Here's the part that matters to you: an API is not automatically a business integration. It might hand over a product price without applying your account discounts, or accept an order without deciding what your staff do with an unknown stock code. The connection still needs mapping, validation and rules, and that's where the real work lives.
The best integrations start with one specific handover: when a quote is accepted, create the invoice; when an order ships, tell the customer. "Connect the website to the CRM" is a wish. "A validated enquiry becomes an owned lead within a minute" is a requirement you can test, and pay for with confidence.
For every piece of shared information, one system must own it and the others must defer. Skip that decision and your systems will eventually disagree about something that matters, probably a price. Then there's access: integrations authenticate with credentials that can often read and change real business data. Ask who holds them, what they can reach, and how they get revoked when a supplier or staff member moves on. Personal and commercial data deserves the same care in transit as it gets everywhere else.
Providers impose rate limits, retire old versions and have outages. None of that is scandalous; it's weather. A well-built integration queues what it can't send, retries sensibly, and, crucially, makes failures actionable: a clear alert saying what didn't transfer and what to do about it, rather than a silent gap someone discovers at month-end. When you're approving an integration, "what happens when it fails?" is the single most revealing question you can ask.
The developer will confirm the connection works. You should confirm the business works: follow a real order, a real refund, a real awkward case all the way through and check that people, records and money end up where they should. That's the acceptance test that counts.
This is bread and butter for our integration work, from joining a website to a CRM, to the deeper automation that follows, to the client-facing systems we've built on top, like Darkin Architects' portal. And sometimes the answer is that you don't need anything new at all, just better connections between what you own. Either way, you now know exactly what to ask.