Faire integration with your ERP: wholesale orders in, stock and prices out

What Faire is and who runs it

Faire is an online wholesale marketplace run by Faire Wholesale, Inc. Brands list their products at a wholesale price, and independent retailers order from them. An order can be a few case packs, for example three cases of candles for a gift shop. Faire handles the retailer's payment and pays the brand out per order.

For a brand with an ERP, Faire is one more sales channel next to its own B2B store, its sales reps and its retail partners. Without an integration, someone retypes every Faire order into the ERP and updates Faire stock by hand. With several hundred SKUs and orders arriving every day, Faire shows stock that sold yesterday, and retailers order it.

What connects to Faire

The ERP is the system of record for items, prices and stock. Faire is where the order starts. These are the flows we build as part of order integration:

An order moves through the states NEW, PROCESSING, PRE_TRANSIT, IN_TRANSIT and DELIVERED, with BACKORDERED, CANCELED and PENDING_RETAILER_CONFIRMATION on the side. The integration moves it forward from the ERP: acceptance when the ERP confirms the sales order, tracking when the warehouse ships.

How Faire exposes data

Authentication

Faire's API is REST with JSON at https://www.faire.com/external-api/v2. A brand that connects only its own account generates an access token in the Brand Portal. An integration partner uses OAuth 2.0: the brand approves a list of scopes, such as READ_ORDERS, WRITE_ORDERS, READ_INVENTORIES and WRITE_INVENTORIES, the authorization code expires within 10 minutes, and every request then carries two headers: X-FAIRE-APP-CREDENTIALS with the Base64 of application ID and secret, and X-FAIRE-OAUTH-ACCESS-TOKEN.

No webhooks, so polling on updated_at

The External API documents no webhooks. Orders are read by polling:

GET /external-api/v2/orders?updated_at_min=2026-10-03T06:00:00.000Z&limit=50
    &excluded_states=DELIVERED,CANCELED
X-FAIRE-APP-CREDENTIALS: ...
X-FAIRE-OAUTH-ACCESS-TOKEN: ...

The response is sorted by updated_at and carries a cursor for the next page. Faire's documentation says a request for a page beyond the first without a cursor falls back to offset pagination and is rate limited, so the integration always pages by cursor. Faire publishes no request rate in numbers; the API answers with HTTP 429, and the integration retries those calls from its queue after a pause. The real-time versus batch note covers how often a poll like this needs to run.

All-or-nothing batches

The stock and price endpoints take a list of SKUs in one call. By default a batch is all-or-nothing: one SKU that Faire does not know fails the whole request with a 404 and nothing is applied. Since September 2026 a request can set accept_partial_success: true; Faire then applies every SKU it resolves and returns the rest in bulk_validation_errors.

Worked through for a catalog of 1,200 SKUs where 3 were never published on Faire: without the flag, every stock update fails and 1,197 SKUs keep yesterday's numbers. With the flag, 1,197 are updated and the 3 are reported by SKU. The integration sets the flag and puts the rejected SKUs on a list in the dashboard instead of retrying them forever.

On hand, committed, available

Faire keeps three numbers per variant. on_hand_quantity is what the brand holds, committed_quantity is allocated to unfulfilled Faire orders, and available_quantity is on hand minus committed. On hand and available can be negative, which means oversold, or of type UNTRACKED. An ERP that reports free stock already excludes its open orders. Written to on_hand_quantity, that number has Faire's own commitments subtracted a second time: 40 free in the ERP with 6 units on open Faire orders becomes 34 available on Faire. The integration writes free stock through the available endpoint, which sets the number Faire sells directly. Which stock counts explains the difference.

Where a Faire integration gets stuck

Five Faire fields arrive in a different shape than the ERP keeps them:

Case packs and minimum quantities

A product has a unit_multiplier, the case size, and a minimum_order_quantity, which must be a multiple of it. An order item's quantity is the number of physical items. A retailer who orders three cases of a candle with a case size of 6 sends quantity: 18. An ERP that sells that candle per case needs 3 on the order line, and a price per case of 6 times the unit price. With a wholesale price of amount_minor: 450 in USD, that is 18 times 4.50 = 81.00 for the line, or 3 times 27.00. The integration converts per item, using the unit table from units of measure.

Money in minor units and prices per region

Every amount is an object with amount_minor and currency. 450 means 4.50 USD. A variant can hold a wholesale and a retail price per region, with geo_constraint set to one of the countries USA, CAN, GBR or AUS, or to the group EUROPEAN_UNION. An ERP price list in euros goes to the EU price and one in pounds to GBR, so a brand with three price lists sends three prices per variant. The older price_cents fields are deprecated and count in USD only; the integration reads price. More in money, tax and rounding.

Three-letter country codes

The shipping address carries country_code as ISO alpha-3 (USA, NLD), country as a full name and state as a full name next to state_code. Most ERPs and carriers expect two-letter codes. The integration converts NLD to NL and CAN to CA before the address reaches the sales order; the general rules are in address field mapping.

SKUs that changed after the order

The sku on an order item is the SKU at the time of the order and may no longer match the variant. A brand that renames SKUs in the ERP and pushes them to Faire breaks the match for every open order. The integration matches order items on variant_id first and keeps a table from Faire variant to ERP item.

Cancellations and identifiers

An order can only be canceled in the states NEW, PROCESSING, PENDING_RETAILER_CONFIRMATION and BACKORDERED, with a reason such as ITEM_OUT_OF_STOCK and a note of 30 to 1,000 characters for the retailer. Order IDs start with bo_; the retailer sees the same ID in capitals without the prefix, so bo_k7m2qx9wte is order #K7M2QX9WTE in their email. The integration stores both on the ERP order, along with purchase_order_number, which Faire takes as free text without validation.

Platforms and systems we connect to Faire

Faire orders end up in the ERP, so the system side matters most: NetSuite, Business Central and Odoo. When a brand runs its own B2B store next to Faire, on Shopify or Magento, both channels draw from the same ERP stock, which is where stock and availability integration comes in.

We build the integration to your Faire account, your case packs and your ERP, then host it, monitor it and adjust it when Faire changes an endpoint, as it did when it removed the old inventory endpoints on June 1, 2026. Before go-live it runs as a dry run that writes nothing, so you see every order, stock number and price it would send. Every integration comes with a dashboard, logs and a per-run diff. Tell us how Faire orders reach your ERP today.