Skip to main content
getOrders is the main and most-used order API method — it downloads orders from Base.com into your system.
  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.
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.

​
Why date_confirmed_from, not date_from or id_from

A detailed explanation of the confirmed/unconfirmed order concept is in Basic principles. 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.
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.

​
Key input parameters

ParameterTypeDescription
order_idintDownloads a single specific order.
date_confirmed_fromint (unix)Recommended paging field — confirmation date to start from.
date_fromint (unix)Creation date — not recommended.
id_fromintOrder ID to start from — not recommended for the same reason.
get_unconfirmed_ordersboolDefault false. Includes unconfirmed orders too.
status_idintLimits results to a single status — see Statuses.
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_fieldsboolAdds custom field values to the response — see Extra fields.
include_commissionsboolAdds marketplace commission info.
include_discounts_databoolAdds a log of applied discounts.
Full input/output field reference is in the getOrders documentation.

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

​
What’s next

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.