When an API is the right answer
Use an API when the consumer needs current state at the moment it asks, or when an event must trigger an immediate action. A credit check at order entry, a pricing lookup at quote, a fulfilment status pushed to a customer — these need the answer now, and a nightly file cannot provide it.
Use batch when the consumer works on periods rather than moments. That covers most reporting and analytics, and it is where real-time integration most often gets built unnecessarily. A dashboard read once each morning does not benefit from a streaming interface; it just acquires more ways to fail.
What production-grade means
- Versioning — consumers do not break when the interface changes
- Authentication and authorisation proportionate to the sensitivity of the data
- Rate limiting and backpressure, so one misbehaving caller cannot degrade the source system
- Structured errors a caller can handle programmatically rather than parse from prose
- Monitoring and alerting on latency, error rate and throughput
- An OpenAPI specification and runnable tests, so behaviour is documented and verifiable
An interface without versioning, monitoring and structured errors works — right up until the moment it matters.
Avoiding the distributed monolith
The failure pattern is architectural rather than technical: point-to-point interfaces built between every pair of systems, until a change in one breaks four consumers and nobody can reason about the whole. Three habits prevent it:
- Route through a small number of well-defined interfaces rather than letting every system integrate directly with every other.
- Prefer asynchronous events wherever the caller does not need an immediate answer — it removes the temporal coupling that makes outages cascade.
- Version rigorously, so a producer can change without a coordinated simultaneous release across every consumer.
Integration platforms are the better answer for standard system-to-system movement with common connectors — cheaper to run, easier to staff. Bespoke APIs earn their place where the logic is specific to your business, where an external party consumes your data as a product, or where the platform cannot express the transformation required. Most organisations run both; the discipline is being explicit about which category each interface belongs to.
Who this is for
- Organisations whose systems are connected by fragile scheduled exports and manual file drops
- Businesses exposing data to customers or partners as part of the product
- Finance teams needing operational data at decision time rather than at month end
- Teams that have accumulated point-to-point integrations and can no longer change anything safely
API and integration FAQs
API or batch?
API when the consumer needs current state or an event must trigger immediate action; batch when the consumer works on periods, which covers most reporting.
What makes an API production-grade?
Versioning, authentication, rate limiting, structured errors and monitoring — beyond simply working endpoints.
How do you avoid a distributed monolith?
Route through few well-defined interfaces, prefer asynchronous events where possible, and version rigorously.
Build or use an integration platform?
Platforms for standard movement with common connectors; bespoke where the logic is business-specific or the data is a product.
Who maintains it afterwards?
Your team — delivered with source, OpenAPI spec, tests, deployment docs and monitoring configured.
Where this fits
APIs complement rather than replace the analytical stack. For period-based reporting, data integration & ETL into a warehouse is the right route; for bespoke tools consuming those interfaces, see custom analytics applications.
