Loop Returns
Loop Returns is one of the most common RMS platforms Pinch merchants run. The integration is bi-directional: Pinch ingests every return Loop creates, scores it, and writes the decision back as a Shopify customer tag that Loop reads inside its policy engine.
What data Pinch gets from Loop
Pinch subscribes to Loop's return events and pulls the following on each return:
| Data | Used for |
|---|---|
| Return ID, parent order ID, customer email | Linking the return to the order and the Pinch Identity |
| Line items being returned (SKU, quantity, price, reason code) | Workflow conditions, abuse-pattern detection |
Customer-stated return reason (e.g. too small, defective, changed mind) | Wardrobing, switch-fraud, size-abuse signals |
| Return method (mail-in, in-store, instant exchange) | Differentiating risk by return channel |
| Return state changes (created → label issued → in transit → received → resolved) | Time-in-transit signals, return-tag-not-used detection |
| Disposition / inspection notes from Loop's warehouse-receiving step | Disposition data when Loop is the source of truth |
Pinch receives these via Loop's webhooks (live) plus a historical backfill on first connect.
What Pinch writes back
Pinch writes the decision back to Shopify as customer tags (e.g. pinch-allow, pinch-review, pinch-deny, plus Sub Decision labels like pinch-suspect-abuse or pinch-vip). Loop reads those tags inside its Workflows engine.
Using Pinch tags inside Loop Workflows
Loop's rule engine is called Workflows and lives at Loop Admin → Returns management → Policy settings → Workflows. Each workflow has one or more Conditions plus an Outcome (Action). Loop exposes a first-class Customer — Tag condition that reads Shopify customer tags directly, so Pinch's tags drop in cleanly.
Recommended Pinch-tag → Loop workflow mapping:
| Pinch tag | Loop workflow | Loop outcome |
|---|---|---|
pinch-deny | Conditional outcomes — Customer Tag equals pinch-deny | Reject item with custom rejection message |
pinch-review | Conditional outcomes — Customer Tag equals pinch-review | Manual review (route to Loop's manual queue) |
pinch-vip | Conditional outcomes — Customer Tag equals pinch-vip | Waive handling fee + offer Shop Now bonus / store-credit incentive; extend return window |
pinch-suspect-abuse | Conditional outcomes — Customer Tag equals pinch-suspect-abuse | Exclude refund outcome (Exchange-only or Store-credit-only); add handling fee |
pinch-first-order | Conditional outcomes — Customer Tag equals pinch-first-order | Offer Shop Now bonus to encourage exchange instead of refund |
| Default (no Pinch tag) | — | Standard return policy |
Concrete example — set up the deny rule:
- Loop Admin → Policy settings → Workflows → + New workflow
- Template: Conditional outcomes
- Condition: Customer — Tag equals
pinch-deny - Outcome: Reject item → add a customer-facing rejection message (e.g., "This order isn't eligible for self-serve return — please contact support.")
- Publish
Loop evaluates workflows top-down, so place Pinch-tag workflows above your default policy so deny / review decisions catch first.
How to connect
In the Pinch dashboard, go to Integrations → Returns System → Loop. Paste an API key from your Loop admin (Loop → Settings → API). Pinch verifies the key and begins ingesting events within a few minutes.
If you're on Shopify, the customer-tag writeback is already in place because the Pinch Shopify app handles tagging — Loop just needs the policy conditions configured on its side.
See also
- Disposition data — what Pinch does with Loop's inspection notes
- Workflows — where Loop return data ends up being evaluated
- Install on Shopify — the customer-tag writeback path Loop reads from