What does an API integration cost? Define the job before the price

Describe one business event

Write, for example: when a sales order is finally approved, create one draft invoice in the destination. Identify who approves the order, which status qualifies and which fields are mandatory. Saying that the CRM should connect to accounting leaves the most consequential decisions open. A quotation covering contact details cannot then be fairly compared with one covering orders, line items and attachments.

Define the boundary as well. Does the integration send the invoice, or does a person review the draft? Are corrections processed automatically? Keeping one consequential action outside the initial release can simplify investigation and acceptance. It does not make that action free to add later; record it as a separate decision with its own requirements.

Check that the API supports the job

An API advertised by a vendor does not establish that every required action is available. Check reading and writing, licences, test access and the actual fields. A product may expose only an export or omit a necessary status. Ask the proposal to distinguish tested assumptions from dependencies that still require vendor confirmation or access.

Where uncertainty is substantial, commission a bounded feasibility exercise. Its output should be a demonstrated minimal exchange, documented limitations and an updated scope. That is more useful than an undefined research phase. Agree that a valid outcome can be recommending an existing connector or a different business process when the requested integration is unsuitable.

Count business rules as well as fields

Ten directly copied fields can take less effort than one status with multiple exceptions. Consider partly delivered orders, organisations with several invoice addresses or product codes that mean different things in each system. The work is in decisions and verification as much as moving data. A field count alone hides that complexity and makes supplier estimates difficult to interpret.

For each rule, record the authoritative source, transformation and response to missing information. A missing project reference might trigger review, while a missing currency might block processing. Provide representative examples including one awkward exception. This lets the developer show whether the proposed solution addresses the same practical problem your employees are trying to solve.

The choice between a connector and custom integration determines development and maintenance work. Examine that decision separately: Standard connector or custom integration: test the whole process.

Compare a fictional work estimate

Suppose two suppliers investigate an integration for approved orders. Supplier A estimates 24 hours of implementation. Supplier B estimates 40 hours including discovery, scenario testing, alerts and handover. The difference does not prove that B works less efficiently. First ask whether A budgets those activities elsewhere and who investigates an order missing after a service interruption.

Divide your planning estimate into discovery, mapping, implementation, testing, introduction and handover. Multiply the agreed hours by the rate actually offered, then add explicitly approved platform and infrastructure costs. An uncertainty allowance should correspond to named unknowns. It should not become an invisible budget for every conceivable feature. The calculation makes choices discussable; it is not a prediction of an exact final amount.

Include failure handling in scope

A network interruption may be temporary, whereas an invalid customer reference generally needs correction. Repeating that second operation indefinitely is unlikely to help. Specify which failures receive automatic retries, which enter a review queue and which employee can authorise recovery. Microsoft discusses the distinction between temporary and persistent failures in its Retry pattern guidance.

An uncertain outcome also needs a defined procedure. A timeout after creating a draft invoice does not necessarily mean that nothing was saved. Ask how the integration finds the earlier attempt before somebody submits the same order again. A low implementation price can conceal ongoing operational effort when every ambiguous response requires somebody to search multiple systems manually.

Microsoft Azure Architecture: Retry pattern ↗

Separate migration from ongoing processing

Loading historical customer records is a different job from processing new changes. Older records may be duplicates, lack required fields or refer to inactive organisations. Specify the historical range, selection and person responsible for ambiguous matches. Do not assume that an inexpensive synchronisation project includes resolving every existing data-quality problem across both applications.

A practical first release might handle only newly approved orders while existing contacts are mapped beforehand. This limits initial volume but still requires a reliable identity strategy. Ask whether the historical load is a supervised one-off exercise or must be safely repeatable later. That choice changes the testing effort, review screens and evidence needed to show that the import is complete.

Budget for running the integration

Recurring costs can include hosting, integration-platform subscriptions, logs, vendor licences and agreed support. Transaction count is only one factor. A small daily workload with strict recovery requirements can need more support than a high volume of simple notifications. Ask which assumptions underpin the monthly estimate and which change would trigger a review of the agreement.

Assign responsibility for replacing expired access and following supplier changes. A process can be technically reachable while business work accumulates unprocessed. Periodically reconciling source orders with destination drafts may therefore be more useful than checking only whether a server is online. Include the checking and correction work that your own team will continue to perform after launch.

Agree acceptance through examples

A demonstration with one valid order says little about the rest of the assignment. Supply cases for a missing field, repeated submission, changed order, expired access and temporary outage. Describe the expected business outcome for each. For instance, an alert should identify the relevant order without exposing credentials or unnecessary personal information in a notification channel.

Have the operational owner assess whether the results match the actual working process. Agree which failures prevent launch and which remaining items can be scheduled later. Keep test evidence alongside the approved scope. After a change, the team can then recheck earlier behaviour without relying on a developer’s recollection or a recording that demonstrates only the happy path.

Make quotations genuinely comparable

Request separate lists of included work, exclusions, dependencies and recurring arrangements. A fixed price becomes useful when its boundary and change process are clear. State, for example, that an additional administration, second direction or new order status requires assessment. This prevents disagreement about changes described as small by one party but consequential by another.

A useful proposal also names who provides access, validates records and can approve scope. Consider transferability: will you receive documentation, an account inventory and a recovery procedure? Ask the supplier to explain the largest unresolved assumption. A concrete demonstration of a limitation helps you choose more effectively than an unconditional assurance that every integration will work.

Prepare for a productive first conversation

Bring one normal event and two exceptions. List the applications, administrations, desired processing delay, approximate volumes and the contact responsible for each system. Remove real personal information and secrets where they are unnecessary. Vendor documentation and a safe test environment are more useful than sending production passwords through ordinary email during a quotation request.

Finally define what the initial release should measurably improve: less repeated entry, timely drafts or visibility of missing transactions. Identify the measurement and owner. The price then supports a business decision. You are commissioning a manageable flow of information with explicit responsibilities, rather than buying an unexplained technical line between two product logos.

Turn the explanation into a project decision

Record your assumptions, unknowns and acceptance checks in the matching tool. Use the service guides to discuss delivery and scope.

• API integration ↗
• CRM integration ↗

Questions about this topic

Continue with a related question