You do not need to know how an API works. You do need to know whether the software you are buying has a good one, because that single fact will decide whether your systems ever talk to each other — and what it costs when you try.
The plain version
An API is a documented way for one piece of software to ask another to do something. Where a person clicks "create invoice," another system can send an equivalent request and get a structured answer back.
It is a front door built for software, with a published set of things you are allowed to ask and a defined format for the answers. The alternative is no front door — at which point integration means exporting CSVs and hoping the column order never changes.
Why it decides the cost of everything
Every "can these two systems talk?" question resolves to this. With a good API on both sides, an integration is days. Without one, you are looking at:
- Scheduled file exchange. Someone exports, something imports. Works, but it is hours out of date and breaks silently when a format changes.
- Screen scraping. Software pretending to be a person clicking through the interface. Fragile, breaks on every vendor update, and often violates the terms of service.
- Manual re-entry. A person retyping. The most expensive option, and the most common.
This is why the API question belongs in software selection, not in the project six months later when you discover the answer.
What to ask before you buy any software
- Is there a documented API, and can I see the documentation now? Public docs are a good sign. "Available on request" often means thin, and "contact your account manager" often means chargeable.
- What does it cost? Some vendors put API access behind a higher tier or charge per call. Find out before it is a surprise line item.
- Can it write, or only read? Read-only APIs are common and half-useful. If you need to create or update records, confirm that specifically.
- Are there webhooks? Can it notify you when something changes, or must you poll? Webhooks are the difference between real-time and "every fifteen minutes."
- What are the rate limits? Fine for normal use, potentially fatal for a migration or a nightly sync.
- How do they handle breaking changes? Versioning and deprecation notice periods. A vendor who changes an API without notice will break your integration on their schedule.
The pattern worth adopting
Rather than connecting every system to every other system — which becomes unmanageable quickly — pick a system of record for each kind of data. Customers live in one place. Invoices live in one place. Everything else reads from there.
It sounds obvious and it is routinely violated, usually by accident, as each new tool brings its own copy of the customer list. That is how you end up with three answers to "what is this customer's address" and no way to tell which is right.
When there is no API
Sometimes you are stuck with a system that has none. Options, in order of preference: check for a partner or integration marketplace; check whether the database is directly accessible under your licence; use a scheduled export with strict validation; and only then consider anything more exotic.
Do budget for it properly — integration against a system that resists it is frequently the largest single line in a project, and it is the most common reason estimates prove optimistic. Our note on what custom software costs covers why.
Integration work of this kind is a large share of what we do under application development, and where the systems are spread across cloud providers it usually touches cloud and infrastructure too.
Not sure whether two systems can be connected? Tell us which ones and we will find out.