Status & order history
Endpoints under /api2/history to change the order status (e.g. invoice_issued, shipped, awaiting_payment or any custom status) with automatic validation against configured Yep statuses, and list the full history with comments, transitions and system events.
Overview
The history resource serves two complementary purposes: auditing (chronological view of what happened on the order) and orchestration (record comments and trigger status transitions from external systems such as ERP, OMS or WMS). For shared family rules (pagination, dates, HTTP statuses), see the main Orders page.
order_id, order_increment_id or increment_id.status applies and records the transition./api2/history only.List the order history. Identify the order with order_id, order_increment_id or increment_id.
By order_id
GET /api2/history?order_id=123
Authorization: Bearer {{token}}
By order_increment_id
GET /api2/history?order_increment_id=100000123
Authorization: Bearer {{token}}
By increment_id (alias)
GET /api2/history?increment_id=100000123
Authorization: Bearer {{token}}
By JSON body
{
"order_id": 123
}
Create a history entry on the order. When status is provided, the entry is recorded and the order receives that status (validated against the configured statuses).
Internal comment (no status change)
POST /api2/history
Authorization: Bearer {{token}}
Content-Type: application/json
{
"order_id": 123,
"comment": "Comment created by API.",
"is_customer_notified": false,
"is_visible_on_front": false
}
Status change with visible comment
POST /api2/history
Authorization: Bearer {{token}}
Content-Type: application/json
{
"order_increment_id": "100000123",
"comment": "Order sent to picking.",
"status": "processing",
"is_customer_notified": true,
"is_visible_on_front": true
}
About is_customer_notified
This flag only marks the history entry as "customer notified" for reporting purposes. It does not send emails. To trigger customer communication, use POST /api2/invoice/email or POST /api2/shipment/email as appropriate.
/api2/history only.Supported usage patterns
Tested and certified combinations for the History resource.
GET /api2/history?order_id=123GET /api2/history?order_increment_id=100000123POST /api2/history + commentPOST /api2/history + statusPOST /api2/history + is_visible_on_front=trueIntegration recommendations
Recommended
- Validate the
statusvalue against the Yep configuration before sending — only configured statuses are accepted. - Use
is_visible_on_front=trueonly on comments that are genuinely relevant to the customer; keep internal logs withis_visible_on_front=false. - For WMS/OMS integrations, record significant transitions via
POST /api2/history + statusto build an audit trail.
Avoid
- Expecting
is_customer_notified=trueto send emails — it only stores the flag. - Trying
/api2/historiesor/api2/historic— the resource is singular. - Changing status without a comment — auditing becomes harder to trace later.
Audit trail
For integrations that must justify transitions for internal audit or compliance, standardize the comment format: e.g. "[ERP-XYZ #1234] Status updated by sync job.". It eases later searches in the order history.
Common errors
| Status | Sample body | When it happens |
|---|---|---|
400 | {"error": "Invalid status"} | status sent does not match any configured Yep status. |
400 | {"error": "Comment is required"} | Body without comment. |
401 | {"error": "Unauthorized"} | Missing Authorization or expired token. |
404 | {"error": "Order not found"} | Unknown order_id or increment_id. |
409 | {"error": "Conflict on save"} | Duplicate or deadlock on concurrent writes. |