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

Set a starting date using date_confirmed_from

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

Process all orders in the response

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

Advance the cursor by 1 second

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

Repeat until the batch is smaller than 100

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

Full input and output field reference is in the getOrders API documentation.

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

​
What’s next

Statuses

Read and write order statuses and handle cancellations safely.

Extra Fields

Access custom fields attached to each order.

Shipping Labels

Generate carrier labels and attach tracking numbers.

Invoices

Issue or attach invoices from your ERP.

Downloading Returns

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.