Flavours Partner API
Order

Get Api V2 Orders Order Id Products Order Product Id

GET
/api/v2/orders/{orderId}/products/{orderProductId}

Authorization

API-TOKEN
API-TOKEN<token>

Your partner API key. Send it in the API-TOKEN header on every request.

In: header

Path Parameters

orderId*string
orderProductId*string

Header Parameters

X-API-Version*string

API contract version to target. See the Changelog for what changed in each version.

Default"2.0.0"
Value in"2.3.0" | "2.2.0" | "2.1.0" | "2.0.0"

Response Body

application/json

application/json

application/json

application/json

curl -X GET "https://api.flavours.sa/dev/api/v2/orders/voluptas/products/earum" \  -H "X-API-Version: 2.3.0"
{
  "meta": {
    "code": 401,
    "status": "error",
    "message": "Unauthenticated."
  },
  "data": null
}
{
  "meta": {
    "code": 403,
    "status": "error",
    "message": "This action is unauthorized."
  },
  "data": null
}
{
  "meta": {
    "code": 404,
    "status": "error",
    "message": "Resource not found."
  },
  "data": null
}
{
  "meta": {
    "code": 500,
    "status": "error",
    "message": "Internal server error."
  },
  "data": null
}

Current user GET

The authenticated user with the relations of their role. For a **subscriber** `userable.branch` is the pinned branch, with `setting` (`setting.timezone`: the branch IANA zone every workday time is computed in) and `shift`. `shift` keeps its legacy keys (`day`, `min`, `max`, `open_at`, `lock_at`) and adds `timezone`, `is_workday` (the branch switch is ON), `workday`, `overtime_end_at`, `auto_close_at` (when the auto-close job will close the open shift) and `next_opening_at` (additive, at every `X-API-Version`); from `X-API-Version` 2.10.0 `shift` is always an object, below it a branch outside every shift keeps `null`. Clients that need the phase and the allowed actions read `GET /v2/attendances/state` instead of deriving them from `shift`.

Mark Order Product Done POST

Flips a single kitchen line's `is_done` flag. When the flip leaves no unfinished `RELATED` line on the order, the order is transitioned to `COMPLETED` through the same service the order update endpoint uses, so a status log is written, the table is released and the broadcast carries the new status. `is_done: 0` never moves the order back. When the order type's mandatory-field settings block the completion the tick still succeeds (200) and the response carries `meta.completion_blocked`, a list of `{field, message}`. **Gated by the branch cutover switch** (`branch_settings.kitchen.legacy_board`, contract §14.1): a branch on `READ_ONLY` answers `409` with `data.error.code = "kitchen.legacy_board_read_only"` and one on `OFF` answers `409 kitchen.legacy_board_off`, both before any write, so a stale client cannot tick a line on a branch that has moved to the kitchen screens.