Admin API / Security / Action required

Public apps now
must configure an "IP allowlist"

Restrict which networks can call the Admin API to limit the damage if a token leaks. The deadline is 2026/11/12 for apps that use bulk operations and 2026/11/20 for all other public apps. Missing it can lead to bulk operations being blocked and even removal from the App Store.

On this page
  1. What's changing (in 30 seconds)
  2. Two deadlines, and what happens if you miss them
  3. Which apps are affected / not affected
  4. Why it's needed: limiting the damage from token leaks
  5. How to set it up: static vs. dynamic IPs
  6. If you call the API from merchant-side infrastructure
  7. 5 key points for engineers
  8. 3 practical use cases
  9. One-line summary for proposals

1What's changing

To better protect merchants,IP allowlists are being added as a requirement for public apps.
Configure it in Dev Dashboard and define in advance which networks your app can call the Admin API from.

Before: callable from anywhere

With a token, the Admin API could be called from any network. If the token leaked, it could be abused from anywhere.

After: only allowed networks

Restrict callers by IP/CIDR, or by your hosting provider's ASN and country. This setting becomes mandatory for public apps.

2Two deadlines, and what happens if you miss them

11/5 Announced ! 2026/11/12 23:59 ET Apps that use bulk operations If not configured, bulk operations fail ! 2026/11/20 23:59 ET All other public apps If not configured, delisted from the App Store + no new installs
Deadline (US Eastern Time)Applies toWhat happens if not configured
2026/11/12 23:59 ET Apps using bulk operations Bulk operations from public apps without an IP allowlistwill fail
2026/11/20 23:59 ET All public apps from the Shopify App StoreDelisted,New installs blocked
In Japan time,the 11/12 deadline falls around 13:59 on Fri 11/13, and the 11/20 deadline around 13:59 on Sat 11/21(converted assuming US Eastern Standard Time, EST = UTC-5). The time from the announcement to the first deadline is only about one week .
After 11/20,the post doesn't say what happens to Admin API calls on stores that already have the app installed.

3Which apps are in scope and which aren't

In scope

All public apps

Public apps installed on multiple stores, such as those listed on the App Store. The deadline depends on whether the app uses bulk operations.

Out of scope

Custom apps

Custom apps are not subject to this requirement.

Out of scope

Merchant-built apps

Apps that merchants create in the Dev Dashboard or the Shopify admin are out of scope.

4Why it's needed: limiting the damage from leaked tokens

Without an allowlist Your server Attacker A Attacker B Admin API All allowed With an allowlist Your server Attacker A Attacker B Allowlist Admin API Allowed sources only × ×
What the post says: A leaked token can be used from any network. By using an IP allowlist to restrict the networks your app can call the Admin API from,you can reduce the damage if credentials are leaked.
It doesn't prevent leaks themselves. Think of it as one layer of defense in depth that limits the damage after a leak.

5Setup: it depends on whether your IPs are static or dynamic

Pattern A

Fixed source IP

If your calls to Shopify come from a fixed IP, build the allowlist withfixed IP addresses or CIDR ranges.

Example A NAT gateway's static IP, a dedicated server's IP, etc.

Pattern B

Dynamic source IP

If your source IP changes,allow your hosting provider's ASNand listthe countries where your app runs.

Example Serverless/PaaS environments where the source IP can't be fixed

Workflow

1

Identify your source IPs

Check whether every process that calls the Admin API (batch jobs, webhook handlers, workers, etc.) uses a fixed or dynamic source IP.

2

Configure in the Dev Dashboard

Register your app's allowed IPs: IPs/CIDRs if fixed, ASNs and countries if dynamic.

3

Verify before the deadline

Confirm that your key API calls, including bulk operations, still succeed (detailed verification steps aren't provided).

For detailed steps, the announcement points you to the official documentation "Restrict API access with an IP allowlist" . This article doesn't mention the maximum number of entries or how IPv6 is handled.

6If API calls come from merchant-side infrastructure

Situation

The app's Admin API calls are made not from the app developer's servers but frommerchant-side infrastructure.

Shopify's guidance

Move to an architecture that further limits Admin API token exposureas soon as possible. For the deadline above, you can alsorequest an extension.

Where to apply, the process, how long an extension may be granted, and the review criteria arenot stated. Extensions are only a temporary measure; moving to a setup that doesn't keep tokens on the merchant side is expected.

75 key points for developers

11/12

1. Your deadline differs by 8 days depending on whether you use bulk operations

Apps that use bulk operations must comply by Nov 12; after that, bulk operations fail. Bulk product and order syncs and exports will stop, soStart by finding where your codebase uses bulk operations.

2. The restriction applies to Admin API callers

The article explains that this restricts the networks from which an app can call the Admin API. It doesn't say whether other APIs, such as the Storefront API, are affected.

IP ASN

3. Dynamic IPs can be covered by ASN and country

Even if you can't provision a static IP, you can specify your hosting provider's ASN and the country where your app runs. However, specifying an ASN means thatthird parties using the same provider also fall within the allowed rangeso it's less restrictive than a static IP.

4. After 11/20, apps are delisted and new installs are blocked

New customer acquisition stops completely. The article doesn't say whether the API keeps working for stores that already have the app installed, so don't assume existing stores are safe.

5. Architectures that keep tokens on the merchant side need review

Architectures that call the Admin API from merchant infrastructure shouldmigrate as soon as possibleto a setup that limits where tokens are exposed. Extensions can be requested, but the article doesn't describe the process.Apps that integrate with on-premises or core business systems shouldstart redesigning now to be safe.

83 practical use cases for your business

!
USE CASE 1

Audit your client and in-house public apps to prevent bulk processing from stopping on 11/12

Challenge
Your own or your clients' public apps use bulk operations to sync products, inventory, and orders. After 11/12, bulk processing fails and data sync stops.
Action
① List all public apps you own → ② Check whether each uses bulk operations → ③ Register the apps that do in the Dev Dashboard allowlist first.
Impact
Prevents sync outages and data inconsistencies caused by missed deadlines. The different deadlines make priorities clear.
Technical note
The deadline is 23:59 US Eastern Time, which is early afternoon the next day in Japan. Account for the time difference and set it up ahead of time.
Static IP
USE CASE 2

Review the outbound IP design of apps running on serverless or PaaS platforms

Challenge
Your app runs in an environment with dynamic outbound IPs, so you can't register a static IP in the allowlist.
Action
Short term: register your hosting provider's ASN and country to meet the deadline. Medium to long term: consider routing outbound traffic through a static IP and switching to IP/CIDR entries.
Impact
You meet the deadline while ultimately narrowing the allowed range to limit damage if a token leaks.
Technical note
Note that specifying an ASN also allows others using the same provider. The article doesn't cover how to fix the outbound IP (e.g., a NAT setup), so check your infrastructure's specifications.
Core system App Server
USE CASE 3

Move merchant on-premises integration apps to an architecture that centralizes tokens

Challenge
The merchant's core business or warehouse systems call the Admin API directly, so tokens are stored in each merchant's environment.
Action plan
① If you can't meet the deadline, submit an extension request → ② Rebuild the setup so API calls are consolidated on the app developer's servers, with merchant systems routing through them → ③ Register the consolidated source IPs in the allowlist.
Impact
Tokens are exposed in fewer places, and the allowlist becomes easier to manage. This also aligns with Shopify's recommended direction.
Technical notes
The changelog doesn't say where to submit extension requests or how long an extension may be granted. Don't rely on an extension; finalize your migration plan and schedule first.

9One-line summary for proposals

"Public apps must now register the networks allowed to call the Admin API.
If this isn't configured in the Dev Dashboard by 11/12 for apps that use bulk operations, or by 11/20 for all other apps (US Eastern Time), bulk operations may be stopped or the app may be delisted from the App Store.
Start by inventorying your app's source IPs."