API Consumption
Guideline for the structured use of external and internal APIs by applications and services.
Classification
- ComplexityMedium
- Impact areaTechnical
- Decision typeArchitectural
- Organizational maturityIntermediate
Technical context
Principles & goals
Use cases & scenarios
Compromises
- Leakage of credentials or insecure authentication.
- Unhandled failure cascades across the system.
- Excessive synchronous dependencies increase outage risk.
- Maintain contracts formally (e.g., OpenAPI) and test them automatically.
- Configure conservative timeouts and exponential backoffs.
- Collect telemetry per endpoint (latency, errors, throughput).
I/O & resources
- API specification or contract (e.g., OpenAPI)
- Authentication and authorization information
- Operational and monitoring access
- Consumed data and standardized DTOs
- Metrics, logs and traces
- Error reports and SLA alerts
Description
API consumption describes how applications and services use external or internal APIs in a structured way. It covers contracts, authentication, rate limiting, data transformation, and error handling. Robust consumption patterns improve reuse, reliability, observability, and performance in distributed architectures at scale.
✔Benefits
- Increased reuse of services and clearer integration boundaries.
- Better fault isolation and controllable stability in distributed systems.
- Enables standardization, monitoring and automated tests.
✖Limitations
- Additional latency from network calls and serialization.
- Third‑party dependencies can affect availability.
- Versioning and compatibility effort when interfaces change.
Trade-offs
Metrics
- Error rate (5xx/4xx)
Share of failed API calls relative to total calls.
- Latency (P95, P99)
Response time distribution to assess performance SLAs.
- Throughput (requests per second)
Measure of processed calls per time unit.
Examples & implementations
GitHub API for repositories
Consumers use REST/GraphQL interfaces to display and synchronize repository data.
Stripe payments integration
Payment processing via external API including webhooks, idempotency and security model.
Internal CRM as API
Unified CRM API consumed by multiple frontends and integrations, with versioning and access controls.
Implementation steps
Define and publish the contract (spec).
Implement client adapter with timeouts, retries and circuit breaker.
Integrate monitoring, metrics and alerts.
Establish versioning strategy and migration plan.
⚠️ Technical debt & bottlenecks
Technical debt
- Ad-hoc integrations without contract tests.
- Missing SDKs or outdated client libraries.
- Incomplete telemetry for critical calls.
Known bottlenecks
Misuse examples
- Frontend calls internal microservices synchronously in series instead of using BFF aggregation.
- Hardcoding sensitive API credentials in client code.
- Omitting monitoring, causing undetected outage risks.
Typical traps
- Missing timeouts cause hanging resources.
- Caching without invalidation yields stale data.
- Tight coupling to provider-specific features.
Required skills
Architectural drivers
Constraints
- • Network latency and bandwidth limits
- • Legal requirements for data exchange
- • Provider-side rate limits and cost models