API or Batch Integration?

Decision in brief: Choose the exchange pattern from the deadline for the business decision. Use a timely API or event path where stale data changes an action; use scheduled exchange where a defined delay is acceptable.

Define freshness

Ask how old the data may be before a staff member makes the wrong decision. The answer may differ for stock availability, monthly accounting, and a customer address.

Design failure handling

APIs need timeouts and idempotency. Batches need completeness checks, checkpoints, rejected-row reports, and safe reprocessing. Neither should silently drop an exception.

Consider operational control

A batch may be easy to audit and replay; an event stream may reduce delay but increase ordering and duplicate-handling complexity. Choose from the real operating need.

Choose from the decision deadline

Write down the business action that consumes the data and the maximum age it can tolerate. An appointment assignment may need current availability; month-end accounting may work from a controlled nightly export. Then map the volume, error tolerance, order requirements, and operating hours. An API adds a live dependency and timeout behavior. A batch adds a completeness and reconciliation problem. Either can work if its failure mode is visible and the team can repair it before the next dependent decision. The freshness target should be measured at the recipient, not just at transmission.

A decision-deadline table can make the exchange choice concrete. Put the consuming action in the first column, then record the latest acceptable data age, expected volume, failure consequence, repair window, and owner. A live API may be justified for technician assignment but unnecessary for a weekly reconciliation report. Add a sample duplicate and a failed delivery to the proof plan regardless of pattern. The table should specify how staff know data is stale and whether they can continue safely. This gives the team a business basis for choosing the simplest exchange that meets the actual timing requirement.

Prove replay and duplicate safety

Send a duplicate record, an out-of-order change, a missing reference, and a partial failure. For APIs, define idempotency keys, timeouts, retry limits, and response contracts. For batches, define file or run identity, row counts, rejected-row reports, checkpoints, and a safe rerun. Keep a durable record of what was accepted and what needs attention. Operators should have a small repair path with ownership and audit history, not a request to edit a database by hand. Include versioning so a field change does not silently corrupt the recipient.

Decision checklist

• Write the maximum acceptable data age.
• Define the source and recipient contract.
• Test retry and duplicate behavior.
• Give operators a visible repair path.

A small test before committing

Select one business event and define how late it may arrive before someone makes the wrong decision. Replay normal, duplicate, delayed, and out-of-order delivery through a small integration prototype. Record the event ID, owner, retry policy, and reconciliation report. An API is appropriate only if real-time action matters and the receiving system can handle failures safely. A scheduled exchange can be simpler when bounded delay is acceptable and checks are visible.

Worked scenario

A hypothetical weekly finance export does not need a real-time API if the team reconciles it every Monday. A technician assignment screen may need current status to avoid double booking. The integration design can differ within the same platform.

For a scoped application of this decision, see Systems & Data Integration.

About this guide: Shawn Iuliucci, software architect at Innov8now. Examples are planning exercises, not reported customer outcomes. The cover is a concept illustration. Read our authorship, sources and corrections policy.