Use cases

An internal service answers in a shape new callers cannot consume. The flow takes the new request, translates it, calls the old service, and composes the response.

• What it covers

  The backend’s status can become the response’s status, declared by the flow. The backend’s error body is available to the flow, so an error can be translated rather than merely propagated. Response headers are dictated by the flow, and those coming from the backend return only through a declared allowlist.

• What it does not cover

  If the legacy service is SOAP and the new caller needs a typed contract generated by the platform, the published contract is loosely typed. That is a limit, not a setting.

A system emits events it cannot wait on. The platform accepts them, queues them, and delivers them onward, with retries.

• What it covers

  The queue has its own write-ahead log: an accepted message survives a crash, and a scheduled retry survives a restart. A delivery that exits through the fault sequence is not committed as a success.

• What it does not cover

  Delivery is at least once, not exactly once. The queue does not prioritise and does not reorder. And a fault sequence that succeeds acks the message, which disarms the retry — if you want both, the handler has to fail deliberately.

A partner takes a request and answers later, on another channel. The platform has to know what the answer refers to when it arrives.

• What it covers

  Request/late-response correlation is declared in the flow and carries a mandatory deadline — an open-ended wait is a leak, not a policy. An overdue one is reconciled, and open waits can be listed from the command line. Declarative deduplication stops a second delivery of the same key from running the flow again.

• What it does not cover

  A response replayed from a deduplication record replays the body and content type, not the headers the flow wrote. And when a duplicate re-runs a previously failed flow, effects already consumed are repeated.

Two services speak gRPC, and something between them has to translate, route, or hold a retry policy.

• What it covers

  gRPC egress works with dynamically loaded descriptors, mutual TLS, a cascade of endpoints and a per-endpoint circuit breaker. The gRPC inbound door routes the call through the same gate and the same delivery bracket as the HTTP door.

• What it does not cover

  Streaming is explicitly refused on the inbound door. The routing table is built at start-up, so a flow published afterwards needs a restart. A fault sequence cannot deliver its body over the gRPC door.

A service provider runs integrations for several customers on the same platform.

• What it covers

  The tenant is a registered entity, created deliberately; a typo does not become a tenant. A library reference resolves within the caller’s tenant. An unknown tenant and a disabled one answer identically from outside. The UI has roles with an enforced boundary, verified route by route.

• What it does not cover

  Tenants share one installation: the same engines, the same state directory, the same retention window. The rate ceiling is configured per credential, not per organisation, so a customer with many keys is sized key by key.

A team wants a wrong integration to fail at publication, not at the first message on Monday morning.

• What it covers

  XSLT outside the supported subset, a malformed routing block, an illegal flow name or an invalid literal status are refusals at publication. A declared configuration key the installation does not supply stops the boot, naming the key.

• What it does not cover

  There is no bit-exact replay of a past delivery, so yesterday’s traffic cannot be replayed over today’s artifact as a form of regression testing.

• ContactSend us your case, with the systems and protocols involved.