# Running ChatGPT ads for a BigCommerce store, end to end

URL: https://adsonomy.com/guides/chatgpt-ads-for-bigcommerce-stores
Published: 20 September 2026
Last updated: 20 September 2026
Plain-text version of the page above. Adsonomy is an independent product and is not affiliated with OpenAI or BigCommerce.

## Summary

The deep BigCommerce version of running ads in ChatGPT: how a store is connected with a store-level API account, how the catalogue is read one row per variant over Catalog v3, why a variant price that is null means inherit rather than zero, which nine columns decide whether a product can be advertised at all, how orders from Orders v2 and the Script Manager scripts together measure a conversion, what the first campaign consists of, and which BigCommerce steps are manual or not built. The shorter overview covering Shopify, WooCommerce and BigCommerce together is at https://adsonomy.com/guides/openai-ads-for-shopify-woocommerce-bigcommerce.

## Key facts

- A BigCommerce store is connected with a store-level API account holding read-only Products and Orders scopes (store_v2_products_read_only, store_v2_orders_read_only, whose v2 naming governs the v3 endpoints too). That route is documented and still open, unlike the Shopify "Develop apps" route, which closed on 1 January 2026.
- Adsonomy asks for four values: store hash, access token, storefront URL and a fallback currency. Credentials are encrypted at rest.
- The storefront URL matters because a product's custom_url.url is a path and the Catalog API never returns the store domain; without it product links fall back to the store hash host at mybigcommerce.com.
- Catalog v3 is used for products and Orders v2 for orders. Products page at 250; orders and order line items page at 50.
- The catalogue is read one row per variant. A product with no options still yields exactly one row, hidden products are skipped and preorder products are kept.
- Every money and measurement field on a BigCommerce variant is nullable and null means inherit from the parent product, not zero. Reading null as zero is the most common cause of a catalogue showing 0.00 prices in any tool.
- calculated_price is what a shopper pays. It is never null and already carries the sale price, the price list and any adjustment rule.
- A v3 product carries brand_id, an integer, and no brand name, so the brand list and the category tree are each read once per sync.
- The product file requires nine columns on every row: item_id, title, description, url, brand, seller_name, image_url, availability, price. A row missing one is left out of the upload with the product and field named.
- Brand, image URL, price, currency, title, description, category, GTIN and MPN can be corrected inside Adsonomy; the correction wins over the store and survives the next sync.
- Catalogue syncs run every six hours; the product feed gets a full push daily and a price and availability delta every 30 minutes when something changed.
- Orders are polled every 30 minutes with a 48 hour overlap and relayed as order_created events with the BigCommerce order id as the event ID. Status 4, 5 and 6 (Refunded, Cancelled, Declined) are skipped; status 14 (Partially Refunded) is not treated as a cancellation.
- The BigCommerce order payload carries no click reference, so the server event cannot carry one; the browser script is what records the visit.
- Not built for BigCommerce: inbound webhooks, automatic Script Manager installation, and an OAuth app install. The two Script Manager scripts are generated with the pixel id filled in and pasted by the merchant.
- Conversion events need a timestamp within the last 7 days. The click window is set on the conversion event and insights requests take no window parameter.
- Custom audiences are not available for campaigns targeting the EEA or Switzerland.

## Full text

