Cin7 integration with your online store: stock per location out, orders in

What Cin7 is and who runs it

Cin7 is inventory and order management software for product businesses: manufacturers, wholesalers, retailers and e-commerce sellers that hold stock in more than one place. It started in 2012 and reports more than 8,500 customers. It sells two products: Cin7 Core, with its features set up out of the box, and Cin7 Omni, more configurable, with native EDI and 3PL connections.

For an integration the two are different systems.

Both return dates in UTC. Cin7 Core's own documentation calls its API a subset of what the application can do, so the first step on any Core project is checking that every field a flow needs is in the API.

What connects to Cin7

Cin7 owns products, prices per price tier and stock per location. The store owns the checkout. That gives these flows:

A sale in Core is built in stages: the sale header with customer, addresses, Location and PriceTier, then the order with its lines. The order's Status can be DRAFT or AUTHORISED on a POST. Only an authorised order allocates stock, and a sale where one line cannot be allocated moves to BACKORDERED. Pick, pack, ship and invoice follow inside Cin7, each with its own status the store can read back.

How Cin7 exposes data

Rate limits and arithmetic

Cin7 Core returns 429 Too Many Requests above 60 calls a minute. The limit counts per API application, and an account can have several applications, so the store integration gets its own and does not share a budget with a reporting tool or a 3PL connection.

Worked through for a Core account with 600 orders a day, 8,000 SKUs and 2 locations: an order takes 3 calls (look up ExternalID, post the sale, post the order), so 1,800 calls a day, 30 minutes of the minute budget when spread out. A full stock read is 8,000 x 2 = 16,000 availability rows, at 1,000 a page 16 calls.

Cin7 Omni's daily cap changes the plan. A stock unit is one product option in one branch. 10,000 options in 3 branches are 30,000 rows, at 250 a page 120 calls. A full read every 15 minutes is 96 x 120 = 11,520 calls a day, more than double the 5,000 limit before a single order is written. Omni's own documentation recommends asking only for records with a modified date after the last poll:

GET /api/v1/Stock?where=modifieddate>='2026-10-03T08:15:00Z'&rows=250&page=1
Authorization: Basic c3RvcmVfYXBpOmFwaWtleQ==

Polling only changes every 15 minutes costs 96 calls a day while each poll fits on one page, and the rest of the budget stays for orders and retries. The note on integration throughput has the method.

Webhooks in Cin7 Core

Core sends webhooks for sale events (Sale/OrderAuthorised, Sale/Backordered, Sale/ShipmentAuthorised), Product/Updated and Stock/AvailableStockLevelChanged. They need the Automation module on the subscription, and there can be at most 5 webhooks of the same type. Delivery is retried on a fixed schedule:

After six failed attempts Cin7 deactivates the webhook. A receiving endpoint that is down for 80 minutes therefore loses every later event as well, until someone switches the webhook back on. We treat webhooks as a signal and poll saleList and productavailability with UpdatedSince next to them, as described in webhooks are not a guarantee.

Where a Cin7 integration gets stuck

Which stock counts. Core gives five quantities per product, location and batch: OnHand, Allocated, Available, OnOrder and InTransit, plus a NextDeliveryDate. Omni gives StockOnHand, OpenSales, Available, Incoming, Holding and Virtual, where Virtual is stock for kit products. A store that receives OnHand sells stock that is already allocated to open orders. The integration sends Available for the locations you choose, and computes kit availability from its components when the store sells bundles. See which stock counts and multi-location inventory.

Duplicate sales on retry. A sale POST that times out may have been created. Core's ExternalID field (256 characters, API only) holds the store order number, and saleList?ExternalID= finds it before a retry. Omni's Reference is unique per order and does the same job.

Variants and SKU length. A Core product family has up to three options (Option1Name to Option3Name, 50 characters each) and generates a SKU per variant from a family SKU of at most 45 characters. A product SKU is at most 50 characters and must be unique across all products. Omni also has three options per product, each value at most 50 characters. Store SKUs that are longer, or products with a fourth option, need a mapping rule before the first sync.

Price tiers. Core keeps up to 10 price tiers per product (PriceTier1 to PriceTier10) and a sale names its tier. A B2B order from the store has to carry the customer's tier, or Cin7 prices it at the default. Tax is set per sale with TaxInclusive, which has to match how the store sends its prices.

Platforms we integrate with Cin7

The integration is built on your Cin7 product, your locations and your sale stages. What the store side needs is on each platform page:

• Shopify: stock per Shopify location against Cin7 locations, orders with the Shopify order number as ExternalID.
• WooCommerce: one stock number per product, so the integration sums the locations you choose.
• BigCommerce and Magento: variants against product family options, B2B price tiers.

For a warehouse run by a 3PL next to Cin7, see ShipBob; for another inventory and order system, Brightpearl. All flows are listed on integrations. We build the integration for a fixed price, then host, run and monitor it for a monthly fee, with a dashboard, logs and a per-run diff. Before go-live it runs as a dry run that writes nothing to Cin7 or the store. Tell us which Cin7 you run and how many locations.