A couple of weeks ago I wrote about Shopify's new IP allowlist, which lets you tie an app's Admin API token to your own servers. At the time it was optional, and I said it was worth switching on. It's now compulsory for a lot more apps than I expected, including custom apps, and the first deadline is this Friday, 20 November.
If you have a custom app that a developer or agency built for your store, or you're the one who built custom apps for other people's stores, this one is for you.
What changed
On 11 November Shopify posted a changelog entry headed IP allowlists are now required for custom apps installed outside your organization. Up to now the requirement had been about public App Store apps. This extends it to custom apps installed on stores outside the organisation that owns the app.
There are two dates, both at 11:59pm US Eastern time:
- 20 November 2026: an app needs an IP allowlist before it can be newly installed on a store outside your organisation.
- 1 January 2027: allowlists are required for existing installs too.
Apps installed only on stores within your own organisation aren't affected, and nor are apps created by merchants themselves in the Dev Dashboard or the Shopify admin. Shopify's docs still "highly recommend" an allowlist for those, and I'd agree.
The bit that catches people out
Shopify's 14 November update has a line every developer with more than one custom app should read twice. From 1 January, it says, "one app without an allowlist blocks you from installing any of your apps" on stores outside your organisation.
So it isn't just about the app you're working on this week. If there's an old app sat in your account with no allowlist, perhaps one you built for a client years ago and forgot about, it can stop you installing something new for someone else. A tidy-up of every app in the account is worth doing before Christmas, not after.
The same post says multi-factor authentication is becoming compulsory on all Partner accounts, starting next week. Shopify recommends passkeys. If anyone in your team still logs in with just a password, sort that at the same time.
What an allowlist actually does
The short version, from Shopify's setup guide: you list the public addresses your servers use to call Shopify, and any GraphQL or REST Admin API request made with your app's tokens from anywhere else gets a 403. So does any request where Shopify can't confirm where it came from. Bulk queries and mutations are covered too.
The point is that a leaked token stops being much use on its own. Tokens end up in Git history, log files and old laptops. If you'd like the longer story on what to do when one does, I've written a guide on API keys in code: rotate first, tidy up after.
I covered the basics in more detail in the earlier post, so I won't repeat it all. But two things have changed since then.
Serverless apps can now take part
Last time, the big catch was that most serverless platforms weren't supported, because they hand out a different address on each run. Shopify has fixed that by letting you allowlist by network as well as by address.
You can now add up to 250 IP addresses or ranges (up from 100), plus up to 10 ASNs. An ASN is the number that identifies a provider's whole network. You can also limit those ASNs to up to 10 countries.
Shopify is fairly clear about the trade-off, and it's worth taking seriously. It calls static IPs "the most secure option" and says to add ASNs only for traffic from dynamic addresses, such as serverless functions. A cloud provider's network is shared with all its other customers, so allowing an ASN means anyone holding your token on that provider's network gets through. Narrow it by country, and if you can move the calls to a fixed address, do.
On AWS, for example, that usually means sending outbound traffic through a NAT gateway with an Elastic IP and listing that one address. It's a bit more plumbing, but it turns "anyone on this cloud" into "my servers".
Things that will break
The docs list a few cases the allowlist doesn't work with, and Shopify rejects them once enforcement is on:
- Shopify Flow's Send HTTP request action using your app's token.
- GraphQL Admin API calls from a storefront hosted on Oxygen.
Dev preview requests on dev stores, and direct API access from embedded app pages and POS UI extensions, are never rejected. If your setup leans on Flow or Oxygen for Admin API calls, plan that before you switch anything on.
How I'd do it this week
- List every app in your account, not just the live ones, and note which are installed on stores outside your organisation.
- For each, find everything that calls the Admin API with its token: web servers, queue workers, cron jobs, staging boxes, and that integration nobody has touched since 2022.
- Get their public outbound addresses. Behind a NAT gateway or load balancer, it's the gateway's address that counts.
- In the Dev Dashboard, open the app, go to Settings, then IP allowlist, and add the addresses. Only reach for ASNs where you genuinely have no fixed address.
- Press Run test. It checks your list against the app's own traffic from the last 30 days and tells you what would have been blocked.
- Turn on enforcement, save, then send a request from somewhere off the list and check you get a 403.
If it goes wrong, you can turn enforcement off again and Shopify keeps your list. It's not a one-way door. I'd still rather do it on a quiet Tuesday than in the middle of Black Friday week, which is uncomfortably close to the 20 November date.
If you're not sure where your app even runs
That's more common than it sounds, especially when the developer who built it has moved on. If that's you, we can help. We build and look after custom Shopify apps and integrations, and our code audit (£250 + VAT) will tell you what the app does, where it runs and what it talks to. If you'd rather someone just kept on top of changes like this, Look after it starts from £355 a month + VAT.
Either way, drop us a line before Friday if you think one of your apps is affected.
Cheers, Rob
