See what the BigCommerce integration can do →

This document catalogs the BigCommerce REST API endpoints called by the iPaaS.com BigCommerce integration, grouped by data type. Its primary purpose is to provide a complete inventory of every endpoint the integration depends on, so that when BigCommerce publishes a deprecation or breaking-change notice you can quickly determine whether the integration is affected. It also serves as a reference for firewall allow-listing, API account scope review, troubleshooting, and understanding how data flows between BigCommerce and your connected systems.

The BigCommerce integration exchanges data in both directions. Storefront data such as orders, customers, and gift cards is read To iPaaS.com; products, categories, inventory, and related catalog and B2B records are written From iPaaS.com. For how those flows are configured, see the BigCommerce Connections and Settings article.

BigCommerce exposes a REST API that exchanges JSON request and response bodies. The integration uses two BigCommerce APIs:

Both APIs are single global hosts — there is no per-region base URL. The store the integration acts on is identified by the store hash, which the integration reads from your subscription settings.

Throughout this document the placeholder [Base URL] refers to the REST Management base with the store-hash and version prefix already applied — that is, https://api.bigcommerce.com/stores/{store_hash}/v3 for v3 endpoints, or https://api.bigcommerce.com/stores/{store_hash}/v2 for the v2 endpoints (which are shown with their explicit /v2/ segment). For B2B Edition endpoints, [B2B Base URL] refers to https://api-b2b.bigcommerce.com/api/v3/io.

For example, [Base URL]/catalog/products resolves to https://api.bigcommerce.com/stores/{store_hash}/v3/catalog/products, and [B2B Base URL]/companies resolves to https://api-b2b.bigcommerce.com/api/v3/io/companies.

Sandbox / Test URL: BigCommerce does not publish a separate sandbox host. To test against a non-production store, provision a BigCommerce sandbox or development store and configure a separate iPaaS.com subscription against that store's hash and API credentials. Both the production and sandbox stores are reached through the same api.bigcommerce.com and api-b2b.bigcommerce.com hosts.

Endpoint paths, pagination, and rate-limit behavior in this document were verified against the BigCommerce REST API documentation as published July 2026.

Order data is served by the BigCommerce v2 API. Orders are read into iPaaS.com and, for the write-back scenarios, created and updated in BigCommerce.

Lists orders, filtered by the poll window and any configured filters. Used to pull new and updated orders into iPaaS.com.

Retrieves a single order by its BigCommerce order Id.

Creates an order in BigCommerce from an iPaaS.com transaction.

Updates an existing BigCommerce order.

Deletes a BigCommerce order.

Lists the line-item products on an order. Used when reading an order's line detail into iPaaS.com.

Retrieves a single order line-item product.

Lists the shipping addresses on an order.

Retrieves a single order shipping address.

Lists the coupons (order-level discounts) applied to an order.

Lists the tax rows on an order.

Retrieves a single order tax row.

Lists the notes/messages attached to an order.

Retrieves a single order note/message.

Lists the status history for an order.

Retrieves a single order status entry.

These endpoints read payment-transaction and refund detail associated with orders. They are served by the v3 API.

Lists the payment transactions recorded against an order (authorizations, captures, refunds). Used to build the payment detail on an iPaaS.com transaction.

Lists the refunds issued against a specific order.

Retrieves one or more refunds by refund Id. The id:in query parameter accepts a comma-separated list of Ids.

Shipments are served by the v2 API and are written from iPaaS.com when fulfillment data is synchronized to BigCommerce.

Lists the shipments recorded on an order.

Retrieves a single shipment, including its tracking number.

Creates a shipment on an order.

Updates an existing shipment (for example, to set or change a tracking number).

Products are served by the v3 Catalog API. This is the core write path for the From iPaaS.com product flow.

Lists products. Used when reading products into iPaaS.com and when resolving an existing product before an update.

Retrieves a single product by its BigCommerce product Id.

Retrieves a product with only its category assignments included. Used when synchronizing a product's category membership.

Looks up a product by its SKU. Used to match an incoming product to an existing BigCommerce product when no external-Id link exists yet.

Creates a new product in BigCommerce.

Updates an existing product.

Deletes a single product.

Bulk-deletes products filtered by visibility. Used only by cleanup/reset operations, not by routine synchronization.

Variants are child records of a product in the v3 Catalog API.

Lists the variants of a product.

Retrieves a single variant.

Looks up a variant by SKU within a product.

