Loop Returns Integration

The Loop Returns integration automates the return lifecycle between Loop Returns, Shopify, and Logiwa. When a shopper starts a return in Loop, Logiwa creates a matching Return Order (RMA). The warehouse then receives and inspects the item in Logiwa's Return Station. Once processing is complete, the result is sent back to Loop so the return can be processed normally or sent for merchant review.

⚠️ Native Shopify Requirement: The standard Loop Returns integration was designed around Logiwa's native Shopify integration. If Shopify orders enter Logiwa through an ERP, OMS, middleware platform, custom API integration, or another non-native flow, contact Logiwa before onboarding — a custom workflow may be required.

💡 Getting Started: For a standard native-Shopify implementation, the main setup items are straightforward: connect Loop with an API key, confirm the SPY- order relationship is present, create the Return Station location, configure return reasons, and run one accepted and one flagged return through UAT.

The Loop API key is created from the Loop Admin portal.

4. Enter a descriptive name for the key (for example, Logiwa Integration).

5. Select all scopes.

6. Generate the key and copy it securely for the Logiwa connection.

🔒 Credential Security: Treat the Loop API key as a password. Store it securely and only share it with authorized integration administrators.

A Logiwa Return Order must be linked to the original Shipment Order. The standard Loop workflow needs a reliable way to identify the Shopify order that was originally shipped from Logiwa.

When Logiwa's native Shopify integration imports a Shopify order, Logiwa uses Shopify's internal order ID and stores the Shipment Order Code with the prefix SPY-.

The Loop workflow uses this relationship to locate the original shipped Shipment Order before it creates the Return Order.

⚠️ Clients Using a Non-Native Shopify Order Flow: If your Shopify orders enter Logiwa through an ERP, OMS, middleware platform, custom API integration, or another non-native process, the Logiwa Shipment Order Code may not contain the Shopify internal order ID in the expected SPY-{Shopify Order ID} format. In that case, the standard Loop workflow may not be able to locate the original Shipment Order. Contact Logiwa before onboarding so the order-matching design can be reviewed. A custom workflow may be required.

Before warehouse users can process Loop returns, create a dedicated location in Logiwa for return processing. This location represents the physical area where returned items are inspected and received.

💡 A Return Station location should be configured before UAT or production activation. Warehouse users will select the receiving warehouse and Return Station when processing RMAs.

Return Reasons control how warehouse inspection results are communicated back to Loop. Configure the required reasons in Logiwa under Settings > Data Setup > Return Process > Return Reasons.

⚠️ Important: Return Reasons in Logiwa should match exactly with the Return Reasons set up in Loop Returns. Ask the client to provide the list of return reasons configured in their Loop account.

Normal accepted reasons are used for returns that should process without merchant review. Six exception reasons (below) are reserved for cases that should be flagged in Loop, such as a warehouse rejection.

Direction: Loop Returns → Logiwa
​What Happens: New/unprocessed Loop returns are retrieved and created in Logiwa as Return Orders (RMAs).

Direction: Within Logiwa

If the warehouse rejects an item or identifies an exception requiring merchant review, select one of the six flag-triggering Actual Return Reasons:

ℹ️ Reminder: These six reasons must be set up inside Logiwa under Data Setup and must match exactly with the reasons configured in Loop.

Once sent, the return is placed into a review state rather than automatically accepted.

Exception Scanning Scenarios

Some scenarios require recording an outcome even when the scanned product doesn't match the item expected on the Loop return. If your operation uses dedicated exception barcodes, create the corresponding scannable SKUs in Logiwa before UAT (these are warehouse processing tools and are not added to the Loop return).

⚠️ A dedicated exception SKU is only needed when the warehouse process requires a scannable placeholder. If the actual item can be scanned, use the actual SKU with the appropriate Actual Return Reason. During UAT, confirm how exception-SKU receipts affect Logiwa inventory and define the warehouse cleanup process if needed.

💡 Example — Empty Box: Loop expects SKU12345. The warehouse scans EMPTY_BOX, selects Empty Box, adds a note/photo, and finishes the return. The integration sends those inspection details back against the SKU12345 Loop line and flags the return for merchant review.

Mixed Returns: Accepted and Rejected Items

A single RMA can contain both accepted and rejected items. Accepted lines are received normally; rejected/exception lines use a flag-triggering reason with supporting note/photo. The integration preserves accepted lines, grades only the rejected lines, and flags the entire return for merchant review.

⚠️ For mixed returns, any rejected/exception line flags the entire Loop return for merchant review, even when other lines were accepted.

Direction: Logiwa → Loop Returns
​What Happens: Completed Logiwa returns are sent back to Loop as processed, or flagged for review, depending on warehouse outcome.

Direction: Loop Returns → Logiwa
​What Happens: A shopper may cancel a return in Loop after the RMA has already been created in Logiwa. A separate cancellation workflow checks Loop for newly cancelled returns, locates the matching Logiwa Return Order, validates its current status, and cancels it in Logiwa when still allowed.

ℹ️ Cancellation direction (Loop → Logiwa) is separate from the completed-return workflow, which sends warehouse outcomes from Logiwa → Loop.

The workflow validates returns before creating or updating RMAs. Duplicate RMAs and return-creation failures are logged so the same return is not created repeatedly.

What happens if the received quantity exceeds the PO quantity?
This scenario is specific to standard receiving, not Loop returns — see the Return Guide for general receiving edge cases.

Can I use this integration if my Shopify orders come in through an ERP or middleware instead of Logiwa's native Shopify integration?
Not by default. The standard workflow relies on the SPY- order-matching pattern created by Logiwa's native Shopify integration. Contact Logiwa before onboarding — a custom workflow may be required.

Do I need dedicated exception SKUs like EMPTY_BOX or NON_RETURNABLE?
Only if your warehouse process requires a scannable placeholder when the actual item can't be scanned. If the actual item is available to scan, use it with the appropriate Actual Return Reason instead.

What happens if only part of a multi-line RMA is rejected?
Accepted lines are preserved and processed normally. Any rejected or exception line flags the entire Loop return for merchant review, even though other lines were accepted.

💡 Getting Started: For a standard native-Shopify implementation, the main setup items are straightforward: connect Loop with an API key, confirm the SPY- order relationship is present, create the Return Station location, configure return reasons, and run one accepted and one flagged return through UAT.