> ## 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.
# How to Download Orders from Base.com with getOrders
> Learn the recommended pattern for syncing orders from Base.com into your ERP or WMS using getOrders with date_confirmed_from pagination.
[`getOrders`](https://api.baselinker.com/index.php?method=getOrders) is the main and most-used order API method — it downloads orders from Base.com into your system. Understanding how to paginate it correctly is essential to building a reliable sync that never misses an order.
## Recommended approach
Choose the timestamp from which you want to start pulling orders and pass it as the `date_confirmed_from` parameter. This should be a Unix timestamp. On first run, use a historical date far enough back to catch all relevant orders. **Do not use `date_from`** — see the section below for why.
The method returns a maximum of **100 orders per call**. If you receive exactly 100 orders, assume there are more and continue paginating. Process every order in the batch before moving on.
Take the `date_confirmed` value from the **last order** in the batch, add 1 second to it, and use the result as the new `date_confirmed_from` for your next call. This ensures you don't re-download the same order while not skipping any.
Keep calling `getOrders` with the updated `date_confirmed_from` until a response contains fewer than 100 orders. At that point you have caught up with all confirmed orders and can wait for the next scheduled run.
Clients typically run this loop periodically — for example, every 10 minutes.
Always persist the `date_confirmed` of the last successfully processed order to durable storage (a database field, a config file, etc.) — **not** your local current time. An order can never appear in the database with a confirmation date earlier than the current latest one, so this approach guarantees you won't miss anything even if your process crashes mid-batch.
## Why `date_confirmed_from`, not `date_from` or `id_from`
The distinction between confirmed and unconfirmed orders is explained in [Core Concepts](/orders/overview#confirmed-vs-unconfirmed-orders). In practice, the problem with the alternatives is:
* **`date_from`** is the order *creation* date. On marketplaces like Alza or Allegro an order can be created as an unconfirmed draft and only confirmed two days later. If you paginate by creation date, this order falls outside the time window you already processed and you never see it.
* **`id_from`** has the same problem — order IDs are assigned at creation, not confirmation, so a late-confirmed order may have an ID lower than others you've already imported.
`date_confirmed` is the only field that is guaranteed not to shift retroactively to an earlier point once it is set. Paginating by it is the only approach that gives you a strict, gapless sequence.
If you genuinely need unconfirmed orders too (for example, to pre-warm a cache or give a warehouse team early visibility), set `get_unconfirmed_orders: true` — but keep in mind the data can still change and the order can be cancelled. You must track these orders over time in your own system and handle updates or discards accordingly.
## Key input parameters
| Parameter | Type | Description |
| ----------------------------- | ------------ | ------------------------------------------------------------------------------------------ |
| `order_id` | `int` | Downloads a single specific order by ID. |
| `date_confirmed_from` | `int` (unix) | **Recommended** pagination field — returns orders confirmed on or after this timestamp. |
| `date_from` | `int` (unix) | Creation date filter — **not recommended** for pagination (see above). |
| `id_from` | `int` | Returns orders with ID ≥ this value — **not recommended** for pagination (see above). |
| `get_unconfirmed_orders` | `bool` | Default `false`. Set to `true` to include unconfirmed draft orders. |
| `status_id` | `int` | Limits results to orders in a specific status — see [Statuses](/orders/statuses). |
| `filter_email` | `string` | Filters orders by customer e-mail address. |
| `filter_order_source` | `string` | Filters by order source (e.g. `"allegro"`, `"shop"`). |
| `filter_external_order_id` | `string` | Filters by external ID (e.g. an Allegro transaction number). |
| `include_custom_extra_fields` | `bool` | Adds custom extra field values to the response — see [Extra Fields](/orders/extra-fields). |
| `include_commissions` | `bool` | Adds marketplace commission data to each order. |
| `include_discounts_data` | `bool` | Adds a log of applied discounts to each order. |
Full input and output field reference is in the [getOrders API documentation](https://api.baselinker.com/index.php?method=getOrders).
## Alternative 1 — sync by order status
Instead of paginating by date, you can call `getOrders` with a specific `status_id` to fetch only orders awaiting processing, and then move each order to a different status via [`setOrderStatus`](https://api.baselinker.com/index.php?method=setOrderStatus) once it has been imported successfully.
**Advantage:** you have precise, explicit control over exactly which orders enter your ERP — nothing slips through and nothing is imported twice under normal conditions.
**Downside:** if an order accidentally lands back in the "import" status (for example due to a manual correction in the panel), it will be picked up again and you risk a duplicate import. Always add a safeguard on your side — for example, check `order_id` against previously imported records before inserting.
## Alternative 2 — getJournalList
[`getJournalList`](https://api.baselinker.com/index.php?method=getJournalList) returns a chronological list of order events — including order confirmation, status changes, and more — from the last 3 days. It is well suited for near real-time change tracking without polling `getOrders` continuously.
The method is **disabled by default** and must be explicitly enabled in the Base panel under **Profile → API** before it will return any data.
For event-driven patterns and webhooks, see [Automation & Webhooks](/orders/automation-and-webhooks).
## What's next
Read and write order statuses and handle cancellations safely.
Access custom fields attached to each order.
Generate carrier labels and attach tracking numbers.
Issue or attach invoices from your ERP.
Returns follow the same pattern — learn the differences here.
If you're not sure which approach — date-based, status-based, or journal — fits your scenario best, consider the trade-offs carefully before building the full integration. Switching approaches later means rewriting the core of your sync logic.