BigCommerce is a fully supported source in Flxpoint, allowing you to connect your store as an inventory and fulfillment feed. This integration enables Flxpoint to pull product data, pricing, and inventory levels directly from your BigCommerce store, and—when configured—send orders back for fulfillment. By using BigCommerce as a source, you can maintain accurate stock levels, streamline order routing, and ensure your catalog in Flxpoint reflects your store’s latest product information.
How To Connect
📋 Phase 1: Create Your BigCommerce Source
+
Create Source in Flxpoint
Go to Sources → + Add Source. Name it BigCommerce and choose Vendor Warehouse (recommended). Click Save & Next.
Tip: Assigning a Vendor enables vendor-level reporting and optional Vendor Portal access.
Enable Order Fulfillment
When prompted, select Yes (Recommended) for “Eligible for Order Fulfillment” so you can route orders to this source.
Choose Integrations
In Integration Set-Up, click Start Creating Integrations and add what you need:
- Get Inventory (Primary)
- Send Fulfillment Requests
- Get Shipments
🔐 Phase 2: Set Up the BigCommerce Connection
+
Option A (Recommended, if you are Owner of the Store): BigCommerce API App (OAuth2)
In Flxpoint, click New BigCommerce Connection and choose BigCommerce API App (OAuth2).
-
Enter your Store Hash (found in BigCommerce Settings → Advanced → API → API Path; the value after
/stores/). - Click Save Connection. You’ll be prompted to install/authorize the Flxpoint app in your BigCommerce store to complete OAuth2.
- After authorization, click Test Connection in Flxpoint.
Why this? OAuth2 is simpler to maintain and doesn’t require sharing long-lived tokens.
Option B: Store-Level API Token (Manual Keys, for a Vendor Store)
If you prefer keys, create a Store-Level API Account in BigCommerce:
- Go to Settings → Advanced → API → Store-Level API Accounts and click Create API Account.
- Name it (e.g., Flxpoint Vendor). Note the API Path and copy the store hash from it.
-
Set permissions:
- Content – Read-only
- Information & Settings – Read-only
- Products – Read-only
- Customers – Modify
- Orders – Modify
- Order Transactions – Modify
- Click Save and capture the Client ID and Access Token (and store hash as above).
-
Back in Flxpoint, choose connection type BigCommerce API Bearer Token and fill:
- Connection Name
- Store Hash
- Client ID
- Access Token
- Click Test Connection, then Save Connection.
Security: Store keys securely. Rotate the token if access is ever shared or compromised.
🛒 Phase 3: Configure Order Processing
+
Use the BigCommerce Connection
Attach your BigCommerce connection to:
- Send Fulfillment Requests – sends orders to BigCommerce (as configured).
- Get Shipments – retrieves tracking and shipment updates.
Automation Settings
- Enable Automatically Send Orders if you want Flxpoint to transmit orders without manual review.
- Add any order-routing rules (minimums, categories, etc.) as needed.
✅ Phase 4: Mapping & Activation
+
Field Mapping for Inventory
Create or select a mapping for Get Inventory (Primary):
- Map SKU, Quantity, Price, Title/Description.
- Apply transformations (e.g., markup rules, qty adjustments) as needed.
Note: Include both product attributes and on-hand quantity fields.
Master SKU Strategy
In Master SKU, map Inventory SKU → Master SKU. Consider a prefix like BC- to identify BigCommerce-sourced items.
Activate & Verify
Click Save & Complete. Monitor the initial sync in Fulfillment Sources → Integrations. Run a test order and confirm shipment updates flow back correctly.
Product Operations
Get Inventory (Primary)
Supported | BigCommerce — Get Inventory (Primary)
Introduction
In Flxpoint, Get Inventory (Primary) — often abbreviated as GIP in job lists — is your main import job
for pulling product and quantity data from a source into Flxpoint.
For BigCommerce, this means connecting to your store and bringing in your entire catalog (products, variants, images, categories, stock levels).
Important: Here “GIP” refers to the job itself — not the Global Inventory Pool.
The Global Inventory Pool is the database inside Flxpoint that stores the inventory after the job runs.
Think of this job as your “BigCommerce → Flxpoint sync engine.” It exists to:
- Import your product list with all variants, images, and basic details.
- Keep your quantities in Flxpoint up to date with what’s in BigCommerce.
- Optionally skip unpublished/hidden products so your internal data matches your live store.
- Maintain your catalog structure (brand names, category levels) for easier mapping to channels.
Every run follows the same process:
- 1Connect via OAuth — Securely link your BigCommerce store to Flxpoint.
-
2Fetch Brands & Categories — Uses
GET v3/catalog/brandsandGET v3/catalog/categoriesto build reference lists. -
3Retrieve Products — Uses
GET v3/catalog/products?include=variants,imagesto pull complete product data. - 4Map Fields — Matches BigCommerce fields to your Flxpoint mapping template.
- 5Save Inventory — Updates quantities and product details in the Global Inventory Pool.
Example: If your “Blue Hoodie” in BigCommerce shows 15 in stock, after this job runs, Flxpoint will also show 15 units — ready to sync to Amazon, eBay, or Shopify.
Setting up the Get Inventory (Primary) job for BigCommerce is straightforward:
- 1Connect Integration — In your source, choose BigCommerce and authorize via OAuth.
-
2Configure Settings:
- Do Not Import Hidden Product — Yes to skip unpublished products (recommended).
- Archive/Un-Archive Inventory — Yes to remove items missing from the feed and restore them if they return. Note: Don’t enable this if a Secondary job is already set to archive.
- Product Page Size Limit — 250 is a good balance for performance and avoiding API limits.
- 3Create a Mapping Template — See mapping section below for recommendations.
- 4Save & Schedule — You can run manually or set up automatic scheduling (UTC time).
For reliable imports, at minimum, map these fields:
| Flxpoint Field | BigCommerce Source | Why It’s Needed |
|---|---|---|
| SKU | variants.sku | Unique identifier for matching products. |
| Title | name | For product display and identification. |
| Quantity | variants.inventory_level | Controls available stock in Flxpoint. |
| Brand | brand_id → brands.name | Ensures consistent brand labeling. |
| Categories | categories[0–2] | Organizes products; up to 3 levels supported. |
| Image URL | images[0].url | Main product image. |
| Weight | weight | Important for shipping calculations. |
| Dimensions | width, height, depth | Helps determine packaging needs. |
| Price / MSRP / Cost | price, retail_price, cost_price | Pricing info for listings and reporting. |
When this job runs, it will:
- Import all variants for each product, updating their individual stock counts.
- Bring in standard pricing (Price, MSRP, Cost) in your store’s currency.
- Import weights and dimensions in metric units (KGS/cm).
- Include the main image and up to 3 levels of categories.
- Run as a full feed every time — no partial (delta) updates.
- Optionally archive missing products if configured.
- Not supported: BigCommerce Custom Fields, multiple warehouses, client-specific pricing.
If your job results aren’t as expected:
- Missing products? Check SKUs in BigCommerce and confirm “Do Not Import Hidden Product” isn’t hiding them.
- Zero quantities? Ensure inventory tracking is enabled for variants and quantities are entered.
- Slow imports? Lower page size or run at off-peak hours to avoid API rate limits.
Set a schedule so this job runs automatically. This ensures your Flxpoint data is always current without manual runs. Remember: schedules run in UTC time, so adjust for your time zone.
Order Operations
Send Fulfillment Requests
Supported | BigCommerce — Send Fulfillment Requests
Works great for teams seeing this for the first time or power users who want the specifics.
What this job does
Send Fulfillment Requests (often abbreviated as FR) creates an order in your connected BigCommerce store
using the items approved in a Flxpoint Fulfillment Request.
That order can then be processed/fulfilled by your BigCommerce apps, automations, or warehouse workflow.
Quick glossary:
FRFulfillment Request — the document Flxpoint generates once an order is ready to send to a supplier or internal warehouse.,
POPurchase Order — sometimes used interchangeably with FR. In this job, we send an order into BigCommerce.,
SKUStock-Keeping Unit — the product code used to match your FR item to the correct BigCommerce product/variant..
- 1Connect — OAuth to your BigCommerce store.
- 2Find products — FR line SKUs are matched in BigCommerce (v2 product endpoints).
- 3Variant lookup — If a variant is needed, we fetch product skus for the chosen product.
- 4Create order — We POST the order to /v2/orders with the matched product/option info.
- 5Auto-acknowledgement — The BigCommerce response contains the order_id which acts as the FR acknowledgement.
Tip: If you need a two-letter state code, add a customer form field in BigCommerce named “State Code” and map it below.
Order Customer ID
Choose how the order is associated with a BigCommerce customer:
- Send order as guest — Fastest. No customer is created/required.
- Create a new customer if it does not already exist using PO details — Great when you want history under a named account.
- Use an existing customer from PO details, or fail the order if it does not already exist — For strict customer policies.
Advanced
-
Hold for X hours — Pause sending for a short review window.
Example: Set to 2 hours to give your team time to cancel or adjust before it leaves your queue.
- Only send during business hours — Queue FRs to send only within your business hour window.
Schedule
Turn on Scheduled to run automatically (times are in UTC). You’ll receive a notification each time it runs.
Map the data Flxpoint should place into the BigCommerce order. Fields shown here are available in your template.
Billing Address
Required to process FRs in BigCommerce.
| Field | Notes |
|---|---|
| Address Line 1 / 2 | Street address; line 2 is optional. |
| City, State, State CodeTwo-letter code (e.g., CA). Create a BigCommerce form field named “State Code” if you need it., Postal Code | Use either State name or State Code; Code is best for carriers. |
| Country / Country Code | Country name and optional ISO code. |
| First Name, Last Name, Full Name | Map First/Last (preferred) or Full Name. |
| Company Name | Optional; used for B2B addresses. |
| Email, Phone | Helpful for delivery updates. |
Shipping Address
| Field | Notes |
|---|---|
| Address Line 1 / 2 | Street address for delivery. |
| City, State, State CodeIf mapped, ensures carriers get the standardized code., Postal Code | |
| Country / Country Code | |
| First Name, Last Name, Full Name | |
| Company Name, Email, Phone |
Fulfillment Request (order-level metadata)
| Field | Type | How it’s used |
|---|---|---|
| Estimated Shipping Cost | Number | For your internal reporting; not sent as a BigCommerce shipping quote. |
| Estimated Dropship Fee | Number | Optional cost tracking. |
| Total Cost | Number | Internal. |
| Total Weight (lbs) | Number | Internal. |
| Generated At / Sent At | Date | Timestamps for audit. |
| Note | Text | Human-readable memo with the order. |
| Fulfillment Request Number | Text | Not sent to BigCommerce as a dedicated FR# field (BC doesn’t support that directly). |
Source Shipping Method
| Field | Notes |
|---|---|
| Carrier | e.g., UPS, FedEx. |
| Method | e.g., Ground, 2-Day. |
| Name | Friendly name you prefer to store. |
| Shipping Code | Internal/service code if you use them. |
Status
Orders are created in Awaiting Fulfillment status by default (typical for handoff to fulfillment apps).
Minimum viable mapping
Billing Address: First/Last, Email, Phone, Address 1, City, State (or State Code), Postal Code, Country. Shipping Address: same as above. Items: ensured by SKU match (see How it works).
Billing Address: First/Last, Email, Phone, Address 1, City, State (or State Code), Postal Code, Country. Shipping Address: same as above. Items: ensured by SKU match (see How it works).
- Order API: Uses BigCommerce v2 endpoints for order creation.
- Item matching: We look up the FR item’s SKU. If it’s a variant, we fetch the product’s variant skus to select the right option.
- Auto-ack: The BigCommerce order_id returned acts as your acknowledgement.
- Limitations: BigCommerce requires a valid Billing Address; Custom fields and attachments are not sent. Shipping methods are unique per customer.
Heads-up: If “Send order as guest” is selected, BigCommerce won’t tie the order to an existing customer.
Choose a customer option if you rely on customer-level shipping methods or discounts.
- Couldn’t match item? Confirm the SKU in the FR exactly matches the BigCommerce SKU (case and spaces matter).
- Order failed with address error? Ensure Billing Address fields are mapped and non-empty.
- Need a two-letter state? Add a customer form field in BigCommerce called “State Code” and map it here.
- Want a pre-send review? Use Hold for X hours and/or enable Only send during business hours.
Example 1 — Guest gift order
Order Customer ID: Send order as guest • Hold: 0 • Status: Awaiting Fulfillment
Billing/Shipping mapped from marketplace order. Result: BC order created without customer record, ready for pack/ship.
Order Customer ID: Send order as guest • Hold: 0 • Status: Awaiting Fulfillment
Billing/Shipping mapped from marketplace order. Result: BC order created without customer record, ready for pack/ship.
Example 2 — B2B repeat customer
Order Customer ID: Use an existing customer… • Billing set to the company HQ • Shipping to a branch.
If the customer email doesn’t exist, the job fails (by design) so your team can fix it.
Order Customer ID: Use an existing customer… • Billing set to the company HQ • Shipping to a branch.
If the customer email doesn’t exist, the job fails (by design) so your team can fix it.
Example 3 — Review window
Hold for X hours: 2 • Only send during business hours: checked.
Orders queue right away but don’t hit BigCommerce until within your window, giving time to cancel duplicates.
Hold for X hours: 2 • Only send during business hours: checked.
Orders queue right away but don’t hit BigCommerce until within your window, giving time to cancel duplicates.
Get Shipments
Supported | BigCommerce — Get Shipments
pulls shipment updates (tracking, packages, partials) from bigcommerce back into your fulfillment requests.
what this job does
Get Shipments listens for shipments in your BigCommerce store and brings them back to Flxpoint so your
Fulfillment RequestsFRs — the requests Flxpoint creates when an order is ready to be sent to a supplier/warehouse.
can be marked shipped (fully or partially), with tracking details attached.
Good to know: This job usually runs after you’ve sent the order with Send Fulfillment Requests.
Once the warehouse/BC app fulfills, Get Shipments grabs the tracking and updates the FR automatically.
- 1Connect — OAuth to your BigCommerce store.
-
2Find shipments — For each FR’s BC order, we request
GET /v2/orders/{orderId}/shipments. -
3Match items — When shipments exist, we also request
GET /v2/orders/{orderId}/productsto associate shipped quantities to the right FR lines (via product/variant IDs that map back to SKUs). - 4Update FR — We attach tracking (#, carrier, method, link) and mark the FR partially shipped or shipped depending on what was fulfilled.
example: BC shows 1 of 3 items shipped with a tracking number. The FR in Flxpoint moves to Partially Shipped and displays that tracking number.
When the remaining 2 items ship later, the FR becomes Shipped and the second tracking is added.
- 1connect an integration — choose BigCommerce and authorize via OAuth.
-
2configure settings:
- FR lookback period — Only FRs created within this window are considered (default ~90 days). why?To keep the job fast. Very old FRs are unlikely to receive new shipments and slow the sync.
- 3define a mapping template — map where shipment data should land (details below).
- 4save & schedule — run manually or set a schedule (times are in UTC).
These fields are commonly mapped for BigCommerce shipments. You don’t need them all; start with the basics and add more as needed.
tracking & carrier
| field | sample value | why it matters |
|---|---|---|
| Tracking Number | 1Z999AA10123456784 | Lets customers and support track the package. |
| Tracking Link | https://wwwapps.ups.com/WebTracking/track… | Clickable link for faster access. |
| Tracking Carrier | UPS | Carrier label coming from BC or your app. |
| Shipping Provider | ShipStation | Optional—who created the label. |
| Shipping Method | UPS® Ground | Service/method used on the shipment. |
item association & quantities
BigCommerce responses include product_id / variant_idIdentifiers for the product and its variant in BigCommerce.. We use those to map back to the correct FR line (which was originally matched by SKU). Partial quantities are supported.
minimum viable mapping
Tracking Number, Tracking Carrier, Shipping Method. (Item association happens automatically via the order’s products/variants.)
Tracking Number, Tracking Carrier, Shipping Method. (Item association happens automatically via the order’s products/variants.)
- Carrier & method: Returned with each shipment and saved to your mapped fields.
- Item association: We use product_id/variant_id from BC to update the correct FR lines.
- Partial shipments: Fully supported—FR status progresses from Open → Partially Shipped → Shipped.
- Invoices & custom fields: Not imported by this job.
- Lookback window: FRs older than the configured period are ignored to keep the job performant.
heads-up: If you don’t see a shipment, first confirm the FR’s BigCommerce order actually has a shipment on it and the FR isn’t outside your lookback window.
- No shipments found? Check the FR age vs. your lookback period and verify the BC order has a shipment.
- Lines didn’t update? Make sure the items in the BC order are the same SKUs you sent in the FR; mismatches can’t be associated.
- Partial vs full? If only some items shipped, the FR will remain Partially Shipped until all lines have shipped.
example 1 — single-package order
One shipment with tracking number is created in BC. Next sync: FR becomes Shipped and shows the tracking.
One shipment with tracking number is created in BC. Next sync: FR becomes Shipped and shows the tracking.
example 2 — multi-package order
Two shipments, two tracking numbers. FR stores both and is marked Shipped when the second posts.
Two shipments, two tracking numbers. FR stores both and is marked Shipped when the second posts.
example 3 — partial shipment
1 of 3 items ships. FR switches to Partially Shipped. When the last 2 items ship later, status updates automatically.
1 of 3 items ships. FR switches to Partially Shipped. When the last 2 items ship later, status updates automatically.