Synchronous vs Asynchronous Integration

What synchronous means

A synchronous call blocks until the work finishes. Your client sends a request, waits, and receives the result in the same exchange. This is the simplest model to reason about: the response either succeeds or fails, and there is no separate state to track.

Synchronous calls suit operations that complete quickly and predictably — fetching a single record, validating input, or reading a small list. The cost is that the caller is held hostage to the slowest step. If a downstream system is slow, every waiting request is slow too, and threads or connections pile up. Keep synchronous work fast and bounded so the caller is never left hanging.

What asynchronous means

An asynchronous design accepts the request, returns quickly with an acknowledgement, and performs the real work afterwards. The caller is told we have received this rather than here is the final answer. Results are delivered later — by polling, a callback, or an event.

This decouples the caller from processing time. A long task such as generating a batch document or reconciling many accounts can run without anyone waiting on an open connection. The price is complexity: you now need an identifier for the in-flight work, a way to report progress, and handling for work that ultimately fails. The caller must be designed to tolerate not yet.

Choosing between them

Pick synchronous when the operation is fast, the caller genuinely needs the answer immediately, and failure can be reported on the spot. Pick asynchronous when the work is slow, expensive, batched, or naturally event-driven.

• Latency budget — if a human or upstream timeout cannot wait, do not block them.
• Coupling — asynchronous models survive downstream slowdowns far better.
• Ordering — synchronous gives you a clear before and after; asynchronous needs explicit sequencing.
• Failure visibility — synchronous failures surface immediately; asynchronous ones must be reported back through status or events.

Many integrations mix both: a quick synchronous acknowledgement followed by asynchronous fulfilment that the client tracks separately. When in doubt, keep the user-facing path fast and push the slow work behind it.

Tracking asynchronous work

Once work is asynchronous you need a handle on it. The usual pattern is to return an identifier the caller can use to check status. A simple status response might look like this:

{
  'job_id': 'abc-123',
  'status': 'processing',
  'submitted_at': '2026-06-29T00:00:00Z'
}

The client stores the identifier and later asks is this done yet? Design status values to be unambiguous — queued, processing, completed and failed are clearer than a single boolean. Always include enough detail for a failed job to be diagnosed without a support call. See polling vs webhooks for delivery options.