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. What is status 5 on one account may be “Shipped” on another and “Cancelled” on a third.

​
Reading statuses

Retrieve the statuses configured on an account with these two methods: A status does nothing by itself. Its behavior (sending a tracking number to the customer, forwarding an invoice to a marketplace, triggering a warehouse pick) is defined via Automatic Actions and the settings of each specific integration (for example, Integrations → Amazon → Order Statuses). More on this mechanism in Automation & Webhooks. A typical baseline status setup looks like this:

​
Writing statuses

Three methods let you change or create statuses programmatically:
  • setOrderStatus: update the status of a single order.
  • setOrderStatuses: bulk-update the status of multiple orders in one call.
  • addOrderStatus: create a new status programmatically. This is typically only needed during initial integration setup, not in ongoing sync flows.
A common mistake is writing a status back to Base on every change in your own system without checking what Base currently holds. This can race with a user editing the same order in the panel at the same time. The recommended approach is:
  1. Fetch the order’s current state via getOrders (or from a recent cached copy).
  2. Compare the current order_status_id in Base with the status you intend to write.
  3. Only call setOrderStatus if the values differ.
This prevents redundant writes and avoids triggering Automatic Actions (which fire on every status change) for no reason.

​
Cancelled orders

When a customer submits a cancellation request on a marketplace, that event reaches Base and needs to be reflected with the correct status. The mechanism for catching the cancellation event (an Automatic Action, getJournalList, or a webhook) is described in Automation & Webhooks. This section focuses on which status to set once you have detected the cancellation. For most channels, set the order to your Cancelled status. Some marketplace integrations distinguish between a Cancelled and a Rejected outcome depending on whether a shipping label has already been transmitted to the carrier or marketplace. Check the specific integration’s settings in the Base panel to see whether this applies to your channel.

​
Complex status mappings

Non-trivial status mappings between Base and your ERP (for example, several Base statuses that all map to a single ERP status, or statuses that mean different things depending on the order source) should be fully planned before you go live. A wrong mapping is much cheaper to fix before orders start flowing than after.