Most software buying conversations focus on features inside the application. The operating problem appears later, when the business needs the platform to exchange data with CRM, finance, identity, service management, reporting tools or automation workflows.
At that point, “it has an API” is not enough. The useful question is whether the API exposes the right business objects, with the right controls, reliability and commercial terms for the way the organisation expects to operate.
API capability is part of product fit because software rarely remains an island after implementation.
Start with the integration outcomes you expect
Do not begin API due diligence with technical terminology. Begin with the workflows. What must enter the platform? What must leave? Which events need near-real-time action? Which records must be created or updated from another system?
For example, a buyer may need new customers from CRM to create accounts automatically, posted invoices to flow to a reporting layer, or support events to trigger a service workflow. Those expected outcomes determine which API capabilities matter.
This extends the buying discipline in how to buy business software without letting the demo make the decision: integration needs should be part of selection, not a surprise discovered during implementation.
Ask what the API actually exposes
Request the API documentation before purchase. Check whether the important entities and actions are available. Some products expose read access but not write operations. Others expose only a subset of fields or require separate endpoints for functionality that appears simple in the user interface.
GOV.UK's recommended OpenAPI guidance notes that a useful API description can document endpoints, operations, parameters and authentication methods. A machine-readable description is useful, but complete documentation should also cover practical matters such as access, examples and limits.
Ask how authentication and access are controlled
Determine whether integrations use OAuth, service accounts, API keys or another mechanism. Ask whether permissions can be scoped to the minimum required data and actions, whether credentials can be rotated without rebuilding the integration and whether audit evidence is available.
A product that forces every integration to use one highly privileged user account creates an operational and security dependency that should influence the buying decision.
Ask about rate limits and volume
APIs often have limits on requests per minute, hour or day. Those limits may be perfectly adequate—or they may make a planned workflow unreliable at business volume.
Model expected transaction volume, peak periods and batch sizes. Ask what happens when limits are exceeded, whether limits differ by subscription tier and whether the vendor provides headers or telemetry that allow integrations to manage throttling predictably.
Ask how the platform signals change
Polling an API every few minutes is not always the best integration design. Ask whether the platform supports webhooks, event subscriptions or change notifications for important business events.
If events are available, understand delivery guarantees, retry behaviour, duplicate events and how missed events can be reconciled. Event support can materially change the complexity and responsiveness of downstream automation.
Ask about versioning and deprecation
Every important integration will eventually encounter platform change. Ask how API versions are managed, how long deprecated endpoints remain available, how customers are notified and whether breaking changes are documented in advance.
This matters because a stable API today is only valuable if the vendor has a credible process for changing it tomorrow. It also connects directly to why every important integration needs an owner.
Ask what is included in the licence
API access can be technically available but commercially restricted. Verify whether API use requires a higher subscription tier, additional integration licence, usage-based charge or vendor-specific middleware.
Also ask whether the same commercial terms apply to bulk export, webhooks, sandbox environments and high-volume access. These costs belong in lifecycle economics, not only the initial licence comparison.
Ask about data export and exit
An API is not only an integration mechanism. It can also affect portability. Ask whether the business can export its data in usable formats, whether relationships and identifiers are preserved and whether attachments or historical records are accessible.
UK government open-standards guidance explicitly connects interoperability with flexibility, reduced lock-in and easier migration. Private businesses do not have to follow government procurement rules, but the architecture principle is useful: future change should not be made unnecessarily expensive by closed interfaces.
Ask whether a sandbox exists
A test environment reduces the risk of developing and validating integrations against production data. Ask whether the sandbox supports the same API capabilities, how often it is refreshed and whether credentials and endpoints differ clearly from production.
A practical pre-purchase API checklist
- Can we obtain the documentation before signing?
- Are the business objects and actions we need exposed?
- Can access be scoped using appropriate authentication?
- What rate and volume limits apply?
- Are webhooks or events available for important changes?
- How are retries, duplicates and failed deliveries handled?
- How does the vendor version and deprecate APIs?
- Is API access included in the proposed licence?
- Can we test integrations outside production?
- Can we export our data in a usable form if we leave?
What better looks like
A strong software-buying process evaluates the platform as part of a wider operating architecture. API capability is assessed against real workflows, commercial terms are understood, documentation is available and the buyer knows how the product will connect, change and eventually be exited.
That does not mean every system needs a perfect API. It means the limitations are known before they become an implementation dependency.