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

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 — this section covers which status to set in that situation.
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.
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.