Reference · built on requestConnectorCommerce & orders

BigCommerce

Orders, customers, products, and inventory levels from a BigCommerce store, with webhooks for order and shipment changes.

Request accessPricing ↗

About

BigCommerce is a hosted storefront platform. Each store exposes a REST Management API under api.bigcommerce.com/stores/{store_hash}, with Orders on V2 and Customers, Catalog, and Inventory on V3. Webhooks push order, shipment, customer, product, and cart events to a URL you register, and retry for up to 48 hours before the webhook is deactivated.

Through Fibric, an operator reads orders as they change status, checks stock by location, and proposes a status update, a shipment record with its tracking number, or a refund from a refund quote, for your approval. Each proposal leaves a receipt: what changed, why, and how to undo it.

This is a reference listing. It documents what Fibric would read from BigCommerce and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Orders with products, shipping addresses, coupons, messages, and statuses through the Orders V2 API
  • Order webhooks: store/order/created, store/order/updated, store/order/statusUpdated, store/order/refund/created
  • Customers with addresses, attributes, form field values, and consent settings through the Customers V3 API
  • Inventory quantities and settings per location, referenced by variant_id, sku, or product_id
  • Shipment events: store/shipment/created, store/shipment/updated, store/shipment/deleted
  • Product and cart events, including store/product/inventory/updated and store/cart/abandoned

Proposed actions

  • Target capability: propose an order status change with PUT /v2/orders/{order_id} and a new status_id
  • Target capability: propose a shipment on an order with tracking_number, shipping_provider, and the items shipped
  • Target capability: propose a refund from a refund quote under /v3/orders/{id}/payment_actions/
  • Target capability: propose an absolute or relative inventory adjustment at a location

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Record the shipment before the customer asks

    Read the ShipStation label event, then propose a BigCommerce shipment with the tracking number so the storefront shows it.

    With Tracking Sync, WISMO Deflection

  • Hold an order that looks wrong

    Watch store/order/created, check the shipping address and order history, and propose a status change that holds the order before pick.

    With Order Risk, Address Repair

  • Keep stock honest across locations

    Subscribe to store/product/inventory/updated and propose an absolute adjustment when the warehouse count and the store disagree.

    With Oversell Watch, Stockout Forecast

  • Refund the right amount, once

    Take a refund quote for the returned items, show the total and tax, and propose the refund to the original payment method for approval.

    With Returns Triage, Refund Policy

Requirements

  • A BigCommerce store and a store-level API account; its token and OAuth scopes cannot be changed after creation
  • Scopes for what the operator reads or proposes: store_v2_orders, store_v2_customers_read_only, store_v2_products_read_only, store_inventory
  • An HTTPS destination that answers webhook deliveries with HTTP 200
  • For refunds, an order that has been paid and a payment gateway that supports refunds
Authentication
A store-level API account created in the control panel under Settings > Store-level API accounts; its access token is sent in the X-Auth-Token header.

Limits

  • Rate limits are per store and shared by every app on it: Pro plans 450 requests per 30 seconds, Plus and Standard 150; Enterprise varies
  • At most 10 webhooks per store, client, and scope combination, and only one per destination
  • A webhook whose destination keeps failing is deactivated after the final retry and must be recreated
  • Refunds take two calls: a refund quote first, then the refund itself

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request BigCommerce ↗

Questions and answers

Which BigCommerce API version does this connector read orders from?
Orders V2. It carries order products, shipping addresses, coupons, messages, statuses, taxes, and shipments. Refunds use Orders V3 under /v3/orders/{id}/payment_actions/, with a refund_quotes step followed by the refund itself.
How does BigCommerce tell Fibric that an order changed?
Through webhooks. You register a destination URL for scopes such as store/order/updated or store/order/statusUpdated. BigCommerce expects an HTTP 200 reply, retries failed deliveries for up to 48 hours, then deactivates the webhook and emails the registered app address.
How many API calls can the connector make?
It depends on the plan. Pro stores allow 450 requests per 30 seconds, Plus and Standard 150. All apps on a store share that quota, and each response carries X-Rate-Limit-Requests-Left and X-Rate-Limit-Time-Reset-Ms headers. A 429 means wait for the window to reset.
Ask about BigCommerce

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with BigCommerce through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy