Developer Changelog / Security requirements

Custom apps installed on stores outside your organization
now require an "IP allowlist"

Applies to new installs from November 20, 2026, and to existing installs from January 1, 2027. Even if a token leaks, the Admin API can't be called from networks you haven't allowed.

On this page
  1. What's changing (30-second overview)
  2. Timeline: required in two phases
  3. Which apps are affected / not affected
  4. Why it's needed: limiting the damage from token leaks
  5. Allowlist configuration patterns (static IP / dynamic IP)
  6. How to comply (3 steps)
  7. 5 key points for developers
  8. 3 practical use cases for your business
  9. One-line summary for proposals

1What's changing

When you install a custom appon a store outside the organization that owns the app,
the app must have an IP allowlist configured. The goal is stronger merchant protection.

Before: callable from anywhere

With an access token, the Admin API could be called from any network. A leaked token could be used from anywhere, too.

After: only from allowed networks

The Admin API can only be called from IPs / CIDRs / ASNs and countries allowed in the Dev Dashboard. Even if a token leaks, the damage is contained.

2Timeline: required in two phases

2026/11/11 Announced Preparation period begins 1 2026/11/20 23:59 ET (US Eastern Time) Required for new installs New installs aren't possible without an allowlist 2 2027/1/1 23:59 ET (US Eastern Time) Required for existing installs too If even one is unconfigured, installs of all apps outside your organization are affected Full enforcement
Deadlines are in US Eastern Time (ET) basis. In Japan time, that's early afternoon the next day, so to leave a buffer in internal schedules, it's safest to finish by the day before. What exactly happens to existing installs after the deadline (for example, whether API access stops) isnot specified.

3Apps in scope / out of scope

In scope (allowlist required)

In scope

Custom apps installed on stores outside your organization

Custom apps installed on stores outside the organization that owns the app.

In scope !

Partners who own multiple apps

Starting January 1, 2027,if even one app has no allowlist configured, it affectsinstalls of every appon stores outside your organization.

