What The Returns Dashboard Shows You

When you log in to Returns, you land on the main dashboard. This gives you a high level picture of how returns are behaving across your account.

You will see the following key widgets:

• Returns vs Orders
  A summary of how many orders have been placed versus how many returns have been booked, with an overall returns rate.

• Account Returns Breakdown
  A set of filters and totals so you can focus on particular brands, reasons, and time periods.

• Returns In Transit / Returns Completed
  Counts of returns by status to show how many parcels are on their way back and how many have been fully processed.

• Returns by Reason
  A breakdown of why customers are returning items.

• Returns by Sales Channel
  A breakdown of returns per sales channel such as Shopify, Amazon, or eBay.

When an account is new you will see zero values and “Awaiting your first return”. As customers begin to use the portal, these widgets update automatically.

Viewing Your Returns vs Orders

To read the top level performance:

1. Look at Orders Placed to see how many orders were created in the selected period.

2. Look at Returns Booked to see how many returns have been requested.

3. Check the Returns Rate to understand what percentage of orders are being returned.

This gives you an immediate sense of overall performance without needing to export or calculate anything yourself.

Using Account Returns Breakdown

To focus on a particular slice of returns:

1. Go to the Account Returns Breakdown section.

2. Set the From and To dates for the period you want to analyse.

3. If you operate multiple brands, choose a brand from the Brand dropdown.

4. If you want to analyse specific customer reasons, choose an option from Return Reason.

5. Select Apply to update the figures.

6. Use Clear to reset all filters and return to a full account view.

The totals for Orders Placed, Returns Booked, and Returns Rate will update to match the filters you have applied.

Tracking Returns In Transit And Completed

To monitor operational progress:

1. Find the Returns In Transit count. This is how many returns are on their way back to you based on courier scans.

2. Find the Returns Completed count. This is how many returns have been fully processed and marked complete.

3. Use these figures to see if returns are building up in transit or moving smoothly through to completion.

As your volumes grow, these indicators help you spot delays and keep your warehouse and customer service teams aligned.

Reading Returns By Reason And Sales Channel

Once you have data flowing:

1. Check Returns by Reason to see which reasons are most common.
   This helps identify product or sizing issues early.

2. Check Returns by Sales Channel to see which channels are driving the most returns.
   This is especially useful if you sell across marketplaces and web stores.

These widgets provide an at‑a‑glance view that feeds into product, merchandising, and marketing decisions while keeping everything centralised in one place.

Setting Up Chargeable Return Reasons

Use chargeable reasons when you want customers to pay for certain types of returns, such as “Change of Mind”.

What Chargeable Return Reasons Do

Chargeable reasons allow you to:

• Mark specific return reasons as chargeable.

• Automatically require payment before a shipping label is generated.

• Use your existing courier presets to define the shipping cost in the brand’s own currency.

If a return includes at least one chargeable reason for any item, the entire return will require payment.

Creating A Return Reason

To create or edit a return reason:

1. Open your brand settings and go to Return Reasons.

2. Select Create Return Reason or edit an existing one.

3. Enter a Name that customers will recognise on the portal.

4. Optionally upload a Photo if your portal design uses imagery.

5. Configure any Additional Input fields if you need extra information from the customer, such as size or notes.

Marking A Reason As Chargeable

To make a reason chargeable:

1. In the return reason form, find the Is Chargeable toggle.

2. Turn the toggle On to make this reason chargeable.
   By default it is off so existing reasons remain non‑chargeable unless you change them.

3. Confirm that your courier preset for the brand is configured with the correct shipping price and currency.

4. Save the return reason.

From this point, whenever a customer selects this reason on the portal, they will be asked to pay the shipping fee before the label is issued.

How Mixed Reasons Are Handled

If a customer returns multiple items:

1. The customer selects a reason for each line item.

2. If at least one line has a chargeable reason, the entire return is treated as chargeable.

3. The customer is required to complete payment for the shipping fee before submission.

4. If all selected reasons are non‑chargeable, the return behaves as a standard free return.

This behaviour keeps the customer journey simple while still enforcing your policies consistently.

Keeping Chargeable Reasons Transparent

To keep customers informed and reduce support contacts:

1. Use clear language in the reason name, for example “Change Of Mind (Customer Pays Return Postage)”.

2. Make sure your returns policy matches the behaviour in the portal.

3. Periodically review returns data by reason to see whether chargeable reasons are working as intended.

Chargeable reasons help you recover costs and reduce abuse while keeping all configuration central and auditable.

How Customers Book A Return

This article walks through the two‑step customer journey on the hosted returns portal.

Step 1: Select Items And Reasons

When a customer opens the returns portal and enters their details, they first choose what they want to send back.

1. The customer is shown their order with a list of items.

2. For each item they want to return, they:

   1. Tick or select the line item.

   2. Choose a return reason from the list you have configured.

   3. Optionally add notes to explain the problem.

   4. Optionally upload photos if your portal allows media.

Only items with a selected reason move through to the next step.

