How The Integration Works
5 min
outline returns are pushed to inmar as they're lodged, then polled on a schedule until inmar reports them processed creating the return when a customer lodges a return, refundid creates the return in inmar in two steps a return authorisation , keyed on a unique reference built from the order number and the refundid return id that key is what makes the request safe to retry the same return can't produce two authorisations a customer return against that authorisation, containing everything inmar needs to receive the parcel what the customer return contains the returns centre address the parcel is being sent to the carrier and tracking number from the return shipping label, so the returns centre can match the inbound parcel to the return carrier names are normalised to inmar's expected values one item per returned line , with the barcode, used as the item identifier the product title as the description the item price the return reason the customer selected, including the follow up reason where one was chosen the quantity and the refundid line reference each item is also tagged with the department and vendor identifiers agreed during setup, so returns are reportable by category in inmar multiple regions where you use separate inmar environments for different regions for example a north american returns centre and a european one refundid routes the return to the right environment based on the order, and authenticates against that environment's credentials your team doesn't need to route anything tracking the return refundid keeps a record linking the inmar return to the refundid return, and checks the status of every open return on a schedule (typically every couple of hours) returns that haven't been processed yet are simply checked again next time to stay within inmar's rate limits, returns are checked in batches with a pause between them on a busy day this means a return may be confirmed on the run after the one where inmar first marked it processed closing the return once inmar reports the return as processed, refundid closes the matching return, accepting the returned items so the customer's resolution is processed the record is then marked as complete so the return isn't checked again when something fails if a status check fails, the return stays open and is retried on the next scheduled run nothing is closed on the basis of a failed or ambiguous response