On 22 October, BigCommerce announced a fix for a permissions gap in the Checkouts API. A token carrying only the Checkouts read-only scope could be used to modify checkout data. Write requests now require the Checkouts modify scope, and read-only tokens will start returning a 403 over the coming weeks as the fix reaches each store.

This is a good change. A read-only credential that can create orders is not read-only in any meaningful sense, and anyone who has ever handed an integration partner a token they described as safe has an interest in that word meaning something. The platform is tightening, which is what you want from the system holding your payment flow.

It is also a useful prompt. Most merchants we work with have somewhere between four and twenty active API accounts, created over several years by several different people, and almost nobody has a current inventory of what each one is allowed to do. BigCommerce API scopes are the quietest part of a store's security posture precisely because they are set once at creation and then never looked at again.

So this post is two things. The first is a precise account of what changed and who it touches. The second is the audit we would run on any store we inherited, which you should run whether or not you write to checkouts. The rollout has handed you a reason to finally do it.

What changed on 22 October

The specifics are narrow, and saying so plainly up front should stop anyone hunting for problems that are not there.

Requests that create, update or delete checkout data must now be made with a token holding the Checkouts modify scope. Requests that only read checkout data are unaffected, and a read-only token will keep reading checkout data exactly as it does today. The enforcement is rolling out progressively rather than flipping on for every store at once, which means a store can pass today and start returning 403 next week.

That last detail is the one that catches people. A progressive rollout means the absence of errors this morning is not evidence that you are in the clear. It is evidence that your store has not been switched over yet.

The endpoints in scope are all of the write operations on a checkout. Adding or updating a billing address. Adding, updating or deleting a consignment. Adding or removing a coupon. Creating an order from a checkout. If your integration touches any of those, it is doing a write, and it needs the modify scope.

How BigCommerce API scopes actually work

Every permission area on a store-level API account comes in two forms: a modify scope and a read-only scope. They are separate values, and the read-only one is not a weaker version of the other so much as a different grant entirely. A read-only scope limits the account to GET and HEAD requests. Nothing else gets through.

The ones relevant here, by their parameter names:

Area	Modify scope	Read-only scope
Checkouts	store_checkout	store_checkout_read_only
Checkout content	store_content_checkout	store_content_checkout_read_only
Carts	store_cart	store_cart_read_only
Orders	store_v2_orders	store_v2_orders_read_only
Content	store_v2_content	store_v2_content_read_only

Note that Checkouts and Checkout content are different areas. The first governs the checkout object itself through the Checkout API. The second governs scripts and content rendered on checkout pages. An integration can hold one and not the other, and the change announced on 22 October applies to the first.

Worth knowing too: carts and checkouts are distinct resources with distinct scopes. An integration that builds a cart and then hands the shopper off is not necessarily writing to a checkout, and may be entirely unaffected. One that manipulates consignments or applies a coupon at the checkout stage is.

The part that makes this more than a configuration change

Here is the detail that turns a two-minute fix into a planned piece of work: a store-level API account cannot have its OAuth scopes changed after it is created.

There is no screen where you tick an extra box. The scopes are fixed at creation, and BigCommerce's own documentation is direct about it, which is why it also tells you to choose them carefully at the time. If an existing account needs the Checkouts modify scope and does not have it, the remedy is to create a new account with the right scopes and move the integration onto it.

That is a credential rotation, not a settings change. It touches whatever stores that token, which might be a middleware platform, a subscription service, a marketplace connector, an ERP, or a config file in a repository that one developer has access to. It needs a window, and on a store doing real volume it needs a plan.

None of that is difficult. It is simply larger than it looks from the changelog entry, and it is the reason to start now rather than when the 403s arrive.

Which integrations are most likely exposed

In our experience the write path to a checkout shows up in a predictable set of places. Run down this list before you run down your token inventory, because it will tell you where to look first.

Headless and custom storefronts. Anything built on Catalyst, a bespoke front end, or a native app that assembles the checkout server side rather than handing the shopper to the hosted page. These are the most likely to hold a checkout write path and the most likely to break visibly.

Custom shipping and fulfilment logic. Consignment writes are how you split an order across locations, apply a carrier rule the platform does not model natively, or reassign a shipment. Any integration doing multi-origin fulfilment is writing consignments.

Quote to order flows. B2B implementations that convert an approved quote into an order often create the order from a checkout. That is a write, and quote conversion failing quietly is an expensive thing to discover late.

Promotions and loyalty tooling. Anything applying a coupon or a discount programmatically at the checkout stage rather than through the promotions engine.

Middleware and iPaaS connectors. The hardest category, because the token often lives in a third party platform and was configured by someone who is no longer on the project. If you cannot see the scopes from your side, you still own the outcome.

