An integration quote almost always prices the build. Two systems, an agreed set of fields, a week or three of work, done. What it rarely prices is the decade afterwards, and that is where integrations actually cost money.
This is the part worth knowing before you sign anything: what an API integration costs you after it ships, and which of those costs are avoidable.
The vendor changes the API. That is not a failure, it is the deal
Every SaaS platform you integrate with will change its API. Not maliciously — because they are improving it, deprecating something insecure, or moving to a new auth model. The good ones give twelve months' notice. The rest give what they give.
What that means practically is that an integration is not a thing you build; it is a thing you keep. Somebody has to read the deprecation notices for every platform in the chain, decide which ones apply, and schedule the work before the date rather than after it. If nobody is doing that, the integration is running on borrowed time and the bill arrives all at once, usually during a month you had other plans.
The failure mode is specific and it is worth recognising: it does not break loudly. A deprecated field starts returning null, a nightly sync quietly writes empty values, and somebody notices three weeks later that the report has been wrong since the change.
Rate limits are a design decision you make once, by accident
Rate limits are documented, everybody reads them, and almost nobody designs for them — because at the volume you are testing with, you never hit one.
Then a backfill runs, or a customer imports a spreadsheet, or the business has a good week, and suddenly the integration is being throttled. What happens next depends entirely on a decision somebody made in an afternoon months ago: does it retry, does it back off, does it queue, or does it drop the record and move on?
If the answer is “it throws an error into a log nobody reads”, you have silent data loss with a timestamp. The fix is not complicated — a queue, exponential backoff, and an alert when the queue depth stops draining — but it is meaningfully more work than the happy path, and it is the first thing dropped when an integration is quoted as a fixed-price build.
Auth expires, and it expires at the worst time
OAuth tokens expire. Refresh tokens expire. Certificates expire. Service accounts get disabled during an offboarding because nobody could tell what they were for.
The pattern to watch is the one where a single person's credentials are quietly doing the work. It happens because it is the fastest way to get an integration running, and it survives right up until that person changes their password, changes role, or leaves. Then a business process stops, and the reason is buried three systems away from the symptom.
One question that surfaces most of this: ask whose account the integration authenticates as, and what happens to it when that person leaves. If the answer needs a meeting to establish, that is the finding.
Who gets paged
This is the cost nobody quotes and the one that decides whether the integration survives its second year.
When the sync fails at 2am, four things have to be true. Someone has to know — there has to be an alert, and it has to reach a person rather than a mailbox. Someone has to be able to tell what broke, which means the logs have to say something more useful than “request failed”. Someone has to be able to fix it, which means the knowledge cannot live entirely with whoever built it. And someone has to own that, by name, on a rota.
Most mid-market integrations have none of the four. They have a person who wrote it and a hope. That works until it does not, and the moment it stops working is usually the moment that person is on holiday.
What actually reduces the bill
Three things, in order of how much they save.
- Fewer integrations. The cheapest integration is the one you did not build because the process did not need it. A surprising share of requested integrations exist to move data to somebody who then re-keys it somewhere else — the honest fix is upstream, in the process, not in the plumbing.
- One seam, not many. Five systems talking point-to-point is twenty relationships to maintain. Five systems talking through one integration layer is five. It is more work on day one and dramatically less work in year two, and it is the single decision that most affects the maintenance bill.
- Idempotency, from the start. If re-running a sync twice produces the same result rather than duplicate records, almost every recovery becomes “run it again”. If it does not, every recovery becomes an investigation. This costs nothing to design in and is expensive to retrofit.
What to ask for in a quote
You are not trying to make the number smaller. You are trying to make it complete, because an integration quoted without these will cost the difference anyway, later, unbudgeted.
- What happens when the vendor deprecates a field we depend on, and who is watching for that?
- What does the system do when it is rate-limited — retry, queue, or drop?
- Whose credentials does it run as, and what happens when that person leaves?
- If it fails overnight, who finds out, and how?
- Can this be re-run safely, or does re-running it create duplicates?
A firm that has done this before will have opinions about all five. A quote that does not mention any of them is pricing a demo.
Where we sit in this
This is labour and judgement, not a product with a license key. The platforms on both ends — the CRM, the ERP, the queue, the model provider — you hold in your own name and pay for directly. What Leverage Automated does is the seam between them, the failure paths, and the part where somebody is accountable when it breaks on a Tuesday.
If you are about to commission an integration, the useful conversation is not about the fields. It is about the five questions above, and what the honest answers cost.
Related reading: Modernizing a legacy system you cannot turn off — what to do when one end of the integration is the system nobody wants to touch. And your AI agents need a manager, not just an API key — the same accountability question, asked about the thing calling the API rather than the integration underneath it. And data cleansing before an AI project — on why fixing the source beats cleaning the output, which is the same argument one seam earlier. And seven major AI incidents in nine days — the failure this post does not cover, where the dependency itself goes away and the only fix is a route you built beforehand. The service page for this work is AI integration.