Syncing Data Incrementally

Incremental sync means: on each poll, ask only for records that changed since the last time you looked, advance a cursorA saved marker of 'where you left off'A cursor is a value you store between polls that marks the last record (or timestamp) you processed. Next poll, you pass it back so the API returns only newer records. It keeps sync O(changes) instead of O(everything). , and process the delta. Done right, a sync job stays cheap no matter how large the catalog or order history grows.

The filter name changes per resource

Every list endpoint that supports incremental pulls takes an ISO-8601 timestamp — but the parameter nameis not consistent across the API. Always confirm the exact name on the endpoint's reference page. Current filters:

There is no updatedBefore counterpart on any list endpoint today — these filters are lower-bound only. Format every timestamp per the Date Formatting guide (ISO-8601, UTC).

The updatedAt-null trap

A record that was created but never modified can return a null "updated" timestamp. That means a filter like updatedAfter — which matches on last-modified time — can silently skip brand-new recordsthat haven't been touched since creation. If your whole sync hangs off one updatedAfter cursor, you will miss them.

To capture both new and changed records, use the widest cursor the endpoint offers:

• If the endpoint has a creation-time filter too (Orders: orderedAfter; RMA / Inbound Shipments: createdAfter): run one pass on the update filter and one on the creation filter, then merge on record ID to dedupe.
• If the endpoint has an ID cursor (sinceId on Orders, FRs, POs): page forward by sinceId to catch new records regardless of their timestamps.
• Otherwise (Products, Listings, Inventory — only updatedAfter): schedule a periodic full reconcile (e.g. nightly) alongside the frequent incremental poll, to sweep up anything the timestamp filter missed.

Resources with no time filter

GET /sources and GET /vendorsexpose no timestamp filter at all. These sets are small and change rarely, so the pattern is different: pull the full list on a slow cadence (hourly or daily), diff against your local copy by ID, and apply the changes. Don't poll them on a tight loop — there's nothing incremental to gain.

A concrete incremental poll

# Store LAST_SEEN (an ISO-8601 UTC timestamp) between runs.
# Pull orders changed since the cursor, newest data included.
curl -G "https://api.flxpoint.com/orders" \
  -H "X-API-TOKEN: YOUR_TOKEN" \
  --data-urlencode "updatedAfter=${LAST_SEEN}" \
  --data-urlencode "orderedAfter=${LAST_SEEN}" \
  --data-urlencode "includePos=true" \
  --data-urlencode "includeShipments=true"

# Advance LAST_SEEN to the max updated timestamp in the response,
# de-dupe the two passes on order id, then process the delta.

(See Integrating as a Channel for why order shipments need includePos=true, and Polling fulfillment requests for the Source-side FR flow.)

Cadence & rate limits

Incremental pulls are light, but they still count against the 2 requests/second per token limit. Page sequentially (one request at a time per token, not parallel bursts), and pick an interval that matches how fast the data actually moves — every 1–5 minutes for orders and fulfillment requests, hourly or daily for slow sets like sources and vendors. See Authentication & Rate Limits for the full model.

Related

• Date Formatting — the exact timestamp format these filters expect.
• Polling fulfillment requests — the Source-side FR polling flow.
• API reference — confirm the exact filter name on each endpoint.