BigCommerce holds everything ChatGPT ads need, but in three places: the catalogue in Catalog v3, the orders in Orders v2, the storefront scripts in Script Manager. This guide is the BigCommerce path from a store with no ad account to a first campaign. What to connect, what the catalogue has to contain before a product can be served, why a BigCommerce catalogue reads as zero prices in so many tools, how an order becomes a measured conversion, and what is still manual. The [shorter overview across Shopify, WooCommerce and BigCommerce](https://adsonomy.com/guides/openai-ads-for-shopify-woocommerce-bigcommerce) covers what the three have in common; this page does not repeat it.

**Key takeaways**

- Connect with a store-level API account holding read-only Products and Orders scopes. That route is documented and open, so there is no app install and no review.
- Set the storefront URL when you connect: the Catalog API returns a path and never your domain, and a feed row needs a public HTTPS product page.
- A variant money field that is null means inherit from the product, not zero. That one confusion is why BigCommerce catalogues turn up priced at 0.00.
- Nine columns decide whether a product can be advertised at all, and brand is one of them, which catches stores that never filled it in.
- Orders are polled, not pushed, and the two Script Manager scripts are generated for you but pasted by you.

**Key facts**

- Connection: the store hash plus an access token from a store-level API account with read-only Products and Orders scopes (`store_v2_products_read_only`, `store_v2_orders_read_only`, whose v2 naming governs the v3 endpoints too).
- Catalog v3 for products, Orders v2 for orders. Products page at 250; orders and order line items page at 50.
- The catalogue is read one row per variant; a product with no options still yields exactly one row.
- Variant money fields are nullable and null means inherit from the product. `calculated_price` is what a shopper pays and is never null.
- Required product file columns: item_id, title, description, url, brand, seller_name, image_url, availability, price.
- Cadence today: catalogue every six hours, full feed file daily, price and availability deltas every 30 minutes, orders every 30 minutes.
- Conversion events need a timestamp within the last 7 days. The click window is set on the conversion event, and insights requests take no window parameter.
- Not built for BigCommerce: inbound webhooks, automatic Script Manager installation, an OAuth app install.

### A BigCommerce store connects with an API account, not an app install

Create a store-level API account in the control panel under Settings, API accounts, give it read-only Products and Orders scopes, and paste the store hash and the access token into Adsonomy. The scopes are named `store_v2_products_read_only` and `store_v2_orders_read_only`, and the v2 in those names governs the v3 endpoints as well. That route is the documented way to read a store and it has not been withdrawn, unlike the Shopify "Develop apps" route, which closed on 1 January 2026 and pushed every new Shopify store onto an install flow.

The form asks for four things: store hash, access token, storefront URL and a fallback currency. The credentials are encrypted at rest. Storefront URL is the one people skip and the one that bites: a product's `custom_url.url` is a path, and the Catalog API never returns the store domain, so without it product links fall back to the store hash host at `mybigcommerce.com`, which is not the address your customers see and not a URL you want in an ad.

The Orders scope is not optional if you want sales reported: it is what the server-side conversion relay reads, and without it the platform sees clicks but never revenue. Testing the connection reads one product and reports the store's product count, which settles the token and the scopes in one call.

### The catalogue is read one row per variant, because a variant is what a shopper buys

Adsonomy reads every visible product and expands it to its variants, one row each, because the variant is what carries the price and the stock. A product with no options still yields exactly one row. Hidden products are skipped, since a hidden product has no storefront page to send a click to, while preorder products are kept, because a preorder is still something you can advertise.

Each row carries the product name with the variant option labels appended, the description, the storefront URL, the brand, the GTIN or UPC, the MPN or SKU, the image, the regular and sale price, the currency, the stock quantity, the category path and the unit cost. Two of those need a second call, because a v3 product carries category ids and a `brand_id` integer with no names attached: the category tree and the brand list are each read once per sync and mapped in. Brand is a required column in the product file, so a store that never filled brands in loses those rows.

Stock depends on what the store tracks. `inventory_tracking` is none, product or variant, and a store tracking nothing gives no quantity, so stock rules have nothing to read. A variant with `purchasing_disabled` reads as out of stock whatever the quantity says. Cost comes from `cost_price`, where 0 means the merchant never entered one and is stored as unknown rather than free, because a product that costs nothing breaks every margin below it.

Cadence today is six hours for the shop catalogue, a full feed file once a day, and a price and availability delta every 30 minutes when something changed. Reads stay inside the store's rate limit, which BigCommerce enforces over a 30 second window, 150 requests on Standard and 450 on Pro.

### A null price on a variant means inherit, and reading it as zero empties a catalogue

Every money and measurement field on a BigCommerce variant is nullable, and null means use the parent product value, not zero. A tool that casts null to a number gets 0.00 and prices every inheriting variant at nothing, silently, with no error and no rejected row. This is the single most common reason a BigCommerce catalogue appears with zero prices in any tool, and it is the first thing worth checking when you see it.

The price a shopper actually pays is `calculated_price`. It is never null and it already carries the sale price, the price list and any adjustment rule that applies. Adsonomy takes it as the effective price and keeps the configured price as the regular one, so a discount reads as a discount in the feed and in the ad rather than as a permanent price drop. The same inherit rule covers cost and the measurement fields. If prices look wrong anywhere, look at the variant rows rather than the products: a store where most variants inherit is perfectly normal, and it only becomes a problem when something downstream treats the blank as a number.

### Nine columns decide whether a product can be advertised at all

The product file OpenAI expects requires item_id, title, description, url, brand, seller_name, image_url, availability and price on every row. A row missing one of them is left out of the upload rather than sent broken, and Adsonomy names the product and the field that blocked it. Two of the nine catch BigCommerce stores in particular: brand, which the platform requires and BigCommerce treats as optional, and description, which plenty of stores leave to the theme.

The url has to be a public HTTPS product page, which is the second reason the storefront URL field matters at connection time. The image has to be a public URL; Adsonomy takes the variant image when there is one and the product thumbnail otherwise. Price has to be positive and carry an ISO currency code, and a sale price that is not lower than the regular price is dropped rather than sent. Titles should stay within 150 characters, which a long product name plus three option labels passes faster than you would expect.

When the store cannot be changed quickly, the fix does not have to happen in BigCommerce. Brand, image URL, price, currency, title, description, category, GTIN and MPN can be corrected per product inside Adsonomy. The correction wins over what the store sends and stays until someone removes it, while the store keeps syncing underneath, so the two can still be compared and the next sync does not quietly drop the row again. What the file contains in general, and how it compares with the Google Merchant Center feed you probably already maintain, is in [the product feed guide](https://adsonomy.com/guides/openai-product-feed-vs-google-merchant-center).

### Conversions are counted once because the order id is the event id

Two layers report the same order. Adsonomy polls Orders v2 every 30 minutes and sends one order_created event per new order through the Conversions API, using the BigCommerce order id as the event id. The browser layer is two Script Manager scripts that Adsonomy generates with your pixel id and you paste: one in the head on all pages, one on the order confirmation page firing order_created with that same order id. The platform deduplicates on the id, so the order counts once.

The server event carries the order total including tax, the currency, the line items, and customer identifiers hashed with SHA-256 at sync time so the raw values are never stored. Line items need one extra call per order, paged at 50, the documented maximum for orders and line items alike and not the catalogue's 250. An order already older than seven days is stored but never sent, because the platform refuses events older than that. Refunded, Cancelled and Declined orders, status 4, 5 and 6, are skipped by the relay; Partially Refunded, status 14, is deliberately not treated as a cancellation, because part of that order stands and so does part of the revenue.

One BigCommerce specific is worth knowing: the order payload carries no click reference, so the server event cannot carry one either. The browser script is what records the visit, which is a practical reason to install both layers rather than rely on the relay alone. Once both are in, the Check installation action reads the most recent sample events on the pixel and shows which arrived from the browser and which server to server.

In reporting, conversions need at least a day to appear, so daily decisions are made on yesterday's orders. The click window is set on the conversion event rather than on the report, and insights requests take no window parameter at all; Adsonomy creates the event setting with a 30 day click window, the only window value OpenAI's documentation states. [The conversion tracking guide](https://adsonomy.com/guides/openai-ads-conversion-tracking-pixel-and-conversions-api) covers the pixel and the Conversions API in detail.

### Three things are manual or not built for BigCommerce today

The two Script Manager scripts are generated for you but pasted by you: Adsonomy does not write to Script Manager. There is no inbound webhook anywhere in the product, so orders are polled rather than pushed. And there is no BigCommerce OAuth app, so connecting a store is the API account described above. Everything else in this guide, the catalogue read, the feed build and the order relay, runs on its own once the store is connected.

Polling is not dressed up here as a feature: orders are read every 30 minutes with a 48 hour overlap, and never sent twice because they are keyed on the store's order id. Webhooks are planned work rather than a switch waiting to be flipped, since BigCommerce deactivates a subscription after 48 hours of failures or 90 days without events, and its payload carries only a type and an id with no HMAC signature, so the entity has to be re-fetched rather than trusted and a reconciliation sweep belongs with that work.

Adsonomy gives you both Script Manager blocks with the pixel id filled in, the placement settings named, and the content security policy line to allow if your storefront enforces one. No code of your own is involved, but nobody else can paste it for you.

### A first campaign is one product set, one ad group and one product ad

Start with a product feed campaign whose ad group points at a product set narrow enough to mean something, one product ad template, and order_created as the conversion event. Everything the platform creates arrives paused, so nothing spends until you activate it, and the moment to activate is after the first feed upload has completed and the pixel has reported its first events.

Product sets filter on the feed's own fields: brand, product_category, item_id, offer_id, title, price, and the custom labels under `ads_metadata` when you turn those on, in which case margin tier goes out as custom_label_0 and lifecycle stage as custom_label_1. Category matching is exact, so a category filter does not pick up everything below it and the set has to list the paths you mean. A sound first set is one category or one brand, in stock, with a margin you are happy to buy traffic against.

Take a conversions objective with your order_created event setting and impression billing, which OpenAI made generally available on 16 September 2026 and describes as its recommended model for conversion campaigns. Budget is where a shop gets caught out, because the daily budget is an average: Ads Manager states a maximum daily spend of twice the budget and a maximum seven-day spend of seven times it, so plan a week rather than a day. On a EUR account the platform refuses a daily campaign budget below 15.00 EUR. [The budgets and pacing guide](https://adsonomy.com/guides/budgets-pacing-and-bidding-strategies-for-chatgpt-ads) covers the trade-offs.

The ad group takes up to 2,000 context hints, free text describing the intent you want to appear in rather than keywords to bid on; [the context hints guide](https://adsonomy.com/guides/contextual-targeting-and-context-hints-in-chatgpt-ads) explains how to write them. The product ad template takes its image, destination URL and price from the feed row and can print the current price, so a promotion in BigCommerce shows in the ad after the next delta without touching the creative. Targeting the EEA or Switzerland means planning without custom audiences, which are not available there. For the build step by step, read [launch your first ChatGPT ads campaign](https://adsonomy.com/guides/launch-your-first-chatgpt-ads-campaign), and [the guardrails guide](https://adsonomy.com/guides/autopilot-guardrails-and-accountability) for what Nomy, the AI manager, may change on its own once the campaign runs and what always waits for a person.

## Frequently asked questions

Q: Do I need a BigCommerce app or a developer to connect a store?
A: No. Reading a BigCommerce store runs on a store-level API account with read-only Products and Orders scopes, which is the documented route and is still open, so you create the account in the control panel and paste the store hash and the access token into Adsonomy. There is no app to install and no review to wait for. The one manual step is pasting two Script Manager scripts into the storefront, which needs no code of your own.

Q: Why does my BigCommerce catalogue show zero prices in other tools?
A: Because every money field on a BigCommerce variant is nullable and null means inherit from the parent product, not zero. A tool that casts null to a number gets 0.00 and prices every inheriting variant at nothing, with no error anywhere. The price a shopper pays is `calculated_price`, which is never null and already carries the sale price, the price list and any adjustment rule. Adsonomy resolves null as inherit and takes `calculated_price` as the effective price.

Q: Does Adsonomy use BigCommerce webhooks?
A: No. There is no inbound webhook in the product today. Orders are polled every 30 minutes with a 48 hour overlap so late arrivals are not missed, and the catalogue is read every six hours. Webhooks are planned rather than built: BigCommerce deactivates a subscription after 48 hours of failures or 90 days without events, and its payload carries only a type and an id with no HMAC signature, so the entity has to be re-fetched rather than trusted.

Q: Which products from a BigCommerce store can actually be advertised?
A: Visible products with a title, a description, a public HTTPS product page, a brand, an image, an availability and a positive price in a real currency, plus the seller name set on the feed. Those are the required columns of the product file, and a row missing one is left out of the upload with the product and the field named. Brand, image URL, title, description, price, currency, category, GTIN and MPN can be corrected inside Adsonomy when the store cannot be changed.