Step 2: Shipping And Payment

Once reasons are chosen, the portal moves to the shipping and payment step.

1. The customer is shown available shipping services for the return.

2. If at least one selected reason is chargeable:

   1. A payment section appears.

   2. The shipping fee is calculated from your courier preset.

   3. The price is shown in the brand’s configured currency.

   4. Available payment methods (for example, Stripe) are shown.

   5. The customer must complete payment successfully.

3. If all reasons are non‑chargeable:

   1. The customer simply selects a shipping service.

   2. No payment section appears.

In both flows, a shipping label is only generated once the step is complete.

Submitting The Return

After shipping and payment (where required):

1. The customer reviews a summary of their items, reasons, and chosen shipping method.

2. They confirm and submit the return.

3. The system:

   1. Creates a return record against the order.

   2. Issues a shipping label or instructions.

   3. Updates your Returns dashboard and any subscribed external systems.

This two‑step flow keeps the customer experience clean while giving you full control over when and how payments are collected.

Understanding Returns By Sales Channel

Sales channel attribution shows you where returns are coming from across your marketplaces and web stores.

How Sales Channel Attribution Works

Whenever a return is created:

1. The system looks up the originating order.

2. It reads the order’s channel information, for example Shopify, Amazon, or eBay.

3. It copies this information onto the return, tagging it with:

   • A human readable sales channel name such as “Shopify”.

   • A sales channel type identifier.

   • The sales channel id for the underlying record.

This process happens automatically without any manual input.

Reading Returns By Sales Channel On The Dashboard

To understand your returns by channel:

1. Open the Returns Dashboard.

2. Find the Returns by Sales Channel widget.

3. Review the breakdown of returns, grouped by channel name.

4. Use this information to:

   1. Compare performance between your channels.

   2. Spot channels with unusually high returns.

   3. Feed insight into merchandising, pricing, or listing decisions.

Because each return is tagged when it is created, you can trust that the attribution is consistent and repeatable.

Seeing Sales Channel On Individual Returns

In the Returns list and detail views:

1. Look for the Sales Channel field alongside:

   • Order number.

   • Return ID.

   • Customer details.

2. Use this field to quickly understand where the return originated.

3. Cross‑reference with your sales data if you need deeper analysis.

Having channel information right next to the operational data makes it simpler to reconcile returns with marketplace or web store reports.

Filtering Returns By Sales Channel

Where supported in your interface or API:

1. Use the Sales Channel or Sales Channel Type filters to narrow down returns.

2. Enter a specific channel name to focus on that source.

3. Use values such as “all” where supported to include every channel again.

This filtering makes it easy to create targeted worklists, for example reviewing only Amazon returns or only web store returns during a particular campaign.

Analysing Returns With Account Filters

Filters allow you to move from “big picture” to “specific story” without exporting data.

Choosing A Time Period

To focus on a particular period:

1. Open the Account Returns Breakdown section.

2. Set the From date to the start of the period you want to review.

3. Set the To date to the end of the period.

4. Select Apply.

The headline numbers update so you can compare periods such as pre‑ and post‑campaign, or peak versus off‑peak.

Filtering By Brand

If you operate multiple brands within Returns:

1. Use the Brand dropdown to select a specific brand.

2. Apply the filter.

3. Review the updated Orders Placed, Returns Booked, and Returns Rate for that brand only.

This lets you compare performance between brands without needing separate tools.

Filtering By Return Reason

When you want to understand why customers are returning items:

1. Use the Return Reason dropdown in the breakdown section.

2. Choose a specific reason such as “Too Small” or “Change Of Mind”.

3. Apply the filter.

4. Review:

   • How many orders were placed that resulted in this reason.

   • How many returns were booked with this reason.

   • The returns rate for this reason.

You can then decide whether to investigate product, fit, description, or policy changes.

Resetting Filters

To go back to a full view:

1. Select Clear in the Account Returns Breakdown section.

2. Confirm that all dropdowns have reverted to their default state.

3. Check that your totals and widgets now show all brands, reasons, and dates.

This keeps your analysis flexible while ensuring you can always return to a neutral starting point.

Connecting External Systems To Returns

Use the integration layer when you want ERP, finance, or warehouse systems to work directly with your returns data.

What The Integration Layer Provides

External systems can:

• Read return data using the Customer API.

• Receive real time webhook notifications when returns change status.

• Write back non‑destructive reference data, such as credit note references.

All activity is logged for audit and troubleshooting.

Reading Return Data By API

To read returns from an external system:

1. Generate or locate a Customer API key for the brand.

2. In your external system or Postman, call the List Returns endpoint:

   • Method: GET

   • Path: /returns

   • Auth: API Key.

3. Optionally:

   1. Pass a status query parameter to filter by return status.

   2. Use page parameters for pagination.

4. For a specific return, call Get Return:

   • Method: GET

   • Path: /returns/{id}

   • Auth: API Key.

Responses include line items, customer details, order information, return address, and any external references.

