CentriWebAPI integration cost depends less on the size of the two systems than on how well one of them lets you in. An API (application programming interface) is the set of doors a piece of software offers so another piece of software can read or write its data, and connecting two systems properly can take a day when both have clear, stable doors and weeks when one has poor documentation, rationed access or messy data behind it.
What an integration actually is
Suppose your booking system should create a customer in your accounting software when a deposit is paid. Someone has to write the instructions: when this happens in system A, send these fields to system B, in this format, with these credentials, and do something sensible when it fails. That small piece of connecting logic is the integration. It can be built in an automation tool such as n8n or Zapier, or as custom code, and the cost mostly sits in the thinking around it rather than the typing.
It is worth separating three things that get lumped together as “integration”:
- A one-way push, where system A sends information to system B and nothing comes back.
- A two-way sync, where both systems can change the same record and must agree which version wins.
- A live lookup, where your website or portal asks another system a question each time a person loads a page.
A push is the cheapest. A two-way sync is the most expensive per field, because every conflict needs a rule. A live lookup sits between them but adds a dependency: if the other system is slow or down, so is your page.
What drives API integration cost
| Factor | Pushes the cost down | Pushes the cost up |
|---|---|---|
| Documentation | Public, current, with examples | Thin, out of date, or only available after signing up as a partner |
| Access | You can create your own keys | Approval process, paid tiers, per-call charges |
| Direction | One way | Two way with conflict rules |
| Data quality | Clean, consistent fields | Duplicates, free-text fields, years of habits |
| Volume | A few records a day | Thousands at once, rate limits to respect |
| Failure handling | Occasional failures can be re-run by hand | Money or legal records involved, so nothing may be lost or doubled |
| Testing | A sandbox or test account exists | Only production exists, so every test touches real data |
None of these show up on a quote request form, which is why the same sentence (“connect our booking system to our CRM”) gets prices that differ wildly. A sensible answer to “how much does API integration cost” only comes after someone has looked at both systems’ documentation and your data.
Why failure handling is most of the work
The happy path, where everything works, is the quick part. A connection that is built properly spends most of its code on what happens when it does not. Networks drop. The other system is briefly down. A field arrives empty. The same event arrives twice.
Payments show this clearly. Stripe’s documentation explains that its API supports idempotency keys, so a request that is retried after a connection error does not perform the same operation twice. On the receiving side, Stripe’s webhook documentation says it retries failed deliveries for up to three days in live mode, may send the same event more than once, and does not guarantee events arrive in the order they were generated. It recommends logging the event IDs already processed and replying quickly before doing heavier work. (Facts as at November 2026; check Stripe’s pages for current behaviour.)
That is one vendor’s rules, but the pattern is general. A proper integration needs to:
- Recognise a repeat and ignore it, so a customer is not created twice or an invoice marked paid twice.
- Cope with events arriving in the wrong order.
- Keep a record of what was sent and what came back, so a failure can be found and re-run.
- Tell a person when something needs attention, instead of failing silently for a week.
An integration without these can look finished on the day it is delivered and still lose records quietly. This is the part cheap quotes tend to leave out, and it is a fair question to ask anyone building yours: what happens when it fails halfway?
A worked example with your own numbers
A physiotherapy practice wants a booking made on its website to create the patient in its practice software and send a confirmation. To estimate the effort, list each piece and give it a rough size from the point of view of the person doing it. The numbers below illustrate the method and are not a price list.
- Read both systems’ API documentation and confirm what the practice software exposes: half a day, and the answer might be “very little”.
- Get access and a test account for each side.
- Map the fields: name, mobile number, date of birth, appointment type, which practitioner. Each field takes a decision, such as what to do with a number without a country code.
- Build the push for new bookings.
- Add rules for duplicates (same person, different spelling), cancellations and reschedules.
- Add logging and an alert to a named person.
- Test with real-looking cases, then run both the old and new process in parallel for a few days.
Steps 1 and 2 decide whether the project is small. Steps 5 and 6 are what separate a quick connection from a dependable one. If the practice software has no public API at all, the project changes shape: the options become an export file on a schedule, a vendor-approved connector, or replacing the software. Better to know that before anyone quotes.
Turning it into a budget
Once the steps are listed, a budget is simple arithmetic. Say the builder estimates 3 days for the push, 2 for duplicates and cancellations, 1 for logging and alerts, and 2 for testing and the parallel run: 8 days. At a day rate of $X, the build costs 8 times $X. Then add the monthly running cost of the automation platform or hosting, plus a reserve for the day the other system changes its API. Ask the builder to show you their list in this form. Where two quotes differ, the difference is almost always in the lines one of them left out.
Ongoing costs people forget
An integration is not finished once it is switched on. Three things continue:
- The other system changes. APIs get new versions and retire old ones. Someone needs to notice before it breaks.
- Credentials expire. Keys and tokens need rotating, and the person who set them up may have left.
- Usage-based charges. Some APIs and some automation platforms charge by volume. A workflow that checks for changes every minute can cost far more than one triggered by an event.
If you are comparing the cost of an automation platform against custom code, our article on Zapier, Make and n8n explains how each one counts usage. For software that will need long-term care, what software maintenance costs covers the running side.
Questions to ask before you get a price
- Which of the three types is this: push, two-way sync or live lookup?
- Have you read the documentation for both systems, and what did you find?
- What happens if the other system is down, or sends the same event twice?
- How will I know if it breaks, and who fixes it?
- Who owns the credentials and the code afterwards?
- What will running it cost each month once it is live?
A builder who can answer these before quoting has probably done the reading. For the same questions asked of web agencies generally, see questions to ask a web design agency.
Where CentriWeb fits
CentriWeb is a technology studio that connects the systems a business already uses. We build most client automations in n8n and write custom code when a tool is not enough, starting with the connection that costs you the most in rework, and we look after it afterwards. Our automation service covers the connecting work. Two common things that depend on good integrations are online quote calculators and customer portals.