Business integration comparison
APIs vs webhooks vs queues: which integration pattern should you use?
Use an API when a caller needs a response, a webhook when a system needs to announce an event, and a queue when accepted work must wait safely for processing. Combine them when one business workflow has several timing needs.
The direct recommendation
Use a synchronous API for current reads, validation and actions that need an immediate outcome. Use a webhook to tell another system that something happened without forcing it to poll. Use a queue when processing may be slow, bursty or temporarily unavailable and the accepted work must not disappear.
Do not force every interaction into one pattern. A customer request may be accepted through an API, processed through a queue and completed with a webhook notification.
01
APIs, webhooks and queues compared
| Factor | API | Webhook | Queue |
|---|---|---|---|
| Interaction | Caller requests | Producer pushes an event | Producer deposits work |
| Timing | Usually immediate | Asynchronous notification | Asynchronous processing |
| Receiver availability | Normally required during the call | Endpoint may fail and require retry | Consumer can process later |
| Best for | Queries and confirmed commands | Change notifications | Durable jobs and load buffering |
| Main risk | Latency and cascading failure | Missed or duplicate delivery | Backlogs and duplicate processing |
| Customer state | Result or clear error | Not normally customer-facing alone | Accepted, processing, completed or failed |
02
Choose an API when the caller needs a response
An API suits current lookups, validation and short business operations where the caller needs data or a confirmed outcome. Define authentication, authorisation, request and response schemas, timeouts, rate limits, versioning and error meanings.
- keep calls bounded and predictable;
- return an explicit accepted state for long-running work;
- use idempotency for actions that callers may retry;
- avoid long chains of synchronous dependencies; and
- monitor latency and business failures per operation.
Microsoft's asynchronous request-reply pattern recommends acknowledging valid long-running work and providing a status location instead of holding a synchronous request open.
03
Choose a webhook when another system needs an event notification
A webhook is a direct HTTP callback from a producer to a subscriber endpoint. It avoids repeated polling, but delivery remains a distributed systems problem.
- authenticate or verify signed webhook messages;
- acknowledge quickly and process significant work separately;
- use stable event identifiers for duplicate detection;
- define retry schedule, expiry and failed-delivery handling;
- support endpoint rotation and subscription administration; and
- offer replay or reconciliation for missed events where the process requires it.
Publish the fact that occurred rather than an instruction tied to one subscriber. Consumers should decide what the event means to their workflow.
04
Choose a queue when accepted work must wait safely
A message broker separates producers from consumers and buffers work until a worker can process it. This is useful for imports, exports, notifications, document processing and writes to slow or intermittently available systems.
Durability
Persist accepted work
Define retention, acknowledgement and what happens after repeated failure.
Idempotency
Expect duplicates
Recognise the business request before creating another payment, order or case.
Capacity
Watch the backlog
Monitor age, depth, throughput and consumer health, not only application errors.
Recovery
Own dead letters
Give failed messages a safe investigation, correction and replay process.
05
Combine the patterns around one honest business workflow
The API response should say that the request was accepted, not completed. The queue should carry a stable request identifier and sufficient context. The worker should reconcile the source outcome. The webhook should be safe to deliver more than once.
Use the broader guide to design a business system integration layer when several applications share these patterns.
06
Define the reliability contract before choosing technology
- Name the business event, command or query.
- State whether an immediate result is required.
- Define acceptable delay, loss, duplication and ordering.
- Choose authentication, authorisation and minimum payload.
- Specify retries, timeouts, idempotency and reconciliation.
- Design customer and operator states for failure.
- Test duplicates, outages, slow consumers and replay with representative volume.
Sources
Primary references
Questions
Frequently asked questions
What is the difference between an API, a webhook and a queue?
An API lets one system request data or an action from another. A webhook sends an HTTP notification when an event occurs. A queue stores a message until a consumer can process it. They solve different timing and reliability needs and are often used together.
When should you use a webhook instead of an API?
Use a webhook when the receiving system needs timely notification of changes without repeatedly polling an API. The receiver still needs authentication, duplicate handling, retry behaviour and a way to recover missed events.
When is a message queue better than a webhook?
Use a queue when work must survive temporary consumer failure, processing can be asynchronous, load needs buffering or several workers need to process reliably. A webhook is simpler when direct event delivery to a known HTTP endpoint is sufficient.
Can an integration use all three patterns?
Yes. An API can accept a request, a queue can process the work, and a webhook can notify the caller when the result is ready. The important part is that each boundary has a clear contract and honest status.
Do queues guarantee that a message is processed once?
Do not assume exactly-once business processing. Design consumers to recognise duplicate messages, use idempotency keys for business actions, record outcomes and reconcile final state.
Choose the integration pattern
Bring the business event, systems and acceptable failure behaviour.
LCR can help map the interaction and prove the riskiest reliability assumption before a wider integration build.