Synchronous vs. Asynchronous Integration with Fluent Order Management

Fluent’s Architectural Philosophy

• Fluent OMS is an event driven workflow platform, not a synchronous request and response processor.
  Key order lifecycle changes, such as order creation, allocation, payment, fulfilment, invoicing and shipment, are modelled as events that trigger rulesets.
• Every meaningful change in an order's lifecycle, creation, allocation, payment, fulfillment, invoicing, shipment, is modelled as an event that triggers a ruleset, which can in turn emit further events.
• This model is what allows Fluent to operate at very large scale across a multi tenant cloud platform: rulesets execute quickly, hand off long running or external work asynchronously, and move on, rather than holding resources open while waiting on a third party
• The trade off is explicit and intentional. Fluent optimises for throughput, resilience, and predictable behaviour at scale, over the convenience of an in line synchronous response within a workflow rule.

Why Synchronous Calls Inside a Workflow Create Risk

• Functional risk is a rule that calls an external system and waits for the response blocks the ruleset until that call returns. This can create race conditions, sequencing issues, duplicate event processing, and orders that become “stuck,” requiring manual reprocessing to recover.
• Processing delay risk - Fluent runs on shared, multi tenant infrastructure. A rule that sits open waiting on a slow or unresponsive external system ties up processing capacity for longer than necessary, which can delay the handling of that tenant's other events and requests queued behind it,  slowing down the very orders the integration is meant to keep moving.

Fluent Commerce — Platform Documentation: Synchronous vs. Asynchronous Integration

• Timeout and remediation risk: rule execution is subject to a maximum execution time. If a synchronous external call causes a rule to exceed that window, the platform will reexecute the rule. For a call that already succeeded but was simply slow to respond, this can create duplicate side effects at the external system and require manual remediation to unwind.
• Authentication and operational overhead: a synchronous call from a rule must carry its own credential handling, retry logic, rate limiting, and error handling for the target endpoint, operational concerns that do not belong inside a workflow engine's rule execution.
• Platform-positioning risk: allowing ad hoc synchronous calls out of rules tends to pull Fluent toward being used as a general purpose integration or orchestration platform for third party systems. Fluent is an order management and fulfillment orchestration platform, not an enterprise service bus or iPaaS, and preserving that boundary keeps both the platform and the customer's own architecture cleaner and more maintainable over time.

Where Synchronous Calls Belong: The Integration Layer

• Purpose built integration platforms such as MuleSoft, Boomi, or Fluent's own Fluent Connect are designed precisely for this role. They can make a synchronous call to a third-party API, handle its authentication, retries, and error handling, and then translate the outcome into an asynchronous event or webhook response back into Fluent. 
• The standard pattern is: Fluent fires a webhook to request an action; the connector or integration layer immediately acknowledges receipt with a 200 OK — a transport acknowledgement, not a business outcome. The integration layer then performs the actual call to the external system, synchronously if required; once it has an answer, it reports the result back to Fluent as a response event, which is what actually advances the order.
• This keeps Fluent's workflow non blocking throughout, while still allowing the interaction with the third party system itself to be synchronous where that system requires it.

Applying the Pattern to Payment Processing

• Sensitive payment data (card numbers, tokens, credentials) should never flow through Fluent. The
  ordering channel typically completes authorization directly with the PSP and shares a token or
  reference with the order.
• Fluent's Payment Connector Contract describes how a payment connector should be structured: the
  middleware or connector layer can call the PSP synchronously to capture or refund funds. It simply
  reports the outcome back into Fluent as an event, rather than having Fluent's rule wait in place for the
  PSP's answer.

Applying the Pattern to Warehouse and Invoicing Flows

• Rather than have Fluent's own workflow block on invoice creation, the same decoupled approach
  applies: the integration layer, or a dedicated invoicing connector, creates and confirms the invoice
  synchronously on its own side, then reports back to Fluent with a “pack cleared” event once the
  invoice is confirmed. That event is what triggers the pack step in Fluent's workflow.
• The dependency between invoicing and packing is real and valid; it simply needs to be resolved
  outside Fluent's rule execution, in the layer designed to hold and manage that kind of external,
  synchronous dependency.

What Fluent Is and Isn't

• Fluent is a cloud native order management and fulfillment orchestration platform, purpose built to
  coordinate inventory, orders, and fulfillment across channels and locations at scale.
• Fluent is not an integration platform, enterprise service bus, or iPaaS, and is not intended to replace
  one. Routing point to point, synchronous integrations through Fluent's rules blurs this boundary and
  tends to create fragile, hard to maintain architecture over time across the customer's landscape as
  a whole, not only within Fluent.
• Using a dedicated integration layer alongside Fluent, whether a commercial iPaaS such as
  MuleSoft or Boomi, or Fluent Connect, keeps each system doing the job it is designed for, and
  keeps the overall architecture easier to reason about, test, and evolve.

 References

• Connector Contract — docs.fluentcommerce.com/essential-knowledge/connector-contract
• Webhooks — docs.fluentcommerce.com/essential-knowledge/webhooks
• Payment Connector Contract — Fluent Commerce best-practice integration guidelines
• Integration layer examples: MuleSoft, Boomi, Fluent Connect

Summary and Recommendation

• Keep Fluent's core workflow asynchronous and event driven. This is fundamental to platform stability,
  scale, and reliability, and is not configurable on a per-customer basis.
• Where a third party system genuinely requires a synchronous interaction as payment providers and
  some WMS platforms do, they place that interaction in a dedicated integration or middleware layer, and
  connect it back to Fluent using the standard webhook request / response event pattern.
• This approach delivers the functional outcome the business needs. This includes funds captured and an invoice confirmed before packing, without compromising the resilience of the order management workflow
  that coordinates it.