Webhooks vs Batch vs Real-Time Sync: Choosing the Right OMS–Dispatch Integration

The integration between your order management system and your dispatch platform is not a set-and-forget technical decision. It is the data pipeline that determines whether your dispatchers are working with real information or stale snapshots. Every minute of lag between an order cancellation in your OMS and the dispatcher seeing it is a minute in which a driver could be routed to a stop that no longer exists. Every missed webhook is a potential duplicate dispatch. The choice of integration pattern has direct operational consequences.

This guide covers the three primary integration patterns—webhooks, batch APIs, and real-time streaming—their appropriate use cases, failure modes, and how to combine them into a hybrid architecture that is both fast and reliable.

Webhooks: The Right Pattern for Order Lifecycle Events

What Webhooks Do Well

Webhooks are push-based: your OMS sends an HTTP POST to your dispatch platform the moment a relevant event occurs. New order created, order cancelled, delivery address updated, priority escalated—each event fires a payload to a configured endpoint within milliseconds of the trigger. For dispatch operations, this is the correct model for anything that changes what a driver should do. A cancellation that arrives in your dispatch platform 8 seconds after it is logged in the OMS can still be acted on. The same cancellation arriving in a batch sync 45 minutes later may result in a completed delivery that generates a return, a refund, and a customer complaint.

Idempotency: The Critical Implementation Requirement

Webhook delivery guarantees are at-least-once, not exactly-once. Your OMS will retry failed deliveries—and sometimes fire duplicates even when the first delivery succeeded, due to timeout ambiguity. Every webhook handler in your dispatch platform must be idempotent: if the same event ID is received twice, the second processing must produce exactly the same result as the first, with no side effects. In practice this means storing processed event IDs and checking for duplicates before acting. Skipping this step is the root cause of most duplicate order and double-dispatch incidents.

• Store and check event IDs before processing—reject duplicates with a 200 OK (do not return 4xx for known duplicates)
• Process webhook payloads asynchronously—acknowledge receipt immediately, process in a queue
• Set a retry budget: exponential backoff with a maximum of 5 retries over 30 minutes
• Dead-letter queue for events that exhaust retries—alert ops team for manual review
• Validate webhook signatures on every request—do not process unsigned payloads

"We had duplicate dispatches three times in one month before we found the root cause: our webhook handler was not idempotent and our OMS was retrying on timeout. Fifteen lines of deduplication logic eliminated the problem entirely."

— Platform Engineer, Last-Mile Logistics SaaS

Batch APIs: Reconciliation and Gap-Filling

What Batch Is Actually For

Batch APIs—polling your OMS on a schedule and processing the delta—are not a slow version of webhooks. They serve a different function: reconciliation. At end of day, your dispatch platform needs to confirm that every order in the OMS that was marked dispatched is also marked completed or returned in dispatch. Any mismatch is a ghost order, a billing discrepancy, or a lost item. Batch reconciliation catches these gaps. Webhooks miss them when events are dropped, network partitions occur, or the dispatch platform was briefly offline.

Batch Latency Is a Feature, Not a Bug

A 15-minute batch sync is not a problem if it is used for the right purpose. Invoice generation, SLA compliance reporting, driver performance scoring, and warehouse inbound logging are all appropriate batch workloads. These processes do not need sub-second data freshness—they need accurate, complete data. Running them off the webhook event stream introduces complexity without benefit. Keep batch workloads in batch and reserve the real-time path for events that affect live driver behaviour.

• End-of-day reconciliation: compare OMS completed orders against dispatch completion events
• Invoice generation: pull confirmed delivery records in batch rather than aggregating from events
• Historical reporting: batch export for BI tools and analytics platforms
• Gap-fill: batch poll after any webhook outage to recover missed events
• Driver performance scoring: aggregate completed stop data in batch, not in real time

Real-Time Streaming: When Webhooks Are Not Enough

High-Volume Event Streams

For operations processing thousands of order events per minute—large e-commerce platforms, multi-city same-day networks—individual webhook HTTP calls become a scalability constraint. At this volume, a message streaming platform (Kafka, AWS Kinesis, Google Pub/Sub) between the OMS and dispatch provides higher throughput, durable event replay, and fan-out to multiple consumers. The dispatch platform subscribes to the stream rather than exposing an HTTP endpoint. The trade-off is operational complexity: streams require dedicated infrastructure, consumer group management, and offset monitoring.

Driver Location as a Streaming Use Case

Driver location data—GPS pings every 10–30 seconds per active driver—is the canonical streaming use case in dispatch. This data volume (100 drivers × 4 pings per minute = 400 events per minute, continuously) is too high for webhook-per-event architecture and too time-sensitive for batch. A location event stream feeds the ETA model, the live map, customer tracking, and the SLA risk engine simultaneously. Managing this as discrete webhook calls would add unnecessary HTTP overhead and fan-out complexity.

Building a Hybrid Architecture

The Production-Standard Pattern

The correct production architecture for an OMS–dispatch integration combines all three patterns by function. Webhooks handle the order lifecycle event stream: creation, modification, cancellation, priority changes. A message stream handles high-frequency telemetry: driver location, sensor data, and delivery status pings. Batch handles reconciliation, reporting, and gap recovery. Each layer has a clear ownership boundary and does not attempt to substitute for another.

1. Order lifecycle events (new, update, cancel, priority) → webhook with idempotent handler
2. Driver location and status pings → message stream (Kafka / Pub/Sub)
3. End-of-day reconciliation and reporting → scheduled batch API pull
4. Gap recovery after outage → batch poll of OMS delta since last successful event
5. Integration health monitoring → webhook latency, stream consumer lag, batch completion time on ops dashboard

Integration Health as an Operational Metric

Integration failures are silent operational risks. A webhook endpoint that starts returning 500 errors during peak may go unnoticed for 20 minutes while dispatchers work from stale data. Treat your integration health metrics—webhook delivery latency p95, retry rate, dead-letter queue depth, batch lag—as first-class operational KPIs alongside route on-time rates and driver utilisation. Alert on them with the same urgency as an SLA breach.