Subscribing To Webhook Notifications

To receive real time updates:

1. In your integration configuration, register a webhook endpoint URL that can accept HTTP POST requests.

2. Subscribe this endpoint to the events you care about:

   • Return Created.

   • Return Updated.

   • Return In Transit.

   • Return Completed.

3. For each incoming webhook:

   1. Read the full return payload in the body, which mirrors the API response shape.

   2. Verify the HMAC signature in the X-Webhook-Signature header.

   3. Return a successful status code from your endpoint if processing is successful.

The system will automatically retry deliveries with backoff if your endpoint is temporarily unavailable. Duplicate events are prevented by idempotency controls.

Writing Reference Data Back To Returns

To link returns to external records:

1. From your ERP, finance, or other system, call Update External References:

   • Method: PATCH

   • Path: /returns/{returnId}/references

   • Auth: API Key.

2. Include any of the supported fields in the body, for example:

   • credit_note_id

   • erp_reference

   • external_id

   • external_status

   • external_notes

3. Send only the fields you want to add or update. Existing fields are merged non‑destructively.

4. The system:

   1. Stores the references under external_references.

   2. Logs the change for audit purposes.

   3. Rejects attempts to update protected fields such as status or tracking number.

This pattern keeps the core return record controlled within Returns while still allowing rich cross‑system links.

Using API Request Logging

For compliance and troubleshooting:

1. When investigating an issue, review the API request log for:

   • HTTP method and path.

   • Status code.

   • IP address.

   • Response time.

2. Use this information to:

   • Confirm that calls reached the platform.

   • Troubleshoot authentication or payload errors.

   • Evidence access patterns for audits.

The integration layer keeps everything observable, traceable, and centralised.

Managing External References On Returns

External references are a structured way to link returns to records in other systems without changing core return data.

What External References Are

Each return record can include an external_references object that may contain:

• Finance identifiers such as a credit note id.

• ERP references.

• Generic external ids and statuses.

• Free text notes from external systems.

These references are additive and non‑destructive.

Adding External References

To add references from an external system:

1. Ensure you have a valid Customer API key.

2. Call the Update External References endpoint:

   1. Method: PATCH.

   2. Path: /returns/{returnId}/references.

   3. Auth: API Key.

3. In the JSON body, include the fields you want to set, for example:

   • credit_note_id: your finance system credit note.

   • erp_reference: your ERP internal id.

   • external_status: a concise status label.

   • external_notes: a short explanation, such as “Refund issued 2026‑03‑20”.

4. Submit the request and check the response to confirm the fields have been stored.

Existing values that you do not include remain untouched, so you can update fields gradually over time.

Viewing External References

To see references on a return:

1. In the API response for:

   • List Returns.

   • Get Return.

   • Webhook payloads.

2. Look for the external_references object:

   • If it is null, no references have been written yet.

   • If it is an object, it will contain any of the supported fields that have been set.

3. Use these values to:

   • Link to finance or ERP records.

   • Attach supporting documentation.

   • Reconcile across systems.

Because references appear consistently across admin APIs, customer APIs, and webhooks, you can rely on a single pattern throughout your integrations.

Respecting Protected Fields

To keep returns consistent and secure:

1. Do not attempt to modify protected fields such as:

   • status.

   • return_status.

   • approved_at or rejected_at.

   • tracking_number.

   • uri.

2. Any attempt to change these fields through the references endpoint will be rejected with a 403 response.

3. Use your normal operational workflows and admin tools to change core return state.

This separation keeps business references flexible while core return data remains controlled and auditable.

Working With Returns In Transit And Completed

Operational teams need a clear view of where returns are in their journey back to you.

Understanding Returns In Transit

Returns move to an “in transit” state when the courier has collected or scanned the parcel.

To monitor these:

1. Look at the Returns In Transit figure on the dashboard.

2. Drill into the detailed list of returns in transit where available.

3. Use the list to:

   • See which customers are waiting for refunds or exchanges.

   • Spot parcels that have been in transit for longer than expected.

   • Coordinate with your warehouse on expected incoming volumes.

This helps maintain service levels by ensuring returns do not get lost between the customer and your facility.

Understanding Returns Completed

A return is marked “completed” once your internal process is finished, for example:

• Goods inspected.

• Refund or credit issued.

• Any replacements sent.

To view completed returns:

1. Check the Returns Completed total on the dashboard.

2. Open the completed returns list or report.

3. Review each return’s:

   • Order number.

   • Return ID.

   • Customer information.

   • Sales channel.

   • External references.

Completed returns provide a clear audit trail from customer request to financial outcome.

Using Statuses With External Systems

Because status changes are available via APIs and webhooks:

1. Subscribe your ERP or finance system to:

   • Return In Transit.

   • Return Completed.

2. Use these events to:

   • Trigger internal reviews.

   • Issue credits automatically once returns are complete.

   • Keep customer communications aligned with real parcel movements.

By joining operational status, financial systems, and customer communication together, you gain a centralised and predictable returns process.