Freezing your integrations before peak

Most peak readiness plans contain a code freeze, and most code freezes are written by the team that owns the repository. That team can stop its own deploys. It cannot stop the ERP vendor shipping a quarterly release on 12 November, the 3PL migrating a warehouse onto a new WMS instance, the tax provider changing a response format, the payment gateway deprecating an endpoint, or the app in your admin auto-updating because that is what apps do.

Every one of those is a change to an interface your storefront depends on, and none of them appears in your change log. The list of incidents that actually take out peak trading is dominated by them, which is why "we have a freeze" and "our integrations are stable in November" are not the same statement.

So the useful reframing is this: you are not freezing your code. You are freezing the contract between systems — what is sent, in what shape, to which endpoint, with which credentials, on what schedule — and that contract has counterparties who need to agree to the freeze for it to mean anything.

The platform does not freeze for your trading calendar, and its calendar is public, so there is no excuse for being surprised.

Shopify releases a new API version on the first day of each quarter, which puts one on 1 October — inside most retail freeze windows. That is not a reason for alarm, because Shopify also documents that each stable version remains accessible for a minimum of 12 months with at least nine months of overlap between consecutive versions. Translated into a decision: no API version migration is ever urgent in November. If someone proposes one, the answer is January.

The behaviour worth understanding is what happens when a version does become inaccessible. Shopify documents that the request does not fail — it falls forward and is answered by the oldest accessible stable version. Your integration keeps working and starts receiving subtly different responses, which is a far worse failure than an error because nothing anywhere goes red. Pin the version explicitly on every request, and assert on the X-Shopify-Api-Version response header in whatever monitoring you already have.

The freeze should be specific enough that anyone can tell whether a proposed change is inside it. Two lists, both short.

Frozen: field mappings and data transformations; webhook topics and endpoint URLs; authentication credentials, API keys and certificates; the set of scheduled jobs and their cadence; API version pins; queue and retry semantics; any new integration, however small; and the promotion path from staging to production.

Deliberately not frozen: backoff and retry timing; queue concurrency; rate limiting; alert thresholds; and the switch that puts an integration into degraded or manual mode. These are the controls you will need at 2am, and a freeze that includes them is a freeze that gets suspended during the exact incident it existed to prevent.

That distinction matters most around rate limits, because peak is when your integrations compete with each other. Shopify documents the GraphQL Admin API as restoring 100 cost points per second on Standard, 200 on Advanced, 1,000 on Plus and 2,000 on Enterprise, with any single query capped at 1,000 points regardless of plan. A catalogue sync, an order export and a stock update all drawing on the same bucket is a solvable scheduling problem in October and an outage in November — so the schedule is frozen, and the ability to turn one of them down is not.

If you read one specification before peak, make it the webhook delivery rules, because they punish slowness rather than failure and that is not what most teams have designed for.

Shopify documents a one-second connection timeout and a five-second response timeout, treats any response outside the 200 range as a failure, and retries 8 times over 4 hours. If a subscription created through the Admin API fails consistently, it is removed, with warning emails sent to the app's emergency developer email address.

Read that as an operational requirement rather than a technical note. An endpoint that does real work inline — writes to your ERP, calls a third party, waits on a lock — is fine at ordinary volume and starts exceeding five seconds under peak load. Once it does, Shopify is retrying, and if it keeps timing out you can end up with no subscription at all: orders stop arriving and nothing in your storefront looks wrong. The design that survives is the boring one — acknowledge with a 200 immediately, queue the payload, process asynchronously — and the pre-peak check is to confirm that every endpoint does that, that someone still reads the emergency developer email address, and that you monitor for a subscription that has quietly stopped existing.

Start around four weeks before your peak begins. The reason is not superstition: integration faults surface under load rather than at deploy time, so a change made a week before peak has had no traffic against it that resembles peak traffic. Four weeks buys you at least one realistic volume test with the final configuration in place.

Lift it when returns and exchanges have settled, not on the Tuesday after Cyber Monday. January returns run through the same interfaces — refunds to your ERP, restocks to your WMS, credits to your accounting system — and the returns path is usually the least-rehearsed part of the stack, because everybody load-tests the buying and nobody load-tests the giving back.

One last thing worth saying plainly: a freeze is not a substitute for the work. Freezing a fragile integration preserves it exactly as it is, which is the point in November and an excuse by March. The list of things you dared not touch this peak is the roadmap for the first quarter — and the honest version of peak readiness is that most of it happens between January and September, not in the four weeks you spend not deploying.

• Shopify integrations
• The pre-peak code freeze, and what it should cover
• Webhooks, retries and the orders you never processed