When point-to-point works
A direct integration connects a producer to one consumer with little shared infrastructure. For a stable, narrowly scoped exchange between two systems, it can be quick to deliver and easy to reason about. That simplicity fades when each new consumer requires another custom connection. Transformation rules, credentials, and error handling become scattered across teams.
Use a direct connection when the data has a single consumer, the contract changes rarely, and both systems have clear owners. Document the mapping and the recovery path so a temporary shortcut does not become an undocumented dependency.
When an API boundary earns its place
An API-led approach exposes a stable capability rather than coupling every consumer to a system's internal model. For example, a customer profile API can hide changes to the CRM schema from the applications that use it. A shared API is valuable when several consumers need the same capability, when access needs consistent controls, or when the source system is likely to change.
That boundary has a cost: someone must own the contract, operate the service, and manage changes. Do not create a new API for every one-off data movement task. Reuse should be a real requirement, not just a hopeful label.
A decision checklist
- Count consumers. One stable consumer favors a direct integration; several consumers may justify a shared contract.
- Find the change boundary. If the source schema changes independently of consumers, put translation behind an owned interface.
- Specify nonfunctional needs. Authentication, rate limits, latency, availability, and auditability can change the answer.
- Plan failure recovery. Decide who retries, who receives alerts, and how missed records are reconciled.
- Assign ownership. An API without a team responsible for versioning and support is another dependency, not a reusable product.
Choose the smallest architecture that gives the next consumer a dependable contract without spreading source-system assumptions everywhere.
What to do next
Draw the current producers, consumers, and transformations. Mark the mappings copied between connections and the changes that have broken consumers. Those are the best candidates for a shared boundary. For the API you decide to expose, use a governance checklist before it reaches production.
Use case: stock availability from a legacy ERP
A wholesale distributor launches a commerce storefront while its ERP remains the source of truth for inventory. Polling the ERP directly from every storefront request would couple checkout availability to the ERP's response time and data model. Instead, an owned integration reads inventory changes, translates product identifiers, and updates a store-facing availability view. The storefront queries a stable availability API, while order placement still checks the authoritative stock rule before committing a sale.
A consumer-facing availability response should state when the value was last refreshed:
{
"sku": "SKU-42",
"available": true,
"asOf": "2026-10-11T10:00:00Z"
}Agree on how stale the storefront view may be, what happens when the ERP is unavailable, and how missed updates are reconciled. Track the last successful sync and surface stale data rather than silently promising stock that cannot be fulfilled. If this is the only consumer, a narrow integration may be enough; if marketplaces and sales tools need the same availability view, a shared API contract earns its operational cost.