> ## Documentation Index
> Fetch the complete documentation index at: https://api.basetools.cz/llms.txt
> Use this file to discover all available pages before exploring further.

# Statuses

> Reading and writing order statuses, typical setup, and handling cancellations

Statuses are fully user-defined in Base — every account names and numbers them differently. **Never hardcode status IDs without verifying them on the specific client account.**

## Reading statuses

Get the current list of statuses (and their groups, which are purely a visual grouping in the panel) with:

* [`getOrderStatusList`](https://api.baselinker.com/index.php?method=getOrderStatusList) — list of statuses.
* [`getOrderStatusGroups`](https://api.baselinker.com/index.php?method=getOrderStatusGroups) — list of status groups.

A status does nothing by itself — its behavior (sending a tracking number, forwarding an invoice to the marketplace, etc.) is defined via **Automatic Actions** and the settings of a specific integration (e.g. Integrations → Allegro → Order Statuses). More on the mechanism in [Automation and webhooks](/en/objednavky/automatizace-a-webhooky).

A typical baseline setup:

* *New Order* (neutral, does nothing)
* *To Be Shipped*
* *Shipped*
* *Delivered*
* *Cancelled*
* optionally *(Invoice)*, *(Cancelled by Alza)*, *(Rejected by Alza)*

## Writing statuses

* [`setOrderStatus`](https://api.baselinker.com/index.php?method=setOrderStatus) — change a single order's status.
* [`setOrderStatuses`](https://api.baselinker.com/index.php?method=setOrderStatuses) — bulk update.
* [`addOrderStatus`](https://api.baselinker.com/index.php?method=addOrderStatus) — create a new status programmatically (typically only during initial integration setup).

### Recommended pattern for two-way sync

A common mistake is writing status back to Base on every change in your own system without checking the current state first — this can race with a user editing the same order in the panel. Recommended approach: check the current status via `getOrders` before writing, and only update it if it actually differs.

## Cancelled orders

A customer's cancellation request on a marketplace reaches Base. The mechanism for catching this event (automatic action, `getJournalList`, webhook) is described in [Automation and webhooks](/en/objednavky/automatizace-a-webhooky) — this section covers **which status** to set in that situation.

<Warning>
  Alza Trade is a special case: it distinguishes between **Cancelled** and **Rejected**:

  * As long as no shipping label has been sent to Alza yet, you send status **Cancelled** (deleting any draft label first via `deleteCourierPackage` if one exists).
  * Once a label has already been sent to Alza (Shipment Departure occurred), **never delete it** — send status **Rejected** instead. The same applies to shipments returned as unclaimed.
</Warning>

<Tip>
  Non-trivial status mappings between Base and your ERP (e.g. several Base statuses mapping to one ERP status) are worth discussing with the implementation team before going live.
</Tip>