RMA update (PUT) and delete are now deployed to Sandbox. See the full API spec here: https://docs.masonhub.co/api/v1#tag/Returns/paths/~1rmas/put
As with other models, an update expects the same body as a create. So if you wish to update some already-existing RMA in the API, send a PUT request with a fully qualified RMA in the body:
PUT to https://sandbox.masonhub.co/account_name/api/v1/rmas
[
{
"customer_identifier": "rma123",
"package_id": "1z324897234nferg45",
"return_type": "rma_submitted_by_customer",
"customer_instructions": "Dry clean",
"line_items": [
{
"customer_order_id": "54321",
"customer_sku_id": "shirts872340",
"quantity": 2,
"return_reason_code": "fit",
"return_notes": "Didn't fit",
"return_inventory_status": "qc"
}
]
}
]
Deletes are straightforward as well, and follow the same pattern as our other delete endpoints. Simply send a DELTE request with an array of objects containing the customer_identifiers of the RMAs you wish to delete.
DELETE to https://sandbox.masonhub.co/account_name/api/v1/rmas
[
{
"customer_identifier": "rma123"
},
{
"customer_identifier": "71625364"
}
]
To round out our feature set for RMAs, there is now a Data Factory endpoint you can hit in order to trigger some RMA events, and related callbacks. See the full API Spec defined here: http://localhost:3001/api/v1#tag/DataFactory/paths/~1data_factory~1rmaEvent/post
There’s a new callback you’ll want to register for, called ‘rmaEvent’.
As with our other callbacks, register for rmaEvents with a POST to https://sandbox.masonhub.co/account_name/api/v1/callbacks with message_type = rmaEvent and your target url
{
"url": "https://api.clienturl.com/api/rmaEvent",
"message_type": "rmaEvent"
}
RMA events are triggered when an RMA is received against, in order to notify you that we’ve received (at least in part) the return shipment from the customer. You have the option of specifying to the Data Factory whether you want to simulate a full receipt, meaning all items originally on the RMA wind up in returned status, or a partial. If you choose the ‘receivePartial’ option, the API will select quantities at random for each line item on the RMA to receive against.
Let’s take the example RMA we used above and trigger an rmaEvent:
POST to https://sandbox.masonhub.co/account_name/api/v1/data_factory/rmaEvent
[
{
"customer_identifier": "rma123",
"event": "receiveFull"
}
]
You can now expect to get a callback POST to the url you registered for rmaEvent messages with a body like so:
{
"callback_url": "https://client.com/api/rmaEvent",
"message_type": "rmaEvent",
"message_id": "0896116f-e54b-4756-9d3e-1b0c4a25d821",
"data": [
{
"id": "vf79fyn5-ec61-7892-ae7b-57a173b68133",
"customer_identifier": "rma123",
"package_id": "1z324897234nferg45",
"return_type": "rma_submitted_by_customer",
"status": "received",
"received_at": "2018-08-06T11:18:46Z",
"notes": "Missing one item",
"customer_instruction": "Dry Clean",
"line_items": [
{
"customer_order_id": "54321",
"customer_sku_id": "shirts872340",
"quantity": 2,
"quantity_received": 2,
"return_reaon_code": "fit",
"return_reason": "Didn't fit.",
"return_inventory_status": "qc"
}
],
"version": 1,
"created_at": "2018-12-28T12:54:01.831921Z",
"updated_at": "2018-12-28T07:56:31.918607Z",
"deleted_at": null
}
]
}
The main thing to note is you now have a ‘received_at’ timestamp for when the RMA was received, as well as a ‘quantity_received’ count on the line_item level, so you know what quantities were successfully received.
With those additions, the RMA endpoint is API complete.
As always, don’t be afraid to reach out to Chris or Andy with any questions.