Looks up variants store-wide by SKU (across all products).

Creates a variant under a product. Also used to write variant inventory.

Updates a variant, including its inventory level.

Deletes a variant.

Product options and option values define the variant matrix. Served by the v3 Catalog API.

Lists the options defined on a product (for example, "Size", "Color").

Creates a new option on a product.

Updates an existing product option.

Lists the values defined under a product option.

Updates a specific option value.

These are additional child collections on a product in the v3 Catalog API.

Lists a product's custom fields.

Retrieves a single custom field.

Creates a custom field on a product.

Updates a custom field.

Deletes a custom field.

Lists a product's images.

Retrieves a single product image.

Adds an image to a product.

Updates an existing product image.

Deletes a product image.

Lists a product's modifiers.

Retrieves a single modifier.

Creates a modifier on a product.

Updates a modifier.

Deletes a modifier.

Deletes a specific value from a product modifier.

Metafields store custom key/value data on products and variants in the v3 Catalog API.

Lists a product's metafields.

Creates a metafield on a product.

Updates a product metafield.

Deletes a product metafield.

Lists a variant's metafields.

Creates a metafield on a variant.

Updates a variant metafield.

Deletes a variant metafield.

Channel assignments control which storefront channels a product is published to, in the v3 Catalog API.

Lists the channels a product is assigned to. The channel_id:in and product_id:in query parameters each accept a comma-separated list of Ids.

Creates or updates product-to-channel assignments.

Removes product-to-channel assignments matching the supplied channel and product Ids.

Brands are top-level catalog records in the v3 Catalog API.

Lists brands. Used to resolve a brand name to a brand Id during product writes.

Retrieves a single brand.

Creates a brand.

Updates a brand.

Deletes a brand.

Categories are organized into category trees in the v3 Catalog API.

Retrieves categories by Id. The category_id:in query parameter accepts a comma-separated list of Ids.

Lists all categories belonging to a specific category tree.

Creates one or more categories.

Updates one or more categories.

Creates or updates a category tree.

Deletes categories matching the supplied Ids.

Bulk-deletes categories. Used only by cleanup/reset operations, not by routine synchronization.

Price lists carry customer-group-specific and variant-specific pricing in the v3 API.

Lists the price lists assigned to a customer group. The customer_group_id:in query parameter accepts a comma-separated list of Ids.

Retrieves price-list records for one or more SKUs within a price list.

Creates or updates price-list records (upsert) within a price list.

Removes price-list records for one or more variants within a price list.

Customers are served by the v3 API.

Lists customers, optionally filtered. The integration commonly requests related data in the same call using the include parameter — for example include=addresses,storecredit,attributes,formfields.

Creates one or more customers.

Updates one or more customers.

Deletes customers matching the supplied filter.

Customer addresses are a child collection of customers in the v3 API.

Creates one or more customer addresses.

Updates one or more customer addresses.

Customer attributes are store-defined custom fields on customers, in the v3 API.

Lists customer attribute definitions.

Creates a customer attribute definition.

Updates a customer attribute definition.

Lists the attribute values set on customers.

Creates or updates attribute values on customers (upsert).

Customer groups map to iPaaS.com customer categories and are served by the v2 API.

Lists customer groups.

Retrieves a single customer group.

Creates a customer group.

Updates a customer group.

Deletes a customer group.

Gift cards (gift certificates) are served by the v2 API.

Lists gift certificates. Used to read gift cards into iPaaS.com.

Retrieves a single gift certificate.

Creates a gift certificate.

Updates a gift certificate.

Deletes a gift certificate.

These reference-data endpoints are served by the v2 API.

Lists the store's enabled payment methods. Used to map payment data on incoming orders.

Lists the store's tax classes.

Retrieves a single tax class.

Storefront redirects are managed through the v3 API when product URLs change.

