Use Cases
Swap over to FlowRelay
Use this when one existing event lane works, but every failure still turns into guesswork across sender logs, middleware, Shopify Flow, and support notes.
Why swap over #
FlowRelay is useful when the brittle part is not just receiving a webhook. The hard part is knowing what arrived, what auth passed, what mapping was active, whether Shopify Flow was ready, whether a replay is safe, and what evidence support or an authorized agent can use without digging through scattered logs.
Safe migration sequence #
Use one pilot before the broader cutover. The sequence is: create endpoint, wire a test sender, enable the Shopify Flow workflow, send a test event, verify the receipt, then cut over the production sender. Do not change the sender URL/auth or production traffic before the receipt proof and rollback owner are clear.
| Step | Proof to collect | Stop if |
|---|---|---|
| Create endpoint | Endpoint name, trigger variant, auth mode, required mapping paths, and plan fit. | The trigger variant or required Shopify reference is unclear. |
| Wire test sender | Synthetic payload, private auth configuration, and expected external event ID behavior. | The sender owner cannot test without exposing secrets or customer data. |
| Enable Flow workflow | Matching FlowRelay trigger is enabled and the test action is safe. | The workflow might perform customer-visible or irreversible actions during the pilot. |
| Verify receipt | Accepted or Delivered status, support code if any, replay state, diagnostics-share availability, and downstream Flow check. | The result is no_workflow, mapping failed, auth failed, or downstream behavior is unconfirmed. |
| Cut over | Cutover window, rollback path, sender owner, monitoring cadence, and stop conditions. | Rollback cannot be performed quickly or plan capacity is not sufficient. |
What FlowRelay adds during migration #
Receipts make each event discussable. Replay previews show whether retained material can be handed to Shopify Flow again and what side effects may repeat. Diagnostics shares let a partner or support team inspect redacted setup and receipt facts. Idempotency helps suppress accidental duplicate sender retries and keeps approved actions tied to the preview that created them. Endpoint secrets keep sender access private, and Flow handoff status separates FlowRelay proof from downstream Shopify Flow behavior.
Why this saves operator work #
The slow part is not usually receiving the POST. It is proving what happened after someone asks why Shopify Flow did not do the expected work. Instead of retrying blindly or digging through logs, human and authorized agent operators can start from stable receipts, replay previews, diagnostics summaries, action previews, and reusable setup facts. FlowRelay does not claim a fixed token-savings percentage.
Do not attack the old path #
Treat the current webhook app, custom code, or manual process as existing infrastructure to replace carefully. The point is not that every older path is bad; the point is that FlowRelay gives the merchant a governed event boundary with receipts, recovery context, and support-safe evidence for Shopify Flow.
Cutover checklist #
Before production cutover, confirm: pilot endpoint is delivered, downstream Shopify Flow behavior was checked separately, production sender auth is ready, rollback owner is available, plan capacity fits expected traffic, diagnostics sharing is available, and support knows not to ask for raw payloads, endpoint secrets, auth headers, tokens, or session data.
Typical path
A typical path starts from the scenario, then moves into setup and verification.
- 01Inventory the current lane: sender, receiver, auth method, owner, event volume, criticality, current retry behavior, rollback path, and the Shopify Flow workflow you want to own the downstream logic.
- 02Choose one low-risk pilot lane before moving production traffic broadly.
- 03Create the FlowRelay endpoint and choose the matching trigger variant and authentication method.
- 04Wire a test sender or sandbox sender to the FlowRelay endpoint without changing the production sender yet.
- 05Enable the matching Shopify Flow workflow with a harmless test action or controlled pilot branch.
- 06Send one synthetic test event and verify the FlowRelay receipt, support code, replay availability, and diagnostics-share path.
- 07Only after proof, cut over the production sender URL/auth for the pilot lane during an agreed window.
- 08Monitor event history, receipts, usage, and downstream Shopify Flow behavior, then expand lane by lane.
Delivered means FlowRelay handed the trigger to Shopify Flow. It does not mean downstream Shopify Flow branches, app calls, fulfillment changes, emails, or later systems completed.
FlowRelay