Out of scope (this requirement doesn't apply)

Out of scope

Apps installed only on your own organization's stores

Apps installed only on stores within the owning organization.

Out of scope

Merchant-created apps

Apps that merchants create themselves in the Dev Dashboard or the Shopify admin.

Separate requirement

Public apps

Not covered by this change, butsubject to a separate requirement. The details aren't covered in this article.

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

Without an allowlist Your app Attacker A Attacker B Admin API Everything gets through With an allowlist Your app Attacker A Attacker B allowlist Admin API Allowed sources only
A leaked tokencan be used from any network. An IP allowlist limits the networks your app can call the Admin API from,A mechanism that minimizes the impact of leaked credentials.
It doesn't prevent tokens from leaking in the first place. Think of it as one layer of defense in depth that makes leaked tokens harder to abuse.

5Allowlist configuration patterns (static IP / dynamic IP)

203.0.113.10 /24 Pattern A

Fixed source IP (static IP)

If your app calls Shopify from a static IP address, configure the allowlist withstatic IPs or CIDR ranges.

Good fit: a VPC with a fixed egress IP via a NAT gateway, dedicated servers, etc.

ASN Pattern B

Changing source IP (dynamic IP)

If your egress (source) IP is dynamic, allowyour hosting provider's ASN , and also listthe countries where your app runs.

Good fit: serverless or PaaS environments where you can't pin the egress IP.

AspectA: Static IP / CIDRB: ASN + country
What you specify IP addresses or CIDR ranges Hosting provider's ASN + list of countries where the app runs
Granularity Fine-grained Only your own egress Coarser Per provider network
Prerequisite A fixed egress IP Knowing your provider's ASN
Where to configure Both use the "allowed IPs" setting in the Dev Dashboard
The "Granularity" row reflects that an ASN allowlist covers the provider's entire network. Limits on the number of entries, IPv6 handling, and whether this applies beyond the Admin API (e.g., Storefront API) arenot statedin this announcement. See the official guide "Restrict API access with an IP allowlist" for details.

6How to respond (3 steps)

1

Inventory out-of-organization installs

Identify the apps installed on stores outside your organization —all of them.

2

Check your egress IP setup

If static, use IPs/CIDRs; if dynamic, decide on ASNs plus the countries you operate in.

3

Configure in the Dev Dashboard

Set allowed IPs for each app.Cover every app by 2027/1/1and finish the rollout.

For apps you plan to newly install outside your organization on or after 11/20, configure this before installing. Existing installs have until 1/1, but since a single unconfigured app affects out-of-organization installs for all your apps, it's safest to handle them together and early.

75 key points for developers

Inside Outside

1. The deciding factor is whether the install target is inside or outside your organization

Even the same custom app is out of scope if it's only installed on stores within the owning organization. The main targets are agencies and partners who install apps on client stores.

2. One unconfigured app affects your whole organization

From 2027/1/1, if even one app has no allowlist configured, it will affectinstalls of any appon stores outside your organization. Manage this as a partner-level risk, not a per-app one.

3. Your egress IP design determines your configuration approach

Whether you restrict by static IPs/CIDRs or allow by ASN plus country depends on your infrastructure. Serverless setups require deciding between fixing egress (e.g., via NAT) and allowing by ASN.

Admin API

4. What's restricted is Admin API calls

The article describes it as "limiting the networks from which an app can call the Admin API." Whether it applies to other APIs, how it affects webhook delivery, and whether an API exists for configuring it arenot stated.

5. Updating the allowlist becomes an operational task during infrastructure changes

If your egress changes due to a hosting migration, an added region, or a NAT change, your calls will come from outside the allowlist.Adding "Update allowed IPs in the Dev Dashboard" to your infrastructure-change checklistis the practical approach (the article doesn't describe the specific error returned when calls are blocked, so verify it in a staging environment).

83 practical use cases

USE CASE 1

Full audit of client-specific custom apps at agencies and development studios

Challenge
Custom apps owned by your organization are installed on multiple client stores, but there's no list of which app is installed where. Missing even one affects all out-of-organization installs.
Approach
Inventory apps installed outside your organization → record each app's egress IP setup → configure allowlists in the Dev Dashboard → track completion by 1/1 with a checklist.
Impact
Avoid a halt on new installs caused by missing the deadline, and show clients that the security requirement has been addressed.
Technical note
Apps created by merchants themselves (via the Dev Dashboard or admin) are out of scope, so narrow the inventory by app owner.
NAT
USE CASE 2

Rethinking egress design for serverless apps

Challenge
For apps running on hosting with dynamic egress IPs, there's no settled approach to configuring the allowlist.
Approach
Start by allowing the hosting provider's ASN plus the countries you operate in to meet the deadline. To lock things down further, move to an architecture with fixed egress IPs and switch to static IP/CIDR entries.
Impact
Meet the deadline while strengthening security step by step.
Technical note
The country list must be updated when you add regions. Make changes to deployment regions the trigger for reviewing the allowlist.
USE CASE 3

Reflecting this in merchant-facing security explanations and proposals

Challenge
Merchants who have external partners install apps are worried about the risk of token leaks.
Approach
State Shopify's requirement that custom apps installed from outside the organization must have an IP allowlist in proposals and security sheets, alongside your own app's allowlist settings (IP/ASN and countries).
Impact
You can explain, as a platform requirement, that leaked tokens are harder to abuse from networks outside the allowlist.
Technical note
Also make clear that an allowlist limits the damage after a leak; it doesn't replace proper token management.

9One-line summary for proposals

"Custom apps installed on stores outside your organizationrequire an IP allowlist: new installs from 11/20, existing ones from 1/1..
A single unconfigured app affects out-of-organization installs of all your apps, sotake inventory → set IP/CIDR or ASN + country in the Dev Dashboard before the end of the year."