Review the business dependency, not only the endpoint
A third-party API dependency review explains which business journey relies on an external service, what information crosses the boundary and how the organisation detects, limits and recovers from failure. Uptime documentation matters, but it does not show the consequence of slow, incomplete or changed responses.
Start with the user or system action that triggers the call and trace the outcome through every dependent step. Record synchronous and asynchronous behaviour, retries, queues, caches, manual alternatives and what the user sees. One endpoint can support several journeys with different tolerance.
Separate provider assurance from local implementation. The supplier may operate a resilient API while the customer uses one credential, no timeout and an unsafe retry. Conversely, a robust client cannot overcome a provider that changes data meaning without notice. Both sides belong in the evidence.
| Area | Question | Evidence |
|---|---|---|
| Purpose | Which outcome depends on the call? | Journey map |
| Contract | What behaviour is documented and versioned? | Specification and change policy |
| Failure | How are timeout, error and bad data handled? | Tests and telemetry |
| Capacity | What limits and peaks apply? | Observed volume and quota |
| Continuity | What alternate or queued path exists? | Exercise and reconciliation |
Define service boundary and ownership
Name the provider, product, API, environment, version and contract or account. Identify business owner, consuming application owner, integration owner, security contact, support route and supplier manager. Shared ownership without a decision path delays response.
Record whether the dependency is mandatory, replaceable, cacheable or deferrable for each journey. A payment authorisation and an address suggestion may both be APIs while requiring very different fallback and communication.
Use stable identifiers in the enterprise integration inventory so incidents, changes and cost reviews refer to the same dependency. Link detailed specifications rather than duplicating them into several documents.
Inspect contract, specification and change policy
Review authentication, request and response schemas, status codes, idempotency, pagination, rate limits, versioning, deprecation, sandbox, support and status communication. Confirm which elements are contractual, documented guidance or observed behaviour.
Ask how breaking and non-breaking changes are defined. A new optional field can still break a strict consumer; a changed enum meaning can alter decisions without changing schema. Build tolerant parsing where safe and validate business semantics.
Track notice periods and test access. Calendar deprecations with owners and affected releases. Do not assume a managed connector removes the need to understand provider change; it may simply move part of the response to another supplier.
Design timeouts, retries and idempotency together
Set timeouts from user and service tolerance rather than library defaults. A very long timeout ties up capacity and delays fallback; a short one can create unnecessary failure. Separate connect, response and whole-journey limits where the platform supports it.
Retry only transient conditions and use bounded delay with jitter. Respect provider guidance and rate limits. Automatic retries can amplify an outage, create duplicate transactions or hide failure until a backlog becomes operationally significant.
Use idempotency keys, unique business identifiers or reconciliation controls for actions that must not repeat. Test the ambiguous case where the provider completes an action but the response is lost. This is more important than the obvious hard error.
Validate data and protect the trust boundary
Treat external responses as untrusted input even from an approved provider. Validate schema, length, type, allowed values and business consistency. Handle unknown fields and values safely. Do not pass error text or generated content directly into privileged actions.
Apply least privilege to API credentials and separate environments. Record storage, rotation, revocation and emergency ownership. Monitor unexpected scope, location and usage without placing secrets or sensitive payloads into logs.
Map personal and confidential data, provider retention, subprocessors and location. Minimise fields and confirm deletion or account closure. Jurisdiction-specific duties require appropriate review; the technical team should supply an accurate data flow and configuration.
Test quotas, peaks and cost behaviour
Measure current and forecast request volume by journey, time and customer cohort. Include batch, retry, monitoring and reconciliation traffic. Average daily volume can hide a month-end, campaign or incident peak that exceeds quota.
Test provider and local rate-limit handling in a safe environment. Queue, shed optional work or provide a clear user path according to priority. A tight retry loop converts a recoverable limit into a prolonged outage.
Model usage charges, overages, minimums and the cost of alternate processing. Keep current price evidence dated and separate technical decisions from commercial negotiation. Cost controls should not silently block critical transactions without an operating decision.
Build observable failure and user communication
Monitor availability, latency, error class, throttle, backlog, data validation and business completion. Provider status pages are useful but may not identify a tenant, region or local integration problem. Compare external and internal evidence.
Alert a team that can act, with correlation identifier, affected journey, recent change and safe diagnostic context. Avoid exposing sensitive payloads. Define escalation and supplier case information before an incident.
Tell users when an action is delayed, queued, failed or requires another route. Avoid success messages before the external action is confirmed. Prepare communication patterns through the SaaS incident tabletop.
Create a proportionate fallback and reconciliation plan
Options include cached reference data, queued processing, alternate provider, manual route, read-only mode or explicit service pause. Choose based on data freshness, consequence and control. A stale answer can be worse than no answer for some decisions.
The GOV.UK API guidance recommends planning for third-party API failure, including alternative service, queued action or another system where appropriate. Adapt the pattern to the organisation and exact business risk.
Define how queued and manual work is validated, replayed and reconciled after recovery. Prevent duplicates and preserve original intent and approvals. Measure the full backlog clearance, not only the first successful API response.
Exercise change, outage and provider exit
Test a timeout, malformed response, quota, credential rotation, version change and provider outage in a controlled environment. Include a partial success and delayed webhook. Confirm monitoring, fallback, user message and reconciliation.
Review after supplier incidents, contract changes, material traffic growth and new data. Keep the risk, runbook and inventory current through normal release control. An unchanged endpoint can carry a changed dependency when the business journey expands.
Use the SaaS exit planning guide when the API cannot be restored or remains strategically unacceptable. A robust dependency review preserves choices without pretending every external service has a simple substitute.
Review standards and incident response together
The GOV.UK guidance on working with open standards links standards with interoperability, flexibility and reduced lock-in. Its mandatory language applies to its government context, while other organisations can use the principles to assess avoidable proprietary dependency.
Use NIST SP 800-61 Revision 3 to connect API failure and compromise scenarios with incident preparation, response and recovery. An interface runbook should state when an error becomes a service or security incident and how evidence is preserved.
Review the dependency after a provider deprecation, incident or material change in business use. An API that was once optional can become critical as more journeys adopt it. Update fallback, monitoring, contract and recovery evidence when consequence changes.
Keep the review evidence close to the service record: test results, provider notices, architecture decisions and owner approvals. A reviewer should be able to trace why the dependency remains acceptable and which event would trigger reassessment.
