FlowRelay FlowRelay Docs Shopify Flow
All docs pages

START

USE CASES

SET UP

OPERATE

RECOVER

AGENT ACCESS

REFERENCE

Markdown

Move one client event into Shopify Flow with proof and rollback

Plain Markdown for agents, CLIs, MCP clients, and readers who want a copyable text version.

# Move one client event into Shopify Flow with proof and rollback

Canonical: https://docs.flowrelay.app/use-cases/agency-developer-partner-kit/
Markdown: https://docs.flowrelay.app/use-cases/agency-developer-partner-kit.md

Move one outside system into Shopify Flow with one FlowRelay endpoint, one matching trigger, one receipt, one rollback owner, and no private-data scavenger hunt.

## When a partner should use this
Use this page when a merchant wants a partner, Shopify developer, implementation team, or technical operator to set up or move one external event path into Shopify Flow. The goal is a small proofable path: the sender knows where to send, the merchant knows what FlowRelay received, the Shopify Flow owner knows what to check, and everyone knows who can roll back.

- [First endpoint guide](https://docs.flowrelay.app/getting-started/first-endpoint/): Use for a brand-new FlowRelay event path.
- [Swap over to FlowRelay](https://docs.flowrelay.app/use-cases/swapover-to-flowrelay/): Use when replacing an existing receiver, webhook app, custom-code path, or manual process.

## One event path checklist
Keep the first path small enough to verify in one sitting. If the sender, authentication, mapping, or Shopify Flow workflow needs adjustment, the receipt and rollback owner should make the next step obvious.


- Field: Sender and event purpose; Fill this before cutover: System owner, event name, expected volume, criticality, and whether this is new setup or replacement.; Use this doc: First endpoint guide or Swap over to FlowRelay
- Field: Shopify Flow target; Fill this before cutover: Trigger variant, required payload paths, safe test workflow, and downstream result check owner.; Use this doc: Trigger variants and mapping
- Field: Proof; Fill this before cutover: Accepted or Delivered receipt, support code if any, replay state, diagnostics share readiness, and separate Shopify Flow check.; Use this doc: Read receipts
- Field: Rollback owner; Fill this before cutover: Named person or team that can restore the old sender URL/auth path during the agreed window.; Use this doc: Swap over to FlowRelay
- Field: Support boundary; Fill this before cutover: Diagnostics share path, support contact path, and the private data nobody should request or paste.; Use this doc: Share diagnostics and Work with support
- Field: Plan fit; Fill this before cutover: Expected accepted events, replay/diagnostics needs, Agent Access usage, and whether monthly or annual approval fits production use.; Use this doc: Usage limits and Pricing

## Give an agent a narrow brief
When the merchant authorizes an agent to help, keep the brief narrow: one event path, one scoped grant, and clear stop points before changes that could affect production or billing. Keep tokens and secrets in the agent client's private secret store or environment.

### Partner agent brief
Use after the merchant creates a scoped Agent Access grant.

```text
You are helping [merchant/store] set up or move one external event path into Shopify Flow through FlowRelay. Read https://docs.flowrelay.app/use-cases/agency-developer-partner-kit/ first.

Work only inside the merchant-authorized, store-scoped Agent Access grant. Confirm whoami, plan usage, endpoint state, trigger mapping, and the exact event path before changing anything.

Stop for operator approval before sender URL or auth changes, Shopify Flow workflow changes, billing approval, grant changes, replay, diagnostics sharing, support submission, or production traffic.

Do not ask for endpoint secrets, auth headers, HMAC values, Shopify tokens, session data, raw event bodies, customer records, copied private logs, screenshots with private values, or store passwords. Use receipt IDs, support codes, diagnostics share IDs, redacted summaries, approximate timestamps, endpoint names, intended workflow descriptions, and refusal details.

Final summary: sender, endpoint, trigger variant, proof receipt, Shopify Flow result check owner, rollback owner, plan fit, unresolved approvals, and next safe action.
```


## Share evidence, not private data
Partners should work from FlowRelay receipts, support codes, and diagnostics shares, not from copied payloads or screenshots of private configuration. Diagnostics can show the receipt, endpoint state, replay context, and recovery guidance after merchant approval.

- [Share diagnostics](https://docs.flowrelay.app/recover/diagnostics/): Preview-first redacted diagnostics sharing.
- [Work with support](https://docs.flowrelay.app/recover/support-signals/): What support can use and what should stay private.
- [Public support page](https://flowrelay.app/support/): Support paths for installed stores, pre-install questions, partners, and authorized agents.

## What not to ask merchants for
Do not ask for raw event bodies, endpoint secrets, static-header values, full authentication headers, HMAC values, Shopify tokens, Shopify sessions, customer data, copied private logs, browser storage, cookies, database URLs, or screenshots containing private values. If those seem necessary, stop and use diagnostics, a receipt ID, a support code, a redacted summary, or a merchant-run sender resend instead.


## Check plan fit before production
Before production traffic moves, check expected event volume, diagnostics needs, replay use, and Agent Access usage against the merchant's plan. Annual plans can make sense when the workflow is production-critical and the first proof is clean, but Shopify billing approval remains a human Shopify-hosted step. Agents and partners can prepare the recommendation; they cannot approve charges silently.

- [Pricing](https://flowrelay.app/pricing/): Monthly and annual plan options for FlowRelay for Shopify Flow.
- [Usage limits](https://docs.flowrelay.app/operate/usage-limits/): Accepted events, diagnostics shares, replay executions, Agent Access safeguards, and paid-plan grace.

## Use the right entrypoint
Use a focused page for each job so the merchant does not receive a pile of generic docs.


- Job: Trigger Shopify Flow from an outside system with receipt proof; Start here: External events into Shopify Flow; Why: Explains the basic sender -> FlowRelay -> Shopify Flow boundary.
- Job: Move a custom webhook receiver to Shopify Flow without losing rollback; Start here: Swap over to FlowRelay; Why: Keeps the pilot path, proof, rollback owner, and cutover window explicit.
- Job: Why did my Shopify Flow not run?; Start here: Recover a failed handoff; Why: Starts from receipt facts, support codes, and the Delivered boundary.
- Job: Replay external events into Shopify Flow safely; Start here: Replay an event; Why: Requires retention, preview, authority, and side-effect review.
- Job: Partner-safe Shopify Flow webhook diagnostics; Start here: Share diagnostics; Why: Gives partners support-safe evidence without secrets or raw payloads.
- Job: Agent-ready Shopify Flow event setup checklist; Start here: Set up with an agent; Why: Gives authorized agents a governed setup path and stop conditions.

## Typical path
A typical path starts from the scenario, then moves into setup and verification.
1. Choose one event path first: one sender, one FlowRelay endpoint, one Shopify Flow trigger, one proof event, and one rollback owner.
2. Use the first endpoint guide for a new event path or the swapover guide for an existing webhook receiver, middleware path, serverless function, or manual handoff.
3. If an authorized agent will help, give it the agent-safe setup or endpoint-swap guide and a scoped, time-bounded Agent Access grant.
4. Collect proof from FlowRelay receipts, support codes, replay availability, diagnostics share readiness, and a separate Shopify Flow result check.
5. Share diagnostics instead of raw event bodies, authentication headers, endpoint secrets, Shopify tokens, customer data, or copied private logs.
6. Use the pricing page and plan-usage view before production cutover so event volume, diagnostics, replay, and Agent Access safeguards fit the merchant's rollout.

## Handoff 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.

## Related
- [First endpoint guide](https://docs.flowrelay.app/getting-started/first-endpoint.md)
- [Swap over to FlowRelay](https://docs.flowrelay.app/use-cases/swapover-to-flowrelay.md)
- [Set up with an agent](https://docs.flowrelay.app/agent-access/setup-with-an-agent.md)
- [Endpoint swap plan](https://docs.flowrelay.app/agent-access/endpoint-swap-plan.md)
- [Share diagnostics](https://docs.flowrelay.app/recover/diagnostics.md)
- [Work with support](https://docs.flowrelay.app/recover/support-signals.md)
- [Usage limits](https://docs.flowrelay.app/operate/usage-limits.md)

## Safety Boundary
Do not include raw event bodies, endpoint secrets, authentication headers, HMAC values, Shopify tokens, Shopify sessions, database URLs, customer data, merchant incidents, or copied private logs in public examples.