Thanks to visit codestin.com
Credit goes to developers.redo.com

Skip to main content

​
Overview

The Loop-Compatible API lets an existing Loop Returns warehouse integration work with Redo. It preserves Loop’s endpoint paths and response shape while reading and updating Redo returns.

​
Choose a version

Use this base URL:
v2 improves financial calculations, line-item refund allocation, exchange metadata, return comments, and status outcomes.
The /api/v1/warehouse portion is part of the Loop-compatible route. The preceding /redo/v2 or /redo/v1 selects Redo’s compatibility implementation.

​
Authentication

Create an API client in the Redo Dashboard under Settings → Developer → Add API Client. Send its secret as a Bearer token:
Read endpoints require the returns read scope. Endpoints that change a return require the returns write scope. See Authentication and Scopes for details.

​
Endpoints

Append these paths to the base URL for your selected version.

​
Returns

​
Notes and reporting

Loop’s close operation maps to rejecting/canceling a Redo return. Loop’s cancel operation maps to resetting a Redo return.

​
Identify a return

For a route containing :return_id, pass the numeric Loop-compatible id returned by the API:
You can instead identify a return with one of these query parameters: For example:

​
List and ASN filters

GET /return/list accepts: GET /reporting/asn supports from, to, pageSize, state, and cursor.

​
Pagination

For return lists in either version, send paginate=true. The API returns an object with the current records and, when another page exists, a URL to request it:
The same value is also provided in the nextPageUrl response header. Follow that URL until the next-page value is absent. Add paginate=true to each subsequent request if you want every return-list page to retain the wrapped { returns, nextPageUrlString } response; otherwise subsequent pages use the array response. ASN responses always remain an array and provide the next page through the nextPageUrl header. Without paginate=true, /return/list returns an array.

​
v2 response behavior

v2 keeps the Loop-compatible response structure, including numeric id and string redo_id, but corrects how important fields are populated.

​
Financial fields

All monetary values are decimal strings with two digits after the decimal point. At the line-item level, v2 reports the original price, the item’s discount and tax, and allocates refund, refund_item, and refund_tax proportionally when only part of the return is refunded.

​
Other corrected fields

  • outcome reports upsell when a customer charge exists; otherwise it distinguishes refunds, store credit, exchanges, and combined outcomes.
  • Advanced exchanges include parsed numeric product and variant IDs, sku, title, discount, allocated tax, and total when available.
  • line_items[].return_comment contains the shopper’s non-empty return-form answers, joined with line breaks.
  • line_items[].weight_in_grams is always numeric, and missing barcodes use an empty string.
  • Shipment labels include only shipments with a carrier, status, and tracking number, and associate the matching line-item IDs.
  • ASN purchase price and outcome use the same v2 return-accounting totals as return details.

​
Upgrade from v1 to v2

  1. Change only the base path from /api/v1/warehouse (or /redo/v1/api/v1/warehouse) to /redo/v2/api/v1/warehouse.
  2. Keep the same credentials, scopes, endpoint suffixes, return identifiers, and write-operation payloads.
  3. Update any reconciliation logic or assertions that depend on financial values. v2 intentionally changes the totals and line-item values described above.
  4. Verify consumers tolerate the newly populated return_comment and exchange metadata fields and the corrected outcome priority.
Do not compare v1 and v2 financial fields for exact equality. The changed values are the primary compatibility fix in v2, not a formatting-only change.
Redo follows Loop’s observed API behavior when Loop’s public documentation and actual responses differ.