API Integration Cost: What Should Your Quote Include?

API integration cost depends on what the connection must do after the first successful transfer. A useful quote should cover the records and fields being moved, the direction of updates, existing data, testing, failure recovery and ongoing support. Software access and running costs should be itemised separately.

If staff currently copy customer details between two systems, a quote to send new customers one way is not equivalent to a quote that also updates existing customers, resolves conflicting changes and recovers missed updates. Both may be described as “connecting the CRM to the accounts system”. They represent different work.

I would agree the update and recovery rules before comparing the headline prices. There is no useful universal price for an undefined connection; the practical budget starts with a shared scope that each supplier can price.

What should an API integration quote include?

An API is a way for software systems to exchange information. The cost of using it is only one part of the project. Someone still has to decide which information moves, implement the rules and check what happens when either system refuses an update.

Ask suppliers to separate the following work, even if they offer a fixed total:

• Discovery: inspect the systems, confirm API access and document the workflow, assumptions and exclusions.
• Build and configuration: connect the systems, match fields and implement update, validation and duplicate rules.
• Existing data: inspect, clean or transfer historical records, where required.
• Testing and launch: test normal and failed transfers, agree acceptance criteria and plan deployment and recovery if launch goes wrong.
• Handover and support: provide operating instructions, access arrangements, monitoring and a defined support period.

A fixed-price quote should make its assumptions and change process clear. For work billed by time, ask for the estimated effort, billing rate, budget checkpoints and what happens if discovery changes the estimate. Either approach can work, provided uncertainty is visible rather than hidden inside a single figure.

For automation and integrations, the scope should describe the business actions, not merely name the two applications.

Why two quotes for the same systems can cover different work

One-way updates versus two-way changes

A one-way connection might create a customer in the accounts system when staff approve a CRM record. It still needs matching and failure rules, but the authority is relatively clear: the CRM supplies the agreed fields.

Two-way synchronisation means changes can travel in both directions. If staff edit the same address in both systems, the connection needs a rule for which version wins. It must also avoid sending its own updates back and forth indefinitely.

Google Cloud’s guidance on bidirectional replication describes the conflict risk when both sides update the same data. Although it discusses databases, the same question matters when scoping customer updates: which system is allowed to decide each value?

Ask whether two-way updates are actually necessary for every field. The CRM might own contact details while the accounts system owns payment status. Giving each field a clear authority can reduce ambiguity without preventing useful information from flowing both ways.

Existing records, matching and cleanup

“Send new customers” does not necessarily include customers already in either system. Historical transfer, often called a backfill, should be a separate scope line.

Matching also needs a decision. An email address may be shared or changed; a company name may be spelt differently. Ask which identifier links the records, what happens when a match is uncertain and who reviews duplicates.

Cleaning data and building a connection are different tasks. A supplier may identify invalid addresses without being responsible for correcting them. Agree who supplies the corrected information and whether the quote includes another import afterwards.

Access, frequency and vendor constraints

Ask the supplier to check the exact subscription plans and API permissions in both systems. Request written confirmation of any required plan upgrade, API charge, usage allowance or test-environment fee. These depend on the products and contracts involved, so they belong in your specific quote rather than a generic cost allowance.

The quote should also state expected daily volume, peak bursts and how quickly changes must arrive. A scheduled batch and an immediate update have different operating requirements. API rate limits, which restrict how many requests can be made over a period, may require work to queue updates and spread processing over time.

Price missed and conflicting updates explicitly

A successful demonstration proves that a transfer can work. It does not establish how staff will discover a missing customer update or recover it safely.

Ask suppliers to describe the failed-update journey in ordinary language:

• Where is the failed update recorded, and what information can staff see?
• Who receives an alert, and who is responsible for acting on it?
• Which failures are retried automatically, and when do retries stop?
• How is a corrected record processed again without creating a duplicate?
• What prevents an older failed update from overwriting a newer change?

Retries need particular care. A system can accept a request but fail to return a confirmation, leaving the sender unsure whether it succeeded. Microsoft warns that repeating an operation that is not safe to repeat can cause unintended side effects. For example, sending another “create customer” request could create another record unless the receiving system or integration prevents it.

Microsoft’s integration guidance also recommends planning for error logging, monitoring and recovery. In a quote, those should become specific deliverables and responsibilities rather than a general promise of reliability.

A worked example: CRM customers sent to accounts

Illustrative scenario: staff approve customers in a CRM and currently copy their billing details into an accounts system. Some customers already exist in both systems.

Quote A covers sending newly approved customers from the CRM, storing the accounts-system identifier and recording failed transfers. An office administrator reviews failures and corrects invalid records. Historical customers and later address changes are excluded.

Quote B also covers matching existing customers, transferring later address changes, showing unresolved failures to staff and safely reprocessing corrected records. It includes launch reconciliation to check that the intended customers arrived.

Quote A can be a sensible smaller scope if the immediate requirement is only new-customer creation and staff accept the remaining manual work. Quote B covers more of the workflow if existing customers and later changes must also be handled. A higher price alone does not tell you whether it is excessive.

Now suppose an address update fails because the accounts system is unavailable. Before it is retried, a member of staff corrects the address again. Acceptance testing should demonstrate what happens to that older pending update, which record gets changed and who can confirm recovery.

If accounts staff must also edit billing addresses and send those changes back to the CRM, neither scope is sufficient unless it includes field ownership and conflict rules. That requirement changes the work being priced.

Separate the build price from the running budget

Ask for an initial total and a separate recurring-cost schedule. The latter should identify software subscriptions or upgrades, usage charges, hosting, monitoring and support, stating the currency and whether tax is included.

For variable charges, ask what drives the bill: records processed, individual actions, API requests or something else. Clarify whether retries and historical transfers count towards usage, and what happens when an allowance is exceeded.

Maintenance also needs boundaries. Correcting a defect in the agreed behaviour is different from adding a new field or adapting to a vendor’s API change. Ask what is included after launch, how long that arrangement lasts and how additional work is authorised.

Name the people responsible for checking alerts, renewing credentials and dealing with vendor changes. If support promises a response time, distinguish that from a guaranteed resolution time. A prompt acknowledgement does not necessarily mean a failed transfer has been repaired.

A checklist for comparing integration quotes

Send each supplier the same checklist and ask them to mark each item as included, excluded or dependent on further investigation.

• Records and fields: which customers, invoices or other records move, which fields are included and what triggers a transfer?
• Direction and timing: one-way or two-way, expected volume, peak demand and acceptable delay.
• Update rules: which system owns each field, how records are matched and how conflicting changes are handled.
• Existing data: inspection, cleanup, duplicate review and historical transfer, with a named owner for corrections.
• Failure recovery: logs, alerts, retry limits, safe reprocessing and a person responsible for unresolved failures.
• Software fees: confirmed subscription requirements, API access, usage allowances, hosting and variable charges.
• Testing and launch: representative records, duplicate and failure tests, acceptance criteria, reconciliation and rollback arrangements.
• Support: launch cover, monitoring, defect fixes, response commitments and the treatment of later changes.
• Ownership: control of accounts and credentials, access to code or configuration, documentation and arrangements for another provider to take over.

Resolve differences in scope before negotiating the total. If the budget needs to come down, narrow a requirement deliberately, such as postponing historical cleanup or limiting updates to one direction. Do not remove recovery work without agreeing who will find and repair the failures instead.