Reference · built on requestConnectorShipping & logistics

Loop Returns

Return and exchange records, label status, warehouse ASN reports, and return webhooks from the Loop Returns API.

Request accessPricing ↗

About

Loop Returns runs the returns portal and return policy for ecommerce merchants: a customer starts a return or exchange, Loop issues the label, and the outcome is a refund, store credit, gift card, or exchange order. The API lists returns by state, open, closed, cancelled, expired, or review, with the refund, exchange, and credit totals, label_status, carrier, and tracking_number on each. The ASN report lists every inbound package by tracking status with its destination warehouse and the items expected. Webhooks fire on return.created, return.updated, return.closed, label.created, label.updated, and restock.requested.

With Fibric, an operator reads those returns and proposes which to flag for review, which to process, and where the restock goes.

This is a reference listing. It documents what Fibric would read from Loop Returns and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Returns from GET /warehouse/return/list with state, outcome, line_items, exchanges, refund, gift_card, and exchange_credit_total
  • label_status, carrier, and tracking_number on each return, filtered by created_at or updated_at and paged by cursor
  • The ASN report from GET /warehouse/reporting/asn: inbound packages by tracking status with destination warehouse, SKU, and return reason
  • Webhook triggers return.created, return.updated, return.closed, return.processing.failed, label.created, label.updated, restock.requested, and giftcard.requested
  • Orders, destinations, and the blocklist and allowlist items configured for the shop
  • Label requests and their status

Proposed actions

  • Target capability: propose flagging a return through POST /warehouse/return/{id}/flag so it waits for a person in the Loop admin
  • Target capability: propose processing a return through POST /warehouse/return/{id}/process, which archives it and places exchange orders or gift cards
  • Target capability: propose cancelling a return through POST /warehouse/return/{id}/cancel so the customer can start over with the same items
  • Target capability: propose a label request through the Label API, which needs OAuth 2.0

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Hold the return that needs a person

    Read return.created, check the line items and outcome against your policy, and propose the flag. Flagged returns stop automated processing until someone reviews them in the Loop admin.

    With Returns Triage

  • Know what is coming back before it arrives

    Pull the ASN report by tracking status and propose the receiving plan per destination: which SKUs, how many, and whether a restock request is expected.

    With Return Restock, Restock Routing

  • Process once the warehouse confirms

    When the warehouse marks the items received, propose the process call. Loop archives the return and places the exchange order or gift card; the return.closed webhook confirms it.

    With Refund Policy

Requirements

  • A Loop merchant account with an API key that carries the returns scope
  • OAuth 2.0 credentials for the Label API and the Webhooks API
  • An endpoint that answers 200, 202, or 204 within 10 seconds for each webhook
  • Destinations configured in Loop so ASN rows carry a warehouse
Authentication
An API key in the X-Authorization header, generated in the Loop admin under Returns Management > Tools & integrations > Developer Tools, with scopes such as returns, orders, and destinations:read; the Label API and Webhooks API use OAuth 2.0 instead.

Limits

  • 300 requests per minute per API key on average; more returns 429 Too Many Requests
  • Processing is queued, not immediate: success arrives as the return.closed webhook, and a closed or flagged return is refused
  • Webhooks are delivered at least once, so duplicates happen; Loop may add payload fields without notice
  • A return with an open instant-refund credit is skipped by the process call

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Loop Returns ↗

Questions and answers

Which webhook triggers does Loop offer?
return.created, return.updated, return.closed, return.processing.failed, label.created, label.updated, restock.requested, giftcard.requested, and shipment.processed, grouped under the Return, Return processing, Label, Restock, Gift card, and Happy Returns shipment topics. Your endpoint must answer 200, 202, or 204 within 10 seconds; failures retry up to five more times.
Does processing a return issue the refund?
Processing queues the return: Loop archives it and fulfils remaining outcomes such as placing exchange orders or creating gift cards. Success is confirmed by the return.closed webhook. A closed return is refused with UNPROCESSABLE_RETURN, and a flagged one with UNPROCESSABLE_FLAGGED_RETURN unless flagged-return processing is enabled.
What states can a return be in?
open, closed, cancelled, expired, or review. The list endpoint defaults to open, closed, and expired, and filters by created_at or updated_at over a from and to range. Cancelling a return lets the customer make another return with the same items.
Ask about Loop Returns

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Loop Returns through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy