Redo
Redo is a returns and exchanges platform popular with Shopify merchants offering covered or "free" return programs. The integration is bi-directional: Pinch ingests every return Redo creates, scores it, and writes the decision back as a Shopify customer tag that Redo reads inside its policy engine.
What data Pinch gets from Redo
Pinch subscribes to Redo'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 | Wardrobing, switch-fraud, size-abuse signals |
| Return method (mail-in, drop-off, in-store, instant exchange) | Differentiating risk by return channel |
| Return state transitions (created → label issued → in transit → received → resolved) | Time-in-transit signals, return-tag-not-used detection |
| Whether the customer purchased Redo coverage at checkout | Differentiating risk on covered vs uncovered returns |
| Disposition / inspection outcome from Redo's receive step (when configured) | Disposition data when Redo is the source of truth |
Pinch receives these via Redo 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). Redo reads those tags inside its Return Flow.
Using Pinch tags inside Redo Return Flow
Redo's rule engine is called Return Flow and lives at Redo Admin → Settings → Return Flow. Unlike a flat rule list, Return Flow is a step-based flowchart — each return runs top-down through the steps, and Condition steps branch the flow into True / False paths. Redo's Condition step exposes an Customer tags type that reads Shopify customer tags directly. (Note: a separate "Rules" engine under Settings → Support → Rules is for Helpdesk tickets, not returns.)
Recommended Pinch-tag → Redo flow mapping (insert these Condition steps early in your Return Flow so they catch before the default path):
| Pinch tag | Redo condition step | Redo true-branch action |
|---|---|---|
pinch-deny | Customer tags = pinch-deny | Reject with custom rejection message |
pinch-review | Customer tags = pinch-review | Mark for manual review (route to support inbox) |
pinch-vip | Customer tags = pinch-vip | Restrict outcome to no restocking fee; apply store-credit bonus; allow instant exchange |
pinch-suspect-abuse | Customer tags = pinch-suspect-abuse | Restrict outcomes to Store Credit or Exchange only; apply restocking fee |
pinch-first-order | Customer tags = pinch-first-order | Route to a separate flow branch with extra exchange-incentive copy |
| Default (no Pinch tag) | — | Standard Return Flow |
Concrete example — set up the deny step:
- Redo Admin → Settings → Return Flow
- Drag in a Condition step at the top of the flow
- Type: Customer tags, value:
pinch-deny(case-sensitive — must match what Pinch writes exactly) - True branch → drag in a Reject step with a customer-facing rejection message
- False branch → continue into the rest of the flow
- Save
Stack the other Pinch-tag Condition steps in priority order: pinch-deny first, then pinch-review, then VIP/treatment branches.
How to connect
In the Pinch dashboard, go to Integrations → Returns System → Redo. Paste API credentials from your Redo admin. Pinch verifies the connection and begins ingesting events within a few minutes.
See also
- Disposition data — what Pinch does with Redo's inspection outcomes
- Workflows — where Redo return data is evaluated
- Install on Shopify — the customer-tag writeback path Redo reads from