Shopify App IP Allowlist: November 2026 Guide

Shopify announced on 5 November 2026 that IP allowlists are now required for public apps that call the GraphQL Admin API or REST Admin API. The first enforcement date is close: from 12 November, bulk queries and mutations can be blocked when an app has no allowlist. From 20 November, the app can be delisted, blocked from new installs and flagged to merchants in Shopify admin.

This is not only a developer compliance task. Public apps often sit inside product syncs, fulfilment, inventory, reporting, loyalty, CRM, ERP and customer-service workflows. A rushed network rule can interrupt those processes; doing nothing can create a visible supplier-risk warning and later API failure.

The practical response is to identify the app, map every place it sends Shopify API traffic from, choose the narrowest workable rule, test recent traffic, enable enforcement, and verify real business journeys. Merchants should also check whether their critical vendors are ready rather than assuming every installed app will meet the deadline.

Know the enforcement sequence

Existing installs do not all stop on 20 November, but that is not a reason to defer. The earlier bulk-operation block can already damage live workflows, and the merchant-facing flag creates an immediate commercial signal. Treat 20 November as a production-readiness deadline, not a paperwork date.

Separate merchant actions from app-owner actions

App owners and implementation partners control the Dev Dashboard setting, hosting architecture, outbound addresses, release process and API verification. They need to prove the allowlist covers production traffic without opening an unnecessarily broad network range.

Merchants normally cannot configure a third-party public app's allowlist. They can still inventory critical apps, review Shopify's app-security indicators, ask vendors for a remediation date, identify which workflows use bulk operations and plan a continuity option.

Internal custom-app teams are outside the mandatory public-app rule, but the same control may be worthwhile. Shopify strongly recommends allowlisting custom apps because a stolen Admin API token is otherwise usable from any network until another control stops it.

Write down who owns each decision. A merchant waiting for a vendor and a vendor waiting for a hosting provider can both believe somebody else is handling the deadline.

Use an eight-stage path from traffic inventory to monitored enforcement

A safe rollout starts with evidence, not guesses. Map where the app really calls Shopify from, classify static and dynamic egress, account for jobs and failover paths, test Shopify's view of recent traffic, enable the smallest rule set and verify business outcomes.

The goal is not merely to make the dashboard show compliant. It is to constrain stolen-token use while keeping legitimate API traffic observable and supportable.

4. Use ASN rules carefully for serverless hosting

Dynamic outbound addresses are common on serverless platforms. Shopify supports allowlisting a provider network by autonomous system number, with optional country restrictions. The trade-off is wider trust: other customers share that network, so a stolen token used from the same allowed ASN may pass the network check.

Prefer dedicated egress, NAT or a proxy with stable addresses when the platform and budget support it. If ASN rules are necessary, allow only the required networks and countries, document why they are needed and schedule a later architecture review.

5. Test the previous 30 days of traffic

Use Test against recent traffic in the Dev Dashboard before enforcement. Shopify checks whether any API source observed during the previous 30 days would be blocked. Investigate every unexpected address instead of blindly adding it; it could be an old environment, a forgotten job or suspicious activity.

6. Enable enforcement and prove the boundary

Save the rule, turn on enforcement and verify both sides: legitimate production requests succeed, while a controlled request from outside the allowlist fails with HTTP 403. Store the test result, rule owner, change date and rollback conditions with the release record.

Check Shopify's compatibility boundaries before enforcing

Shopify documents two important patterns that do not work with the allowlist because it cannot confirm their source address: access tokens used by Shopify Flow's Send HTTP request action and Admin API requests made directly from an Oxygen-hosted storefront.

Do not solve those cases by widening the rule. Move the Admin API call behind a controlled app backend, redesign the token flow, or use a supported direct-access pattern. Shopify also documents request types that are never rejected by the allowlist, including development-preview requests on dev stores and direct API access from embedded app pages or POS UI extensions.

This boundary is why a route-level inventory matters. An application can appear to work during an interactive admin test while a background or storefront-origin request fails later.

Do not treat allowlisting as complete app security

An IP rule limits where a token can be used; it does not reduce what the token can access, detect every leak or repair an insecure endpoint. Pair it with the rest of Shopify's current security model:

• migrate public apps to expiring offline access tokens before the separate 1 January 2027 deadline;
• request only the Admin API scopes the app uses;
• keep client secrets and private keys out of source code, browser bundles and logs;
• rotate credentials regularly and immediately after suspected exposure;
• authenticate webhooks, app proxies and interactive requests;
• scope stored records to the authenticated shop;
• run Shopify app security checks on every release and scan separate backends or internal tools;
• review API logs and maintain an incident-response owner.

Shopify's expiring offline tokens last one hour, while allowlisting constrains the networks from which that token works. These controls reduce different parts of the same credential risk and are stronger together.

A practical seven-day response plan

Day 1: inventory and assign

Confirm public-app status, business owner, technical owner, hosting owner, Admin API use and bulk-operation exposure. Merchants should list their critical third-party apps and contact vendors with unclear status.

Day 2: map network paths

Collect public egress evidence for every runtime, region, worker, scheduler and recovery path. Identify dynamic or unsupported origins before making a rule.

Day 3: design the narrowest rule

Prefer static addresses and constrained CIDR ranges. Where an ASN is unavoidable, document the shared-network risk and restrict countries.

Day 4: test recent traffic

Run Shopify's 30-day test, reconcile every observed source and investigate unknown addresses. Add only legitimate dependencies.

Day 5: enforce and verify

Enable enforcement in a controlled release. Test interactive, webhook, scheduled, bulk and failover journeys, then prove an outside request receives 403.

Day 6: monitor and communicate

Watch API errors and job outcomes, brief support teams and give merchants a concise confirmation of scope, test evidence and residual risks.

Day 7: close the next security gap

Schedule expiring-token migration, scope review, credential rotation and CI security checks. Add network-change review to the app's deployment and hosting processes.

Sources checked

• Shopify: App security updates — IP allowlist is now required
• Shopify Developer Documentation: Restrict API access with an IP allowlist
• Shopify Developer Documentation: About app security
• Shopify Developer Documentation: Use expiring offline access tokens
• Shopify Developer Documentation: Run app security checks in CI/CD
• Shopify Developer Documentation: Manage app credentials
• Australian Signals Directorate: Information Security Manual — web APIs

Sources were accessed on 10 November 2026. Shopify requirements and dates can change; verify current documentation and the Dev Dashboard before implementation.