Subscription and recurring billing services. Rebilling that constructs a checkout server side to create each renewal order is doing exactly the operation this change governs.

Three questions settle each case.

How to audit your BigCommerce API scopes

Start with the inventory, because you cannot audit what you have not listed. Store-level accounts live under Settings, then Store-level API Tokens. Account-level accounts are under Settings, then Account-level API Tokens. Pull both lists and write down every account, what it is named, and what you believe it is for.

That last column is where the real findings are. On most stores we audit, at least one account has a name like "test" or "temp integration" and nobody present can say what uses it. An account nobody can account for is a finding on its own, independent of this change.

Then, for each account that your list suggests touches checkout, confirm the scope empirically rather than from memory. The reliable test is a single low-risk write against a checkout in a sandbox or test store using that token: create a checkout, then POST a consignment to it. A 200 or 201 tells you the modify scope is present. A 403 tells you it is not, and tells you before your shoppers do.

Do this in a sandbox, not production. The point of the exercise is to learn something without writing to a live checkout, and a store with a test context is the right place to spend the five minutes.

Where an integration is run by a third party and you cannot test it yourself, the question to send them is specific enough to get a specific answer: does the API account you use on our store hold the store_checkout scope, and if not, when are you rotating it? Vague questions about readiness get vague answers. This one does not.

Rotating a token without losing webhooks

If an account needs replacing, the order of operations matters more than the work itself. Deleting a store-level API account is permanent, it cannot be undone, and it takes two things with it that people forget.

The first is webhooks. Webhooks are owned by the API account that created them, not by the store. Delete the account and its webhook subscriptions go with it. If that account was the one receiving order created events, those events stop arriving, and they stop arriving silently.

The second is metafields. Metafields created under an account are preserved when it is deleted, but they become inaccessible, which is worse than losing them outright. BigCommerce's guidance is to deal with the metafields before deleting the account rather than after, because after is too late.

So the sequence runs in the opposite order to the instinctive one. Create first, delete last, and keep both accounts live in the middle while you confirm the new one works.

A few notes on the steps. At step two, resist the temptation to copy the old account's scopes verbatim and add Checkouts to them. The old scope set was chosen by someone solving a different problem, possibly years ago, and the rotation is a free opportunity to narrow it. Grant what the integration demonstrably uses.

At step five, prove the write rather than assuming it. One successful consignment POST on a sandbox checkout is the whole test, and it takes a minute. The alternative is discovering the scope was wrong during the rollout, at which point you are debugging under time pressure with a second rotation ahead of you.

Least privilege is the actual lesson

The Checkouts change will be a non-event for most stores. Worth sitting with, though, is why it was possible to be wrong about this in the first place.

Most stores accumulate API accounts the way a garage accumulates extension cords. Someone needs an integration working by Friday, creates an account, ticks the scopes that look relevant plus a few more for safety, and ships. The scopes are immutable, so the over-granted token stays over-granted for as long as the integration lives. Nobody revisits it, because nothing ever forces the question.

Two habits fix this permanently, and neither is expensive.

One account per integration. Shared tokens are what make rotation frightening, because you cannot change one consumer without touching all of them. Separate accounts turn a rotation into a contained change, and they also mean a leaked credential has a blast radius you can describe in one sentence.

Grant on evidence, not on anticipation. The instinct to add scopes in case they are needed later is understandable and it is the thing that makes tokens dangerous. Scopes cannot be edited, but accounts can be replaced, so the cost of starting narrow is one rotation at the point you actually need more. That is a much smaller cost than carrying a token that can create orders because someone once thought it might need to.

A store with one account per integration and honest scope lists absorbs a change like this one in an afternoon. A store with four shared tokens and no inventory spends a week finding out what it owns. The difference is not technical sophistication, it is whether anyone has written it down.

If you have not looked at your BigCommerce API scopes since the integrations were built, this rollout is as good a reason as you will get. The inventory alone usually pays for itself, and the stores that come through platform changes calmly are generally the ones that already knew what their tokens could do.

Sources

• BigCommerce developer changelog, 22 October 2026: Checkouts API write requests now require the modify scope.
• BigCommerce developer documentation: API accounts and OAuth scopes, including the store_checkout and store_checkout_read_only values and the GET/HEAD limitation on read-only scopes.
• BigCommerce support documentation: Store API Accounts, covering the control panel locations, the fact that existing accounts cannot have their OAuth scopes updated, and the effect of deleting an account on its webhooks and metafields.
• BigCommerce developer documentation: Checkout management API endpoint reference, for the set of write operations on a checkout.