Not Everything Should Be an API

There is a version of architecture discipline that looks sensible from a distance and becomes damaging up close.

It says that systems should integrate only through approved interfaces. In modern enterprise architecture, that often means REST APIs for request/response interaction and Kafka, or another event platform, for asynchronous communication. Everything else starts to look suspect. Database replication is treated as a shortcut. Direct data movement is treated as a breach of encapsulation. Anything that does not fit the application contract is seen as impure.

I understand where that instinct comes from. A long history of point-to-point database links, uncontrolled extracts, shared tables, undocumented file drops, and brittle overnight jobs gave architects good reasons to want cleaner boundaries. APIs and events brought discipline to a landscape that often needed it.

But the reaction can go too far.

Not every movement of data is a business interaction. Some integration exists to support reporting, analytics, audit, reconciliation, migration, search, synchronisation, or recovery. Forcing all of that through the same approved access pattern can remove exactly the information the downstream process needs.

The better starting point is not:

Which technology are we allowed to use?

It is:

Why are we moving the data in the first place?

Gartner’s framing of data-centric, event-centric, and application-centric integration is useful because it separates integration by intent rather than product category. I am not trying to improve on that model. I am using the same basic distinction for a practical reason: architecture decisions get worse when we collapse different kinds of data movement into one approved pattern.

In my own mind, the first cut is simple. APIs are for asking another system to do something. Events are for telling other systems that something happened. Data-centric integration is for giving another system the data it needs. Native database or platform replication is for protecting data and service.

That sounds obvious. In practice, it is often exactly what gets lost.

When A Clean API Hides The Problem

I saw this directly in an audit feed where the approved pattern was API access only.

The API exposed orders with their order lines. That sounded reasonable. From the application’s point of view, an order was not a useful business object unless it had lines. The API returned the business object the application understood, and it protected consumers from internal mess.

The problem was that the audit process was looking for precisely the cases where that assumption failed.

It needed to find orders with zero order lines.

Those records were not useful business objects. They were evidence. They showed that something had gone wrong and needed investigation. But the API filtered them out because its contract represented the application’s valid business view. It returned the cleaned version of the world, not the broken version the audit process needed to see.

The consequence was subtle but serious. We could not diagnose or fix the underlying problem from the downstream feed, because the feed had removed the evidence. Worse, downstream data quality checks would always pass, because they were checking the sanitised output rather than the actual committed state.

The API was not malicious. It was not even badly designed for its original purpose. It was the wrong pattern for the job.

That is the point. A business API is supposed to expose a controlled view of a capability. Audit, reconciliation, and problem resolution often need something different: the ability to see invalid, incomplete, contradictory, or rejected state. If the integration pattern only exposes valid business objects, then the process responsible for finding invalid state has already lost.

Business Interaction: Use APIs

When the purpose is a business-level interaction, APIs are usually the right pattern. Checking customer details, submitting an order, calculating a price, validating an address, or starting an approval process are not really requests for a pile of data. They are requests for another system to perform, expose, or coordinate a business capability.

That distinction matters.

An API is not just a data access mechanism. A good API provides a business contract. It hides internal implementation details, applies policy and security, protects the owning system, and allows the provider to evolve without exposing every internal data structure. This is application-centric integration: invoking and composing application functionality rather than directly moving datasets around.

The problem starts when that answer is applied to every other integration problem as well.

Change Notification: Use Events

A different problem is when something has happened and other systems need to know about it: a sensor reading, a device status change, an order status update, an inventory threshold breach, a completed payment, or a system alert.

Here, the pattern is not request/response. The producer is not necessarily asking a consumer to do something immediately. It is publishing the fact that something occurred.

This is where event-driven architecture and streaming are often the better fit. Kafka and similar platforms are valuable for this kind of problem because they decouple producers and consumers. The system producing the event does not need to know who is listening, and different consumers can react in different ways.

But events are not a universal answer either. An event can tell another system that something happened. It does not automatically provide a complete audit record, a reporting dataset, a recovery mechanism, or a consistent copy of state. Those requirements need to be considered on their own terms.

Reporting, Analytics, And Audit Need Data-Centric Patterns

There is another class of problem where the consumer needs data, not a business interaction. Reporting, analytics, audit feeds, reconciliation, downstream data quality checks, data warehouse loading, and data lake ingestion all sit in this territory.

These processes often need broad, repeatable, efficient access to data. They may need history. They may need rejected records. They may need before-and-after values. They may need the exact committed state, not the application-approved interpretation of that state.

This is where data-centric integration comes in.

The pattern might be batch ETL, ELT, file movement, change data capture, replication, or data pipeline processing. The right choice depends on latency, volume, consistency requirements, transformation needs, and how the target system will use the data. This is also where it is important not to confuse a business API with a data feed.

An API exposes a contract. It may filter, transform, enrich, validate, hide, or simplify the data in order to provide a coherent business capability. That is often exactly what it should do.

But reporting, analytics, and audit may need the data before it has been made coherent. They may need the awkward cases, the failed assumptions, the half-formed records, and the values that do not fit the happy path. A feed that removes those cases may look clean while making the organisation less able to understand itself.

