> ## 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.

# Downloading orders — getOrders

> Complete overview of the getOrders method: parameters, pagination, recommended polling pattern

[`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.

## Recommended approach

1. Set a starting date and pass it in the `date_confirmed_from` parameter (not `date_from` — see why below).
2. Process all orders received. The method returns a maximum of 100 orders per call — if you get exactly 100, there are likely more waiting.
3. For the next call, take the `date_confirmed` value from the last order you processed, add 1 second, and use it as the new `date_confirmed_from`. This prevents re-downloading the same order.
4. Repeat until you get a batch with fewer than 100 orders — that means you've caught up.

Clients typically call this method periodically, e.g. every 10 minutes.

<Note>
  Always persist the `date_confirmed` of the last processed order, not your local current time. An order can never "jump" into the database with an earlier confirmation date than the current latest one, so this approach guarantees you won't miss anything.
</Note>

## Why date\_confirmed\_from, not date\_from or id\_from

A detailed explanation of the confirmed/unconfirmed order concept is in [Basic principles](/en/objednavky/zakladni-principy#confirmed-and-unconfirmed-orders). In practice: if you sync by `date_from` (creation date) or `id_from`, an order confirmed with a delay (say, two days later) can slip outside a time window you've already processed and never reach you. The confirmation date is the only field guaranteed not to retroactively shift earlier for older orders.

<Warning>
  If you genuinely need unconfirmed orders too (e.g. for some custom pre-processing), keep in mind their data can still change or the order can be cancelled. You need to track them over time yourself and discard them in your system if needed.
</Warning>

## Key input parameters

| Parameter                                                         | Type       | Description                                                                               |
| ----------------------------------------------------------------- | ---------- | ----------------------------------------------------------------------------------------- |
| `order_id`                                                        | int        | Downloads a single specific order.                                                        |
| `date_confirmed_from`                                             | int (unix) | Recommended paging field — confirmation date to start from.                               |
| `date_from`                                                       | int (unix) | Creation date — **not recommended**.                                                      |
| `id_from`                                                         | int        | Order ID to start from — **not recommended** for the same reason.                         |
| `get_unconfirmed_orders`                                          | bool       | Default `false`. Includes unconfirmed orders too.                                         |
| `status_id`                                                       | int        | Limits results to a single status — see [Statuses](/en/objednavky/statusy).               |
| `filter_email`, `filter_order_source`, `filter_external_order_id` | —          | Filter by email, order source, or external ID (e.g. an Allegro transaction number).       |
| `include_custom_extra_fields`                                     | bool       | Adds custom field values to the response — see [Extra fields](/en/objednavky/extra-pole). |
| `include_commissions`                                             | bool       | Adds marketplace commission info.                                                         |
| `include_discounts_data`                                          | bool       | Adds a log of applied discounts.                                                          |

Full input/output field reference is in the [getOrders documentation](https://api.baselinker.com/index.php?method=getOrders).

## Alternative 1 — sync by order status

Instead of working with dates, you can fetch only orders in a specific status (`status_id`) and move them to another status via [`setOrderStatus`](https://api.baselinker.com/index.php?method=setOrderStatus) once processed. Advantage: precise control over what goes into your ERP. Downside: if an order accidentally lands back in the "import" status, you risk a duplicate import — add a safeguard on your side (e.g. checking against `order_id`).

## Alternative 2 — getJournalList

[`getJournalList`](https://api.baselinker.com/index.php?method=getJournalList) returns a list of order events (including confirmation) from the last 3 days and is well suited for near real-time change tracking. The method is **disabled by default** and needs to be turned on in the Base panel under **Profile → API**. More on journals and webhooks in [Automation and webhooks](/en/objednavky/automatizace-a-webhooky).

## What's next

* [Statuses](/en/objednavky/statusy)
* [Extra fields](/en/objednavky/extra-pole)
* [Shipping labels](/en/objednavky/prepravni-stitky)
* [Invoices](/en/objednavky/faktury)
* Returns work analogously, see [Downloading returns](/en/vratky/stahovani-vratek)

<Tip>
  If you're not sure which approach (date, status, or journal) fits your scenario, discuss it with the implementation team before building the full integration — switching approaches later means rewriting the core of your sync logic.
</Tip>