Before the Signature: Making API Capability a Procurement Test

Procurement teams are practised at comparing licence costs, security certifications and implementation timelines. API capability frequently arrives later, during technical due diligence or, worse, during onboarding. By then the commercial leverage has gone. The supplier has been selected, the implementation partner is mobilised and the integration team is left to work around limits that should have been a contractual question.

For UK buyers, the issue is not whether a SaaS product has an API. Most do. The issue is whether that API is good enough for the organisation's integration estate, and whether the supplier has committed to keeping it good enough for the life of the contract. Integration capability is a procurement criterion, not an implementation detail.

Why procurement is the right gate

A procurement exercise is the point at which requirements, service levels and exit rights are negotiated. If API behaviour is absent from that process, it becomes an operational surprise. Rate limits that are generous in the sales cycle may prove restrictive under production load. A sandbox that looked adequate may lack parity with production. Webhooks may be described as real-time without any commitment on retry, ordering or replay. Data residency may be asserted for primary storage but not for backups, support access or sub-processors.

None of these points is exotic. They are standard integration concerns. The discipline is to ask them early, insist on written answers, and attach the answers to the contract as a schedule or service description.

Ten questions to ask before signing

1. What is the versioning and deprecation policy? Ask how many API versions are supported, how much notice is given before retirement, whether changes are additive or breaking, and where the changelog is published. A supplier that cannot commit to a notice period is asking the buyer to absorb avoidable rework.

2. What are the rate limits, quotas and burst behaviours? Obtain limits per endpoint, per account and per integration. Ask what error codes are returned, whether limits differ in sandbox and production, and how the supplier expects clients to back off. Unlimited API access is rarely unlimited in practice.

3. How reliable are the webhooks? Ask about retry schedules, ordering guarantees, duplicate delivery, signature verification, dead-letter handling and replay. A webhook that fires once and forgets is not an integration mechanism; it is a notification.

4. What sandbox access is provided? Confirm whether the sandbox mirrors production behaviour, how test data is created and reset, whether all endpoints are available, and whether sandbox use is charged. A sandbox that cannot exercise failure modes is of limited value.

5. Where is data processed and stored? Establish primary processing, backup locations, support access and sub-processor arrangements. For UK organisations, UK GDPR obligations and sector rules may require specific answers. A vague statement about European data centres is not enough.

6. What export formats and exit mechanisms exist? Ask for bulk export, schema documentation, frequency, cost and deletion confirmation. Exit should be designed before entry. If the API is the only route to the data, the contract should say how that route remains available during termination.

7. How is support escalated? Get severity definitions, response targets, named contacts, status page arrangements and the route for integration incidents. A general helpdesk queue is not an escalation path for a broken production interface.

8. What authentication and security controls apply? Confirm OAuth scopes, IP allowlisting, key rotation, audit logs and administrative controls. Integration credentials are privileged access and should be treated as such.

9. What observability does the buyer receive? Ask for API logs, metrics, event identifiers, correlation support and retention periods. When an interface fails, both sides need to reconstruct what happened.

10. What are the commercial terms for integration load? Check API call overages, egress charges, webhook volume, sandbox fees and any charge for export. Integration traffic can change the economics of a contract, so it should be priced before signature.

Turning answers into contract terms

The answers matter only if they are enforceable. A short API schedule can capture version support, notice periods, rate limits, webhook behaviour, sandbox availability, data residency, export rights and support escalation. Where a supplier will not commit to a specific figure, ask for the method by which the figure is set and the notice required to change it. That is often more useful than a headline number.

Public sector buyers should also check how these requirements sit with the relevant framework terms and any additional data protection clauses. Private sector buyers should align the schedule with their own exit plan and disaster recovery arrangements. In both cases, the integration team should review the schedule before signature, not after.

Red flags and next steps

Be cautious of suppliers that cannot describe their deprecation policy, charge separately for sandbox access, offer no webhook replay, or treat export as a professional services project. None of these is automatically disqualifying, but each should be priced and accepted deliberately.

A short proof of concept can test sandbox parity, webhook reliability and rate-limit behaviour before the contract is signed. That is a better use of procurement time than discovering the same limits during onboarding. The API is part of the product. It deserves to be procured as one.