This is why blanket refusal to allow data replication or change data capture technologies can be a problem. The issue is not that replication is always right. It is that rejecting it on purity grounds prevents the architecture from asking the real question: what does this downstream process actually need to know?

If the requirement is analytics or reporting, the answer may be a curated data product. If the requirement is audit or evidence, the answer may need to be closer to raw committed state. Those are different needs. They should not both be forced through the same application API because the architecture rulebook has only one approved shape.

Migration, Synchronisation, Search, And Read Models Need Their Own Design

There are other data-copy problems that need individual consideration.

Migration is not the same as reporting. Search indexing is not the same as audit. Operational read models are not the same as analytics. Cross-system synchronisation is not the same as disaster recovery.

Each has its own questions. A search index may tolerate a short delay; an audit feed may not tolerate transformation that removes evidence; a migration may need one-off reconciliation; an operational read model may have to make ownership and freshness explicit. The source and target may disagree, and the architecture has to say what happens when they do. The consumer may need valid business objects, raw state, or both.

This is why the category “data copy” can become too broad if we do not break it down. The shared point is that these are not business interactions in the API sense. They are ways of maintaining or deriving state for another purpose, and that purpose has to drive the design.

Active-Active Is A Reconciliation Problem

There is another pattern that deserves separate treatment: active-active data movement across regions.

This often appears in global systems where users in different continents need local performance, local availability, or local operational autonomy. The architecture may need more than a read replica. It may need writes to happen in more than one place, with data flowing between regions and conflicts resolved after the fact.

That is not ordinary reporting integration. It is not simply event notification. It is not disaster recovery either, although it is often discussed in the same conversation.

Active-active is a reconciliation problem.

The hard questions are different. Can the same business entity be changed in more than one region? Which changes are allowed locally, and which require a single authority? What happens when two valid updates conflict? Is reconciliation automatic, manual, or a mixture of both? How are users told that a conflict has been resolved? What is the evidential record of the conflict and the resolution?

This matters because active-active designs can look deceptively clean on a slide. Data flows both ways. Each region remains available. The system appears resilient and globally distributed.

But if two regions can make independent decisions about the same state, the integration mechanism is only part of the answer. The real design is in the reconciliation model. Without that, the architecture may be highly available but semantically confused.

So when the question is:

How do I keep multiple active regions operating on shared business state?

The answer is not simply:

Add replication.

It is:

Design the ownership, conflict, and reconciliation model explicitly.

DR Is Not Integration

There is one category that should be treated separately and forcefully: data protection and recovery. Disaster recovery is not integration. High availability is not integration. Failover is not integration.

These are resilience concerns, and they require stronger guarantees than general integration tooling is designed to provide.

If the requirement is recovery point objective, recovery time objective, failover, durability, and data integrity, the starting point should be native database replication, built-in HA/DR capabilities, or platform-level protection mechanisms designed for that purpose.

Using a general data integration tool for reporting is one thing. Using it as the foundation for disaster recovery is another. A pipeline that can move data from one place to another does not automatically provide a recoverable service. It may not preserve transaction boundaries. It may not provide a consistent recovery point. It may not fail over with the database. It may not give you the operational guarantees you need when the primary system is gone.

When data integrity is mandatory and recovery guarantees matter, the database platform’s native capabilities are usually the right place to start.

Agents Make This More Important

Agentic systems make this distinction more important, not less.

As agents, MCP servers, and tool surfaces spread through enterprise systems, there will be pressure to expose more and more capabilities as callable tools. That is useful when the tool represents a business operation. It is dangerous when we start treating every data need as if it were just another API or tool invocation.

An agent asking a system to perform an operation is one thing.

An audit process needing every invalid order is another.

A reporting platform needing millions of records is another.

A disaster recovery architecture needing a consistent recovery point is another again.

The interface shape should follow the purpose. If the purpose is business action, use a governed API or operation. If the purpose is notification, use events. If the purpose is evidence, reporting, analytics, migration, synchronisation, or search, design the data movement explicitly. If the purpose is recovery, use recovery technology. Agentic tooling does not repeal these distinctions. It makes the cost of getting them wrong higher, because the consumers become faster, more dynamic, and less likely to notice that the integration pattern has hidden the thing they needed to see.

The Simple Decision Model

The decision model I use is:

The table is not a full design method. It is a guardrail against the mistake that causes most of the trouble: treating one integration pattern as universally better than the others.

Conclusion

The mistake in API-only thinking is not that it values clean contracts. Clean contracts matter. The mistake is assuming that the same kind of contract can serve every purpose.

An API expresses a business view of the world. That is its strength. It gives consumers a stable, governed way to ask for an action or retrieve a meaningful business object. But some processes do not need the business view. They need the evidence underneath it, the changes around it, the copies derived from it, or the recovery guarantees that protect it.

When architects refuse to make those distinctions, the architecture may look purer while becoming less useful. It may be easier to govern on paper, but harder to audit, harder to reconcile, harder to report on, and harder to recover.

The discipline is not in forcing every integration through the same approved shape. The discipline is in choosing the mechanism that preserves the property the business actually needs: intent for business interaction, notification for change, evidence for audit, scale for analytics, reconciliation for active-active operation, and integrity for recovery.

That is why not everything should be an API.