Hanzo
OpenapiCommerce

Method-override tunnel for a return — for clients that cannot send PUT, PATCH…

A return is an RMA — the store, user and order it belongs to, the line items coming back, a fulfillment block carrying its own type, status and pricing, a…

POST /v1/commerce/return/{returnid}

Addresshttps://api.hanzo.ai/v1/commerce/return/{returnid}
MethodPOST
Operationpost_commerce_return_by_returnid
AuthAuthorization: Bearer $HANZO_API_KEY

A return is an RMA — the store, user and order it belongs to, the line items coming back, a fulfillment block carrying its own type, status and pricing, a summary, and eight lifecycle timestamps from submitted through delivered and processed. Its status is a FREE STRING with no enumeration behind it, and there is no refund amount on the return itself: the money sits inside the line items and the fulfillment pricing. Re-dispatches the request into the handler the intended verb would have reached, taking that verb from a _method form value or query parameter and then from the X-HTTP-Method-Override header. PUT replaces the row, PATCH changes part of it, DELETE removes it, and anything else is 405. The trap is the DEFAULT: naming no override at all leaves the method POST, which this tunnel maps to the PARTIAL UPDATE — it is never a create, and creating is the collection root's job. Behaviour and authorization are the underlying operation's, since the real handler runs. Any valid access token reaches it.

Request

1 field.

FieldInTypeRequiredDescription
returnidpathstringyes

Response

The document declares no response body for this operation. It answers 200 on success and the platform error shape on failure — see Errors.

Examples

hanzo has no subcommand for this operation — the CLI serves only what cloud's live route table confirms. Use HTTP or an SDK.


Commerce API · All Hanzo APIs · Interactive reference

How is this guide?

On this page