The clearest sign that a business needs an integration is a person. Specifically, a person who exports a file from one system on a Monday morning and types its contents into another.
That task is reliable, slow, and wrong a small percentage of the time. It is also exactly what an API integration replaces.
What an API actually is
An API — application programming interface — is a defined way for one piece of software to ask another piece of software to do something, without a human in between.
The useful mental model is a counter at a bank. A customer can only interact through the counter: there are specific things they can request, specific information they must provide, and a defined response. They cannot wander into the vault. The counter is the API: a controlled, documented set of operations, with everything else kept out of reach.
So when a booking platform "integrates with Stripe", what happens is that the platform sends Stripe a request saying charge this amount, for this customer, with this payment method, and Stripe sends back a response saying whether it worked. No person involved, no card details stored by the platform, no file passed between them.
Two patterns are worth distinguishing, because they solve different problems:
- Request and response. Your system asks a question and waits for the answer. Is this slot still free? Charge this card. Create this contact.
- Webhooks. The other system tells yours when something happens, without being asked. This payment succeeded. This subscription lapsed. This refund was issued.
Most practical integrations use both. Request-and-response for the things you initiate, webhooks for the things that happen elsewhere — and the webhook half is the one people forget to scope, which is why so many integrations are mysteriously out of date.
Where integrations pay off
The test is not whether an integration is possible — nearly everything has an API now. It is whether the manual work it replaces is frequent, repetitive and rule-based. Work that happens twice a year, or that requires judgement every time, is usually better left to a person.
Payments
Almost always the first integration a business needs, and the one where building your own is least defensible. A payment provider handles card data, fraud screening, 3-D Secure authentication, refunds, chargebacks and the compliance burden that comes with all of it. Using one keeps card details out of your systems entirely, which is both safer and dramatically cheaper than the alternative.
What the integration actually gives you beyond taking money: an authoritative record of what was paid, automatic reconciliation against your own orders, and a webhook when a payment later fails or is disputed. That last one is the difference between finding out about a failed renewal immediately and finding out at month end.
CRM and sales
The common case is a website form that creates a contact in the CRM, tagged with where the enquiry came from and what the person asked about.
It is a small integration with a disproportionate effect, because it removes the two failure modes of manual entry: enquiries that never get entered, and enquiries entered without the context that would have let someone follow up well.
Booking and scheduling
Where availability lives in more than one place, you have a double-booking problem, and it is only a matter of time.
A scheduling integration keeps one system authoritative and synchronises the others — most often a business calendar, so that a booking made on the website appears in the staff member's own calendar and a block in their calendar removes the slot from the website. We have built this pattern several times; the All About House Cleaning platform synchronises appointments with Office 365 calendars for exactly this reason.
The hard part of scheduling integrations is rarely the API. It is time zones, recurring events, and deciding which system wins when both have changed.
Accounting and invoicing
Orders or completed jobs becoming invoices without re-entry. High value because the manual version is both frequent and consequential: a transcription error in an invoice costs more than an afternoon.
Worth knowing before you start: accounting systems are strict about their own rules — tax codes, account references, invoice numbering — and they will reject anything that does not match. Most of the work in an accounting integration is mapping your data onto their model, not calling their API.
Messaging and notifications
Transactional email and SMS: booking confirmations, reminders, receipts, password resets. Through a dedicated provider rather than your own server, because deliverability is a specialist problem and an email that lands in spam is the same as an email you did not send.
Appointment reminders are the highest-return example we see. They are a small integration and they reduce no-shows directly.
Internal systems and logistics
The least glamorous and often the most valuable: a shipping provider's rates and labels, a supplier's stock levels, a payroll system, an operational database somewhere else in the business. These rarely have a marketing page, and they are frequently where the actual hours are going.
What automation realistically looks like
Three honest expectations, because this is where integration projects disappoint.
It removes the copying, not the judgement. An integration can move an enquiry into your CRM, assign it, and notify the right person. It cannot decide whether to take the job. Automate the transport of information; leave the decisions.
Partial automation is usually the right target. "Every invoice is generated automatically" is ambitious. "Every invoice is drafted automatically and someone approves the exceptions" is achievable, and it captures most of the saving at a fraction of the cost. The exceptions are where the complexity lives, and handling them in code is often genuinely not worth it.
You need to know when it fails. This is the part that separates an integration that helps from one that quietly causes problems. Every integration fails sometimes: the other service is down, a record is rejected, a credential expires. If nobody is notified, the first symptom is a customer asking where their confirmation went — three weeks later. Error visibility is not a nice-to-have, it is the thing that makes the automation trustworthy.
Security considerations
Integrations move your data to places you do not control, so a few questions are not optional.
Credentials. API keys are passwords. They belong in environment variables or a secret store, never in the codebase, never in version control, and never in a client-side script where a browser can read them. A key committed to a repository should be treated as compromised and rotated, not quietly deleted.
Least privilege. Most providers let you issue scoped keys. An integration that only needs to create contacts should not hold a key that can delete them. When a key leaks, the scope is what limits the damage.
Verify your webhooks. A webhook endpoint is a public URL that anyone can send a request to. Every serious provider signs its webhooks so you can confirm a request genuinely came from them; if you do not verify the signature, you have built an endpoint through which a stranger can tell your system that an unpaid invoice was paid. This is the most common serious mistake we find in existing integrations.
Send only what is needed. Every field you transmit is a field in someone else's breach notification. Integrating a support tool does not require giving it your full customer record.
Know where the data goes. For personal data this is a compliance question as well as a technical one: which provider, in which jurisdiction, under what terms, and how do you get it deleted. Worth establishing before the integration exists rather than after.
Fail safely. When the payment provider is unreachable, the correct behaviour is to tell the customer the payment could not be processed — not to assume success, and not to retry indefinitely in a way that could charge them twice. Idempotency, where the same request sent twice has the same effect as sending it once, is the mechanism that makes retries safe, and good providers support it explicitly.
The ongoing cost nobody quotes
An integration is not a one-off build. It is a dependency on somebody else's software, and that is a permanent commitment.
APIs change. Versions are deprecated, endpoints are retired, required fields appear. Reputable providers give notice; the notice goes to an email address that needs to be read by someone who understands what it means.
Credentials expire. Keys get rotated, OAuth tokens need refreshing, certificates lapse. A surprising proportion of "the integration stopped working" incidents are an expired credential.
Rate limits bite as you grow. The integration that was comfortable at fifty orders a day may not be at five hundred.
Providers change terms. The free tier gains a limit, the API moves to a higher plan, the company is acquired and the product is sunset. This is a business risk attached to a technical decision, and it is worth asking, before you build, how hard this integration would be to replace.
Things break on both sides. Your system changes, their system changes, and nothing tells you the combination no longer works unless you are monitoring it.
Plan for a small recurring maintenance allocation per integration. Two or three integrations are manageable; fifteen built by different people over five years, with no central record of what connects to what, is a genuine operational burden. Keeping a simple inventory — what connects to what, which credential, who owns the account, what happens when it fails — costs almost nothing and is worth a great deal the first time something breaks.
Where to start
Spend a week noticing rather than planning.
Write down every task in the business that involves moving information from one place to another by hand. For each: how often, how long it takes, and what goes wrong when it is done incorrectly.
The ranking usually settles the question. The top one or two items will be obviously worth automating, there will be a middle group that is marginal, and there will be a tail of things that are cheaper to keep doing manually. Build the top two. Leave the tail alone.
If you would like help working out which is which — and whether the systems you already have expose what an integration would need — that is a short piece of work, and it is a much better starting point than a platform decision. Our Custom Web Applications work is frequently exactly this: not a new system, but the connective layer that makes the existing ones behave like one.
