Skip to main content

Narvar

Narvar Returns is a returns experience platform used by larger Shopify and headless retailers. Pinch ingests every return Narvar creates, scores it, and writes the decision back as a Shopify customer tag that Narvar reads inside its policy engine.

What data Pinch gets from Narvar​

Pinch subscribes to Narvar's return events and pulls the following on each return:

DataUsed for
Return ID, parent order ID, customer emailLinking 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 reasonWardrobing, switch-fraud, size-abuse signals
Return method (mail-in, drop-off, in-store)Differentiating risk by return channel
Return state transitions (created → label issued → in transit → received → resolved)Time-in-transit signals, return-tag-not-used detection
Disposition / inspection outcome from Narvar's receive step (when configured)Disposition data when Narvar is the source of truth

Pinch receives these via Narvar 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). Narvar reads those tags inside its Eligibility Rules engine.

Using Pinch tags inside Narvar​

Narvar's tag-driven decisioning happens in two adjacent engines inside its Return & Exchange app:

  • Eligibility Rules — block, restrict, or modify what's offered on a return (path: Return & Exchange → Settings → Return Policy → Eligibility Rules).
  • Return Method Rules — route returns to different mail/drop-off carriers or apply shipping-label fees.
Customer-tag condition: verify with your Narvar CSM

Narvar's public docs don't explicitly confirm a "Customer Tag" condition primitive on Eligibility Rules. The conditions documented publicly scope to Order / Line Item / Customer. Most enterprise Narvar deployments do support arbitrary Shopify customer tags as a condition, but the rollout is gated through the Narvar implementation team. Confirm with your Narvar CSM before relying on this — and have them surface the tag primitive if it's not already exposed in your admin.

Recommended Pinch-tag → Narvar mapping (subject to the note above):

Pinch tagNarvar engineNarvar action
pinch-denyEligibility Rules — Customer Tag contains pinch-denyReturn Restriction (block return entirely)
pinch-reviewEligibility Rules — Customer Tag contains pinch-reviewRoute to manual review (typically via a custom restriction with CS escalation)
pinch-vipEligibility Rules — Customer Tag contains pinch-vipRestrict refund method to gift-card / store-credit waived, waive shipping-label fee, extend return window
pinch-suspect-abuseEligibility Rules — Customer Tag contains pinch-suspect-abuseHide exchange option (refund-only) or restrict to store-credit; apply shipping-label fee
pinch-first-orderEligibility Rules / Return Method RulesRoute to lower-cost return method or offer instant-credit bonus
Default (no Pinch tag)—Standard return policy

Most of these need to be configured by your Narvar implementation team during the integration. Ask them to:

  1. Confirm that Customer Tag is exposed as a condition on Eligibility Rules in your admin.
  2. Pre-create the five tag-condition rules above using your Pinch tag list (the Pinch team can share the exact tag set Pinch writes for your account).
  3. Order the rules so deny / review / restriction rules evaluate before any default policy.

How to connect​

In the Pinch dashboard, go to Integrations → Returns System → Narvar. Paste API credentials from your Narvar admin. Pinch verifies the connection and begins ingesting events within a few minutes.

See also​