Skip to main content
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.

At a glance

Before you call

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.

Things to know

  • 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 status active and return_status pending. 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.