Creates or updates 301 redirects on the storefront (for example, after a product's URL changes).

Webhooks (hooks) are served by the v2 API and let the integration subscribe to store events.

Lists the webhooks registered on the store.

Retrieves a single webhook.

Registers a new webhook.

Updates an existing webhook.

Removes a webhook.

The following endpoints are served by the B2B Edition API and are only called when B2B Edition is enabled on the subscription. Unlike the REST Management API, B2B Edition endpoints do not carry the store hash in the path — the store is identified by the request headers instead.

Lists companies, paged with limit and offset.

Retrieves a single company.

Creates a company.

Updates a company.

Deletes a company.

Sets a company's status (for example, to approve or reject a company).

Retrieves the payment terms configured for a company.

Updates the payment terms for a company.

Updates the payment methods enabled for a company.

Company addresses are managed through the B2B Edition API.

Retrieves a single company address.

Lists company addresses matching a filter (for example, by company Id).

Creates a company address.

Updates a company address.

These endpoints manage parent/subsidiary company hierarchies and super-admin relationships in the B2B Edition API.

Lists the super-admin users attached to a company.

Lists the companies a super-admin is attached to.

Retrieves a super-admin's details.

Lists a company's subsidiary companies.

Retrieves the hierarchy (parent chain) for a company.

Assigns a parent company to a company, establishing the parent/subsidiary relationship.

Removes a subsidiary from a parent company.

Lists the sales-staff users assigned to a company.

Assigns or updates a sales-staff assignment.

Company users (B2B customers) are managed through the B2B Edition API.

Retrieves a single company user.

Retrieves a company user by the associated storefront customer Id.

Creates a company user.

Updates a company user.

Deletes a company user.

Retrieves the custom "extra field" definitions for a B2B resource type (for example, companies or users). {tableName} identifies the B2B resource whose extra-field schema is being read.

Quotes (requests for quote) are read through the B2B Edition API.

Retrieves a single quote by its Id, including its line items and addresses.

B2B orders and invoices are managed through the B2B Edition API.

Retrieves a single B2B order.

Lists the line-item products on a B2B order.

Lists invoices matching a filter.

Retrieves a single invoice.

Generates an invoice from a B2B order.

B2B payment data is read through the B2B Edition API.

Lists the store-level payment methods available to B2B.

Lists the payments recorded against an invoice, paged with offset and limit.

Lists invoice payments matching a filter.

The integration authenticates to the REST Management API using a store-level API account access token, sent on each request in the X-Auth-Token header (with the API account's Client ID, where applicable). The store is identified by the store hash in the URL path. This token does not expire on a fixed schedule — it remains valid until the API account is deleted or its scopes are changed in BigCommerce. There is no token-exchange call for routine API traffic; the token is created once in the BigCommerce control panel and entered into the subscription settings. For credential setup and the exact scopes to grant, see the BigCommerce Connections and Settings article.

For the B2B Edition API, requests are authenticated with a B2B server-to-server auth token sent in the X-Auth-Token header together with the X-Store-Hash header. When a dedicated B2B token is required, the integration obtains it from BigCommerce's B2B authentication endpoint:

Some app-based installations complete a one-time OAuth authorization when the app is connected. In that flow, BigCommerce issues the access token through its OAuth token endpoint:

This exchange happens only during app installation/authorization, not during routine synchronization.

The v3 REST Management API returns list results in a data array wrapped in a response envelope that includes a meta.pagination object with total, count, per_page, current_page, and total_pages. List requests are paged with the page and limit query parameters (default page size is 50; the maximum is 250). When a list response reports more than one page, the integration automatically requests the remaining pages and combines the results, so multi-page result sets are handled transparently.

The v2 REST Management API does not use the meta.pagination envelope; it returns a plain array and is paged with page and limit query parameters. An empty response (HTTP 204 No Content) indicates there are no further pages.

The B2B Edition API pages with offset and limit query parameters, as shown on the company and invoice-payment endpoints above.

Pagination behavior above was confirmed against the BigCommerce REST API documentation as published July 2026.

BigCommerce rate-limits the REST Management API using a request quota that refreshes on a rolling 30-second window. Per the BigCommerce API rate-limit documentation (published July 2026), the quota per 30-second window depends on the store's plan:

Every REST Management API response carries the current rate-limit state in these headers:

When the quota is exhausted, BigCommerce returns HTTP 429 Too Many Requests. The integration reads these headers and, on a 429, pauses and retries after the reset window rather than failing the transfer outright. It also retries transient BigCommerce server errors (HTTP 500, 502, 503, 504) a small number of times with a short backoff before surfacing an error. If persistent rate-limit or server errors continue to appear in your transfer logs, reduce the volume or frequency of transfers, or contact iPaaS.com Support. Repeated 429 responses are reported through the standard error path — see the BigCommerce Integration - Error Messages article for how these surface.

The B2B Edition API is subject to its own throttling. When B2B synchronization volume is high, stagger B2B transfers to avoid overwhelming the B2B endpoints.

External References