FlxpointBeta

Integrating as a Channel

"Channel" is the role you play in Flxpoint when you're the system Flxpoint pushes data to. Common cases: a marketplace (Amazon, eBay, Walmart), an ecommerce storefrontThe buyer-facing site selling productsShopify, BigCommerce, WooCommerce, Magento, custom-built — anywhere a buyer can land, browse, and check out. As a Channel, you receive listings and publish them, and you send the resulting orders back to Flxpoint to be routed to a Source for fulfillment., or a point-of-sale system. If buyers land on your surface and place orders there, you're a Channel.

Typical flow

  1. Pull listings to sync— inventory / price updates Flxpoint wants reflected on the channel. Run this on a poll; treat each row as "ensure this listing on my surface looks like this".
  2. Pull listings to publish— new products Flxpoint wants listed on the channel. Same pattern, different state: these aren't live yet.
  3. Post sync / publish responses(optional) — confirm success or report errors. Without these, Flxpoint can't tell whether a sync actually landed; with them, you get visibility on both sides.
  4. Push new ordersinto Flxpoint as they come in. This is the trigger that kicks off fulfillment routing on Flxpoint's side.
  5. Pull order status + shipments back from Flxpoint to surface tracking and delivery info to the buyer.
Pulling shipments? includeShipments alone does nothing. On GET /orders, shipments are nested under an order's fulfillment requests and purchase orders — not on the order root. To get tracking data back you must send both includeShipments=true and includePos=true. Requesting shipments without POs returns an empty shipments array and hides the bug.
curl -G "https://api.flxpoint.com/orders" \
  -H "X-API-TOKEN: YOUR_TOKEN" \
  --data-urlencode "updatedAfter=2026-07-01T00:00:00Z" \
  --data-urlencode "includeShipments=true" \
  --data-urlencode "includePos=true"

Endpoints you'll use

Browse the Channel, Listing, Order, and Shipment resources for the exact request bodies and response shapes.

Authentication

Use a Channel token — scoped to your single channel, with its own rate-limit bucket. See Authentication for how the three token types differ.

Idempotency on order push

When you push orders into Flxpoint, make the operation idempotentSafe to send the same request twice — no duplicateAn idempotent operation has the same effect whether you call it once or 100 times. For order push, this means: if your network drops mid-request and you retry, you get the same Flxpoint order — not a second one. Flxpoint uses your channel-side order ID to deduplicate; send a stable, unique ID per buyer order and you're safe.. The simplest way: pass your channel-side order ID in the request and let Flxpoint dedupe on it. Without that, retries on network errors can create duplicate orders that'll bill the buyer twice.

Updating orders: it's a full replace

An order update replaces the whole object. The line-item set you send is treated as the completeset — any existing line item you leave out is interpreted as removed. There's no "patch one item": always send the full current set of items you want to keep.

A few fields (billing / shipping address, fulfillment type, invoice) can only be changed while the order is still in draftstatus; once it's past draft they're locked. Editing notes, tags, and line-item custom attributes is allowed after import. Check the Order reference for the exact editable-in-draft fields, and test against a draft order before wiring an update into production.

What next?

  • Authentication & Rate Limits — get a Channel token and confirm it works.
  • Order— the central resource for channel integrations; start here when you're ready to push.
  • Date formatting — required reading before you build any time-based filter or sync cursor.