That last bit is the important part. Right now, for most apps, an Admin API token works from anywhere in the world. Whoever holds it is your app, as far as Shopify is concerned. The new IP allowlist changes that.

What Shopify actually released

On 27 October Shopify published a security update for app developers with a handful of new features. The one I'd look at first is the IP allowlist, which lives in your app's settings in the Dev Dashboard.

The idea is simple. You list the public IP addresses (or CIDR ranges) your servers use to call Shopify. Turn on enforcement, and Shopify checks the source of every GraphQL Admin API and REST Admin API request made with your app's tokens. Anything from outside your list gets a 403. According to Shopify's setup guide, so does any request where Shopify can't confirm where it came from.

A few practical details from the docs:

  • You can add up to 100 addresses or ranges, one per line.
  • IPv4 ranges must be /16 or narrower, and IPv6 ranges /32 or narrower.
  • Public addresses only. If your servers sit behind a NAT gateway, you list the gateway's addresses.
  • If your servers reach Shopify over IPv6, those addresses need to be on the list too.

Why this matters more than it sounds

Tokens leak. They end up in a Git repo, a log file, a support ticket, an old laptop or a supplier's shared drive. We wrote about this only yesterday: deleting a leaked key isn't the same as revoking it. Until you rotate it, it still works.

An allowlist doesn't stop a token leaking. What it does is make a leaked token far less useful. Someone who grabs it can't just call your store's Admin API from their own machine, because their machine isn't on your list. It's the difference between losing your front door key and losing a key that only works if you're also standing inside the house.

Shopify's own docs suggest pairing it with expiring offline access tokens, so a leaked token is both short-lived and tied to your servers. That migration is already due. Public apps calling the Admin API need to move to expiring offline tokens by 1 January 2027, and Shopify is clear the later enforcement dates are a buffer for merchants, not extra time for developers. Custom apps and merchant-created apps aren't affected by that particular deadline.

Who can't use it yet

This is where you need to be honest about how your app is hosted. The allowlist only works if you call Shopify from static IP addresses. Shopify says most serverless platforms, which hand out a different address on each run, aren't supported yet. Support is "coming soon", but there's no date.

There are a couple of other catches in the docs worth knowing about before you flip the switch:

  • Requests from Shopify Flow's "Send HTTP request" action, using your app's token, will be rejected, because Shopify can't confirm their source.
  • Admin API requests from a storefront hosted on Oxygen get rejected for the same reason.

If any part of your setup relies on those, turning enforcement on will break it. Not the sort of thing you want to find out on a busy Saturday.

How to switch it on without locking yourself out

Shopify has built in a sensible safety net. Before you enforce anything, there's a Run test button that checks your list against the addresses your app has actually used in the last 30 days. If any of your own traffic would be blocked, it tells you.

The order I'd do it in:

  • Work out every place that calls the Admin API with your app's token. Your main server, obviously, but also background workers, cron jobs, staging boxes and that integration someone set up three years ago and nobody has touched since.
  • Find their public outbound addresses. If you're behind a load balancer or NAT gateway, it's the gateway address that counts.
  • Enter them, run the test, and fix anything it flags.
  • Turn on enforcement, then send a request from somewhere that isn't on the list and check you get a 403.

If something does go wrong, you can turn enforcement off again and Shopify keeps your list. So it isn't a one-way door. Still, I'd do it on a quiet morning rather than the week before Black Friday.

The other new setting: declaring your network access

The same update added a [network_access] section to the app's shopify.app.toml file. It has two parts. allowed_sources lists up to 20 HTTPS origins your app's code loads from or sends requests to on storefront, checkout and admin pages. Shopify uses that to spot requests your app didn't make. allowed_navigation_hosts lists up to 20 external sites you link customers to, so those links skip the warning Shopify normally shows when a customer leaves the store.

Shopify doesn't require it, but it strongly recommends it. It's a short config change followed by a fresh app deploy, and it means writing down which outside servers your app actually talks to. That's a list every app owner should have anyway.

What I'd do this week

If you have a Shopify app on a fixed server, set up the allowlist. It costs very little and takes a whole class of "someone found our token" problems off the table. If you're on serverless, note it down and come back when Shopify adds support. And if you're not sure where your app runs, or what it talks to, that's worth finding out regardless of this update.

If you'd like a hand, this is the kind of job we do. We build and look after custom Shopify apps and integrations, and for firms without anyone technical in-house we can act as your tech department, keeping on top of changes like this so you don't have to. Drop us a line and we'll take a look.

Cheers, Rob