The useful gain is not another endpoint. It is a receipt that lowers the cost of believing the handoff worked.
Use case
External webhooks into Shopify Flow.
A webhook is easy to send. The harder question is whether the store team can trust what happened when the outside event was supposed to become a Shopify Flow trigger.
Operators keep workflow logic in the native system they already inspect.
A receipt gives support, partners, and authorized agents enough context without exposing raw payloads.
What changes
A successful HTTP request can still leave the operator guessing.
Sender logs usually explain transport. They often do not show which Shopify Flow trigger was expected, which endpoint settings were active, whether the workflow was ready, or what is safe to try next.
FlowRelay role
FlowRelay turns the boundary into an operating record.
FlowRelay receives the outside JSON event, verifies the sender, validates expected fields, records endpoint and mapping context, and hands the trigger to Shopify Flow with a receipt the team can inspect later.
Evidence to check
First-event verification checklist
Use the first event to prove the handoff, not just to prove that an endpoint returned a status code.
Sender
Signed request or static-header check passed.
The store can trust where the event came from before Shopify Flow acts.
Endpoint
Trigger family, required fields, and mapping are visible.
The event has Shopify Flow meaning, not only JSON shape.
Handoff
Delivered records the FlowRelay-to-Shopify Flow handoff.
Downstream workflow outcomes remain in Shopify Flow, but the boundary is no longer vague.
How to start
Prove one useful event before widening the path.
A small first event makes the setup feel governable. Pick something real enough to matter and safe enough to test.
-
01
Name the sender
Record the outside system, event name, owner, expected volume, and Shopify Flow trigger family.
-
02
Create the endpoint
Choose authentication, required fields, and the FlowRelay trigger variant Shopify Flow will use.
-
03
Send a safe event
Use a low-risk example without secrets, copied customer records, or irreversible downstream actions.
-
04
Read the receipt
Confirm auth, validation, mapping, Flow readiness, and handoff before production traffic depends on it.
Current-path check
Verify the current path before changing it.
Before changing a sender, list the outside system, current receiver, intended Shopify Flow trigger, owner, rollback path, evidence source, confidence level, and any access gaps. FlowRelay, Shopify Sidekick, and authorized agents cannot automatically discover every existing webhook app, Zapier or Make scenario, middleware route, serverless function, or receiver unless those systems are available to inspect. If the current environment is incomplete, start with one low-risk event and document what is unknown.
Boundary
Delivered means handoff, not downstream success.
FlowRelay can prove it handed the trigger to Shopify Flow. Shopify Flow and downstream apps still own branches, actions, emails, fulfillments, tags, refunds, and later business outcomes.
- Use FlowRelay receipts for intake and handoff evidence.
- Use Shopify Flow run history for workflow conditions and actions.
- Use downstream system logs for actions that happen after Shopify Flow.
Questions
Common questions.
Can FlowRelay trigger Shopify Flow from an external system?
Yes. A sender can post an authenticated JSON event to FlowRelay, then Shopify Flow can run from the matching FlowRelay trigger.
Does FlowRelay replace Shopify Flow?
No. FlowRelay handles external-event intake, receipt facts, replay context, diagnostics, and governed access. Shopify Flow remains the workflow engine.
Do public examples need raw payloads?
No. Public proof should use receipt facts, endpoint settings, mapped fields, support codes, and redacted diagnostics.