Authorise customer returns against fulfilled invoices, approve or reject them, receive returned stock and keep notes.
A return merchandise authorisation (RMA) records the goods a customer may return from a fulfilled invoice. These endpoints create, update, approve, reject and delete RMAs, receive the returned stock, and manage the RMA’s notes. This area has 19 endpoints, each available in all seven SDKs.
Receiving returned stock commits it, and a received RMA cannot be deleted.
Register your API credentials once when your app starts, as shown in
Authentication. Every SDK sample on these pages then gets its client in one line.
With cURL, send the access token in an Authorization header: Authorization: Bearer $ACCESS_TOKEN.
Writes take the RMA’s id; the reads under it take its code. Update, delete, approve, reject, receive and the note writes need the rma_id and refuse a code. The note and receipt reads resolve the RMA by code and return 404 for an rma_id.
An RMA needs a fulfilled invoice. The create body names the invoice by its internal id, inv_ followed by the invoice’s uuid without hyphens, and each return line by a fulfilled invoice line’s id.
A new RMA has statusactive and return_statuspending. The create call returns a short record (id, code, status, version); read the RMA for the rest.
Approve and reject take no body and can notify approvers. Both are refused with 422 when the RMA has no pending approval.
Notes are JSON, not forms, and carry no file. Create an RMA note takes {"note": {"note": "..."}} and no attachment.
Listings page by cursor. Pass limit and the previous page’s pagination.next_cursor as cursor, and stop when has_more is false.