Postman collection
Orders Read

pixiGetChangedOrders

Returns the header data of all orders that were created or changed, including changes to their order lines or addresses, since a given point in time.

Use this call for delta synchronisation of orders. It returns one row per changed order.

Time window

  • The end of the window, DateTimeTo, is the server time at execution (GETDATE()). It is returned in every row.
  • If DateTimeFrom is later than five minutes before the server time, it is moved back to now minus 5 minutes. Every call therefore covers at least the last five minutes.

Which orders count as changed

An order is selected if at least one of the following timestamps is at or after DateTimeFrom and not after DateTimeTo:

  1. The order header: UpdateDate, or CreateDate if the order was never updated.
  2. An order line: its UpdateDate, or CreateDate for lines that were never updated.
  3. The billing address (AddrRef) or the shipping address (ShipAdrRef) of the order: UpdateDate, or CreateDate if never updated.

Direct fulfillment filter

  • ReturnOnlyDFOrders = 0 (default): all changed orders are returned.
  • ReturnOnlyDFOrders = 1: only changed orders that have at least one order line with an OrderHistory entry with status FUT are returned.

Returned data

  • Header fields come from the order header, the customer (ShopID is the customer's CustomerOf) and the addresses. PaymentType is the payment type of the billing address. OrderLocked is the lock flag of the shipping address (N if empty).
  • Aggregated order line fields per order: OrderDate, which is the latest order line date or the earliest one if the setting UseInitialOrderDate is 1; the highest VoucherID with its VoucherAmount; the currency code OrderCurrency; the latest EstimatedDelivery.
  • Only orders with an existing customer, billing address and shipping address are returned. The rows are not sorted.

Notes

  • Polling: Pass the DateTimeTo value of the previous response as DateTimeFrom of the next call. Because of the minimum window of five minutes, the same order can be returned in consecutive calls. Process the rows idempotently.
  • If DateTimeFrom is NULL, no order matches and the result is empty.
  • Unused parameter: skipGetXMLValue is declared but not used by the code.
  • Dirty reads: All permanent tables are read with NOLOCK. Uncommitted data can appear, and rows can be missed or duplicated during concurrent changes.
  • Setting: UseInitialOrderDate is read from the Settings table and controls whether OrderDate is the earliest or the latest order line date.
  • Missing currency: The order line aggregates (OrderDate, VoucherID, VoucherAmount, OrderCurrency, EstimatedDelivery) are NULL if the order's currency is not found in pixi.Currency or the order has no lines.
  • EstimatedDelivery: The code compares it with a placeholder date (now + 999 days, including the time of day). In practice this almost never matches, so the value is returned unchanged.
  • Performance: The call scans addresses, order headers and order lines by date. Very old DateTimeFrom values can produce large results and long run times.

Tables used

Addresses · Read OrderHeader · Read Orderlines · Read OrderHistory · Read Currency · Read Orderline_EstimatedDelivery · Read Voucher · Read Customers · Read Settings · Read
SQL object:
dbo.pipiGetChangedOrders
Updated at 2026-10-30