Getting Started
First endpoint guide
Use this guide to prove one outside event reaches the Shopify Flow handoff before production traffic depends on it.
Steps
Complete these in order.
-
Start with one path
Start with one sender and one workflow. The basic path is external system -> FlowRelay endpoint -> Shopify Flow trigger -> FlowRelay receipt, then a separate Shopify Flow result check.
-
Gather the prerequisites
Before starting, make sure FlowRelay is installed, the sender owner is available, you can edit a safe Shopify Flow workflow, and you have a synthetic test payload that does not contain customer data.
-
Enter the endpoint identity
Enter an Endpoint name and Source label, such as Warehouse status to Flow and warehouse-partner, then choose which service will send the POST request.
-
Review the sender-aware recommendation
FlowRelay recommends static-header authentication with X-FlowRelay-Secret for Zapier, Make, and n8n. It recommends exact-body HMAC-SHA256 with X-FlowRelay-Signature for custom HTTP/code. The Generic trigger, external.event, and no Shopify data access remain the ordinary starting point.
-
Change the trigger only when needed
Open Change trigger when Flow needs a native Order, Customer, or Product reference, or the matching Inventory, Fulfillment, Return/refund, or Company/B2B context.
-
Open advanced controls only when needed
Open Advanced authentication and mapping when a capable sender needs a deliberate authentication override or the payload needs custom event types, JSON paths, identifiers, or required fields. FlowRelay warns when a standard no-code sender is paired with HMAC.
-
Add the Flow trigger
Add the matching FlowRelay trigger to a safe Shopify Flow workflow and enable it before sending the test event.
-
Prove the outside sender
Use the in-app self-test to check FlowRelay first, then send one synthetic event from the actual outside sender. Setup progress records those as separate milestones and does not treat the self-test as proof that the sender is configured.
-
Read the proof boundary
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.
-
Fix missing workflow readiness
If the receipt says no_workflow, enable the matching FlowRelay trigger in Shopify Flow, confirm the variant matches the endpoint, then preview replay while the event is retained or ask the sender to resend a fresh test event.
What you need #
You need a Shopify store with FlowRelay installed, access to create a Shopify Flow workflow or a teammate who can, a sender system owner who can configure URL and authentication, and one synthetic test payload. Do not use real customer, order, token, endpoint secret, HMAC, or session data for the first proof.
Choose Generic or a native reference trigger #
Generic is the simplest first proof when Shopify Flow only needs to react to a custom event. Choose Order, Customer, or Product when Shopify Flow should receive a native Shopify resource reference from the sender payload. Choose Inventory, Fulfillment, Return/refund, or Company/B2B when the workflow belongs in that FlowRelay event lane and the sender can provide the required related resource context.
| Workflow need | Suggested starting point | What to verify |
|---|---|---|
| Start a workflow from any external event. | Generic | The sender can send valid JSON and Shopify Flow can branch on the fields you mapped. |
| Operate on an existing Shopify order, customer, or product. | Order, Customer, or Product | The sender provides the Shopify ID or GID at the mapped payload path. |
| Handle inventory, fulfillment, return/refund, or company/B2B work. | The matching operational lane | The payload contains the related resource context FlowRelay needs for that trigger. |
Keep routing terms separate #
When more than one endpoint or workflow uses the same trigger variant, add Shopify Flow conditions for the endpoint Source label and the resolved Event type so only the intended workflow path runs.
| Term | Meaning |
|---|---|
| Source label | The endpoint routing identity surfaced to Shopify Flow. |
| Trigger variant | Selects the FlowRelay trigger payload and native-reference shape. |
| Default event type | The fallback event label used when no mapped event-type path supplies one. |
| Resolved event type | The mapped event-type value when present; otherwise the endpoint's default event type. |
Read the first receipt #
A receipt should answer what FlowRelay accepted, which endpoint configuration was active, whether authentication and validation passed, whether Shopify Flow readiness existed, and whether FlowRelay handed the trigger to Shopify Flow. It is not a Shopify Flow run log and it cannot prove that downstream Flow branches, emails, tags, inventory changes, or app actions completed.
If you see no_workflow #
no_workflow means FlowRelay accepted the event but did not find a matching enabled Shopify Flow trigger for that endpoint and variant. Fix the Shopify Flow workflow first: add or enable the matching FlowRelay trigger, confirm the trigger variant matches the endpoint, and save the workflow. Then preview replay if the event is still retained, or send a fresh test event from the sender.
First endpoint done criteria #
The first endpoint is ready for cautious production traffic when the external sender reaches FlowRelay, external authentication passes, the external event receipt shows Delivered, the merchant separately confirms any downstream Shopify Flow run behavior they care about, the sender owner knows where the endpoint URL and auth material live, and support knows to use receipt IDs or diagnostics shares instead of raw payloads.
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