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

# Base.com Orders API: Core Concepts and Integration Guide

> Understand how Base.com orders work — confirmed vs. unconfirmed, order sources, statuses, and how to structure your API integration before you start.

This section covers working with orders between your system and Base.com via API. The vast majority of integrations work in the direction **out of Base** — you download orders that originated from an e-shop, a marketplace, or were entered manually in the panel, and push them into your own ERP, warehouse, or accounting system.

## Where an order comes from

Every order has an `order_source` field that tells you which channel created it. Common values include:

* `"shop"` — a connected e-shop
* `"personal"` — added manually in the Base panel
* `"order_return"` — a return order
* Marketplace codes such as `"allegro"`, `"amazon"`, `"ebay"`, `"ceneo"`, `"emag"`, and others

The full list of sources configured on a given account, along with their numeric IDs, is returned by [`getOrderSources`](https://api.baselinker.com/index.php?method=getOrderSources).

## Confirmed vs. unconfirmed orders

<Note>
  This is the single most important concept in the entire order API. Getting it wrong is the most common cause of missing or incomplete orders in external systems.
</Note>

Base distinguishes between two states for every order:

* **Unconfirmed** (`confirmed: false`) — on some marketplace channels (typically Alza, Allegro), an order first appears as an incomplete "draft". You can see the line items, but not necessarily the full address, price, or shipping method — data may still change, and the order may be cancelled before it is ever confirmed.
* **Confirmed** (`confirmed: true`, `date_confirmed` populated) — the marketplace has sent confirmation and Base has filled in all remaining details. From this point the order should not change materially and is safe to persist into an external system.

This distinction is central to correctly downloading orders. See [Downloading Orders](/orders/downloading-orders) for the recommended sync pattern that builds on it.

## Order statuses

Independently of the confirmed/unconfirmed state, every order also carries a user-defined **status** (`order_status_id`) — for example: *New Order*, *To Be Shipped*, *Shipped*, *Delivered*, *Cancelled*. Every account configures its own statuses, and their behavior (sending tracking numbers, forwarding invoices, notifying the marketplace) is driven by Automatic Actions.

Status IDs are account-specific — never hardcode them without verifying the exact values on the target client account. See [Statuses](/orders/statuses) for details on reading, writing, and mapping statuses safely.

## What's in this section

<CardGroup cols={2}>
  <Card title="Downloading Orders" icon="download" href="/orders/downloading-orders">
    How to periodically pull orders with `getOrders` and paginate safely using `date_confirmed_from`.
  </Card>

  <Card title="Statuses" icon="tag" href="/orders/statuses">
    Reading and writing statuses, the two-way sync pattern, and handling cancellations.
  </Card>

  <Card title="Shipping Labels" icon="truck" href="/orders/shipping-labels">
    Tracking numbers and carrier label generation.
  </Card>

  <Card title="Invoices" icon="file-invoice" href="/orders/invoices">
    Issuing an invoice in Base or attaching one from your ERP.
  </Card>

  <Card title="Extra Fields" icon="sliders" href="/orders/extra-fields">
    Custom fields attached to an order.
  </Card>

  <Card title="Automation & Webhooks" icon="bolt" href="/orders/automation-and-webhooks">
    Catching events like cancellations and status changes in real time.
  </Card>
</CardGroup>