Use Cases

Logistics Integration — Orchestrating the Fulfillment Lifecycle

How Orchesty handles logistics integrations across e-commerce, ERP, WMS, and carrier systems with reliable message flow, throttling, and operational visibility.

In a professional e-commerce ecosystem, logistics integration isn't just a point-to-point connection. It typically involves at least three systems: the E-shop (order generator), the ERP (the system of record, managing identity and warehouse), and the Carrier (fulfillment execution).

Orchesty acts as the central brain, directing data flow and ensuring the ERP remains a stable database while the orchestration layer takes responsibility for asynchronous communication and process integrity.

Order Ingestion and Identity Synchronization #

The process begins with a purchase on the e-shop. The ERP must be the "owner" of the order, even though the order originates in the e-shop.

  • Identity Check: Orchesty receives the order and immediately verifies the customer's existence in the ERP (via email).
  • Data Enrichment: If the customer does not exist, Orchesty creates them in the ERP first. Only then does it proceed with the injection of the order itself.

Architect's Pattern: Derived Connectors & Golden Thread

To maintain a linear and readable topology, we use Derived Connectors. Instead of the topology containing dozens of nodes for "stitching" data together, a specialized connector receives the entire order, queries the ERP, and "attaches" the discovered ERP Customer ID directly to it. Data flows as a continuous thread (the Golden Thread) that becomes richer at every step without causing the topology to branch out.

Fulfillment and Label Cache #

This topology is triggered when a warehouse worker changes the status in the ERP/WMS to "Ready to Ship." At this moment, the exact weight and dimensions of the package are known.

  • Carrier Handshake: Orchesty calls the carrier's API to create the shipment and obtain the label.
  • Label Caching: Orchesty doesn't just send the downloaded label (PDF/Base64) to print; it stores it in a temporary cache.
    • Significance: If a printer jams in the warehouse, the worker can reprint the label directly from Orchesty without needing a new (and often billed) request to the carrier's API. This prevents the ERP from being bogged down by storing bulky PDF files while still allowing access via a link.
  • Parallel Back-write: In a single moment, Orchesty writes the Tracking ID into the ERP, updates the status in the e-shop, and sends the PDF to the printer at the packing station.

Event-Driven Statuses and Monitoring Cron #

Tracking a shipment after it leaves the warehouse is critical for customer satisfaction. For security and reliability, a hybrid model is used to ensure 100% information delivery.

  • Primary Path (Webhook): The carrier "pings" Orchesty upon every status change (picked up, in transit, delivered). As soon as the webhook arrives, Orchesty propagates the change to both the e-shop and the ERP — typically within seconds.
  • Monitoring Status Cron (Integrity Check): Not all logistics APIs are perfect, and webhooks can occasionally fail. Therefore, a parallel Cron process runs at defined intervals (e.g., every 4 hours), actively checking "live" orders and querying their status.
  • Significance: This process acts as a safety net. If a webhook fails to arrive, the Cron process ensures that the delivery status in all systems is updated with minimal delay.

How the Logistics Flows Connect #

Instead of one monolithic integration, Orchesty orchestrates multiple connected topologies. Each one has a clear responsibility, but the platform still provides end-to-end auditing across all of them - so the entire lifecycle of an order can be traced as if it were one continuous process.

Logistics integration topologies connecting e-shop, ERP, WMS, carrier webhooks, and monitoring cron flows
Orchesty splits logistics integration into dedicated topologies for ingestion, fulfillment, and status monitoring.

Resilience and Error Management (Trash System) #

In logistics, data quality is the highest risk (invalid zip codes, unsupported characters in addresses). In Orchesty, these errors do not cause a system crash:

  • Trash: If a carrier rejects an order, the message drops into the Trash.
  • On-the-fly Repair: An administrator can correct the address directly in the Orchesty UI or simply verify it and adjust the address in the ERP. The process then continues from where it left off, without the need to manually re-edit data across the e-shop or ERP.

Conclusion: Order Auditing as the Source of Truth #

The primary value of this architecture is absolute observability. An audit for a specific order can be requested directly within Orchesty. An administrator can see:

  1. Exactly when the data arrived from the e-shop.
  2. The specific snapshot of data sent to the ERP.
  3. A precise log of communication with the carrier, including the cached label.
  4. A history of all statuses (via both webhook and the monitoring cron).

This solution eliminates the "finger-pointing" between different system vendors. Orchesty serves as the irrefutable witness and guarantor that every package gets its label and every customer receives timely information about their delivery.

Operator-facing dashboards aggregate this audit at a one-minute cadence — see the observability guide for the difference between event-driven propagation (seconds) and dashboard refresh (minute).

Related #

  • ID mapping guide — the e-shop ↔ ERP customer matching pattern that anchors the order ingestion flow.
  • Self-correcting integrations guide — what to do when a referenced customer or address is missing in the target system instead of failing the message.
  • Operational visibility — Trash workflow, Limiter view, and the dashboard cadence behind incident triage.
  • Trace auditing — the AI-native entity-level audit feature (Pro & Enterprise) that complements the existing per-process logs.