Skip to content

Integration scenarios

Here we provide some examples of how the Returnista Platform’s interoperability points support various integration scenarios.

Retrieve purchases and process resolutions from a custom ecommerce platform

Implement a custom Ecomm Bridge (synchronous) to connect with any ecommerce platform:

Scenario 1

Custom returns UX

Returnista provides a customizable and fully branded “Returns Portal” as part of its platform offering. However, customers looking for an even greater level of frontend integration are free to build their own consumer facing returns UI.

The Returns Portal is a client web application that uses the REST API for delegating all business logic and state persistence to the Returnista Platform. Therefore, a custom Returns UX can work in the same way.

Scenario 2

These are the endpoints such a system would typically use:

  • POST /auth/consumer: Verify and create identity for a consumer. I.e. Their order details correspond to sales orders in the underlying ecommerce system. A consumer identity is unique to the order credentials they provide.
  • GET /consumer/:id/purchases: Get purchases to display to the consumer from which they can select to return. Each purchase provided will also include relevant data such as: available shipping options and selectable return reasons.
  • POST /consumer/:id/draft-return-order: Create a draft return order. The draft return order will calculate the cost breakdown of the return
  • PATCH /consumer/:id/draft-return-order/:id/shipping-option: Update the return request to include the selected Shipping Option
  • POST /consumer/:id/return-order: Create a real Return Order based on the Draft Return Order. This will start payment and label generation flows
  • GET /consumer/:id/return-order/:id: Get the return order for providing confirmation of the return.

Custom resolution process

Customers may choose to use their existing systems to process return resolutions (e.g. processing a refund).

This scenario requires the customer system to retrieve Return Requests in batches via the REST API or one-by-one via webhooks.

In both cases the API call would filter Return Requests by the appropriate lifecycle stage/status or the webhook subscription would listen to Return Requests that progress to this stage/status. Typically this would be: Resolution: Approved

Once a Return Request resolution action has been externally processed, its status can be updated via the REST API.

Fulfillment-center/WMS forecasting

It is often required to pre-notify an fulfillment-center of an incoming return. This can be achieved by the fulfillment-center subscribing to the webhook event when a shipping label for the return is generated.

Often, a Warehouse Management Software (WMS) may not be able to subscribe to the webhook directly and require a middleware service to subscribe to the webhook and call an API endpoint on the WMS.

Furthemore, the reference numbers retrieved from the source ecommerce system may not be compatible with the WMS. In this scenario, the middleware may perform a mapping function to translate order numbers via another system such as an ERP system that also integrates with the WMS.

Scenario 4