Developer / App security

App IP allowlists now support
IP addresses + ASNs together
Limit raised from 100 to 250

In the Dev Dashboard IP allowlist, you can now add static IPs and ASNs (Autonomous System Numbers) to the same list. This makes setup easier for apps that use both static and dynamic IPs. IP allowlists are expected to become required for all public and custom apps soon.

On this page
  1. What's changing (30-second overview)
  2. How it works: how requests are allowed or blocked
  3. Limit changes
  4. Before vs. after
  5. IP or ASN: which should you use?
  6. How to set it up (3 steps)
  7. 5 key points for developers
  8. 3 practical use cases
  9. One-line summary for proposals

1What's changing

Previously, the IP allowlist in your app settings made you choose either "IP addresses" or "Networks (ASN)"— not both.
Now you can add both to the same allowlist. The limit for IP addresses/ranges has also increased from 100 to 250.
IP ASN

Before: one or the other

You chose whether to restrict by IP address or by network (ASN). IP addresses/ranges were limited to 100.

IP ASN

After: use both together

You can add IP addresses/CIDR ranges (up to 250) and ASNs (up to 10) at the same time. You can also add just one type.

2How it works: how requests are allowed or blocked

Your server Static IP Serverless Dynamic IP API request App IP allowlist IP addresses / CIDR ranges: up to 250 Networks (ASN): up to 10 └ Limit ASNs to countries: up to 10 countries Matches any Matches none Allowed Reaches the Shopify API Fails with 403 Not on the allowlist
Matching uses "OR" : among your registered IPs and ASNs, a match on any one is allowed. If none match, the request fails with a 403 status code.
Country limits apply only to ASNs. Country limits don't apply to IP addresses.

3Limit changes

IP addresses / ranges
250
Previously 100 → 2.5×

Add them in the "IP addresses or CIDR ranges" field

ASN
10
Previous limit: not specified

Add them in the "Networks (ASN)" field

Limiting ASNs by country
10
countries can be selected

Set in "Limit ASNs to countries"

4Before vs. after

ItemBeforeAfter
Using IPs and ASNs together Only one or the other Can be combined Either alone also works
IP address / range limit 100 entries 250 entries
ASN limit Not specified 10 entries
Country restrictions Not specified Up to 10 countries.Applies to ASNs only
Requests from outside the allowlist Not specified 403 Fail with
Required? Optional Required soon Applies to all public and custom apps (timing not specified)

5IP or ASN: which should you use?

Specific IP addresses = most secure Hosting provider's network Your servers Other customers: blocked Only your servers can use the access token ASN = allow the entire network Hosting provider's entire network Your servers Other customers: allowed through Use only for dynamic IPs, and restrict by country
Recommended

Default to specific IP addresses

Allow by IP address whenever possible. This is considered the most secure approach, since only your servers can use the app's access token.

Use sparingly

ASNs only for dynamic IPs

Add ASNs only for requests whose IPs change, such as serverless functions. Then restrict them to the countries where your app runs.

Allowing an ASN allows every address on that network,including addresses used by the hosting provider's other customers.

6How to set it up (3 steps)

1

Open the settings page

In the Dev Dashboard, open your app's Settings page and go to the IP allowlist section.

2

Register IPs, ASNs, and countries

Enter static IPs in the IP/CIDR field. Register only dynamic sources in the ASN field, and restrict them by country.

3

Validate against recent traffic

Before turning on enforcement, validate your updated allowlist against recent traffic.

For detailed setup instructions, see the official documentation "Restrict API access with an IP allowlist" for details. This article does not specify how to verify it (which screen or logs to check).

75 key points for engineers

403

1. Requests outside the allowlist get a 403

API calls from unregistered sources fail with a 403. Set up your app's error handling and monitoring so that a spike in 403s is flagged as a sign of a missing allowlist entry.

OR

2. Matching is IP OR ASN

A request is allowed if it matches any one registered IP or ASN. Adding ASNs widens the allowed range (it does not narrow it with AND logic).

3. Country restrictions apply only to ASNs

"Limit ASNs to countries" restricts only requests that come through ASNs. Country restrictions don't apply to sources registered by IP address.

CIDR

4. You can register CIDR ranges

You can register CIDR ranges as well as single IPs, with each counting as one entry, up to 250 entries. Even multi-region setups with many static IPs can stay within the limit by grouping them into CIDR ranges.

5. Inventory your source IPs ahead of the requirement

IP allowlists will soon be required for all public and custom apps(no start date given). Shopify also strongly recommends using them for all apps. It's safest to identify the source of every path that calls the Shopify API (batch jobs, webhook handlers, admin backends, serverless functions, etc.) and move whatever you can to static IPs.

83 practical use cases

VM λ
USE CASE 1

Protect an app that mixes static servers and serverless with a single allowlist

Challenge
The main backend uses static IPs, but some processing runs on serverless functions whose source IPs change. Previously you had to choose either IPs or ASNs, so you couldn't cleanly allow both paths.
Approach
Register static-IP servers in the IP/CIDR field. Register only the serverless functions' sources in the ASN field, limited to the countries where they run.
Result
Most traffic stays protected by the most secure option, IP-based rules, while dynamic-IP paths keep working.
Technical notes
Note that adding ASNs widens the allowed range through OR matching. If your serverless setup can use a static source IP, IP-based rules are the safer choice.
Becoming required
USE CASE 2

Audit and update client custom apps before the requirement takes effect

Challenge
You run custom apps for multiple clients, and none of them has an IP allowlist configured. Once it becomes required, apps without one risk breaking.
Approach
For each app, identify the source of every path that calls the Shopify API → register static IPs in the IP field and dynamic IPs via ASN plus country restrictions → verify against recent traffic before enforcing.
Result
You won't be scrambling when the requirement lands, and you limit the damage if an access token leaks. You can also offer it as a security measure under your maintenance contracts.
Technical notes
No start date for the requirement is given. After enforcement, calls from outside the allowlist fail with a 403, so watch especially for missing entries on infrequent paths such as cron jobs and batch jobs.
250
USE CASE 3

Stick with IP-based rules instead of ASNs for a multi-region public app

Challenge
A public app with servers in multiple regions had more than 100 static IPs, which didn't fit under IP-based rules, so it had to use ASNs instead.
Approach
With the limit raised to 250 entries, switch to IP addresses and CIDR ranges. Keep ASNs only for paths that are unavoidably dynamic.
Result
Stop relying on ASN entries that also admit your hosting provider's other customers, and restrict the sources that can use your access tokens to your own servers.
Technical notes
Before switching over, validate the new allowlist against recent traffic. Combining contiguous addresses into CIDR blocks saves entries.

9One-line summary for proposals

"App IP allowlists can now include both fixed IPs (up to 250) and ASNs (up to 10) together.
Use IP entries by default, and ASN plus country restrictions only for routes with dynamic IPs.
Inventory and validate your traffic sources before this becomes mandatory for all apps soon."