Skip to main content
Order returns in Base work analogously to orders and have their own mirrored block of API methods. You can download, filter, and manage returns using dedicated endpoints that closely mirror the patterns you already know from working with orders.

​
The main method: getOrderReturns

getOrderReturns downloads returns from Base from a given date, with a maximum of 100 records per call, the same pagination principle as getOrders.
Unlike orders, there is no confirmed/unconfirmed concept for returns: no date_confirmed field exists. Page through results using date_from or id_from.
As with order pagination (see Downloading Orders), there’s no guaranteed compound cursor here either: date_from is only accurate to the second. Advancing the cursor past the last processed timestamp (+1 second) can skip a return that shares that exact second. Prefer the same overlap and de-duplicate pattern: reuse the last record’s date_from value on the next call and de-duplicate on your side by return_id.

​
Key response fields

These bank fields are structured around European identifiers (IBAN/SWIFT); there’s no dedicated US ABA/routing-number field. In most US flows, refunds go back through the original payment method (credit card, PayPal, etc.) via your payment provider rather than by bank transfer, so these fields typically won’t apply. If your refund flow does use a direct bank transfer, order_return_account_number is the field to populate; confirm with your payment or refund provider how to map that to a US account and routing number pair. Either way, see the warning below: recording a refund in Base is a separate step from actually moving the money.

​
Working with statuses and refunds

Return statuses are read and written analogously to orders:
setOrderReturnRefund does not trigger any actual payment. It only records the refund information inside Base. Any real money transfer must be handled through your payment provider separately.

​
Tracking changes over time

Just like orders, returns have their own journal. Use getOrderReturnJournalList to poll for recent changes; it follows the same principle and activation requirement as getJournalList for orders.
You must enable journal access in your Base account before using this endpoint: go to Profile → API and activate the journal for returns.

​
Returns from marketplace channels

For selected marketplace channels, Base can automatically fetch return requests directly from customers and create returns from them. This is configured per sales channel in the Base panel. Once enabled, you simply monitor new returns as described above; no additional API calls are needed to pull them in.

​
Return shipping labels

If you also handle return shipping, the principle is identical to generating standard shipment labels. Use the same shipping label methods, but pass return_shipment: true in your request. See Shipping Labels for full details.