Shopify public apps now face firm network-security deadlines. An app that uses the Admin API may work normally today and then lose bulk operations, new installs, or eventually API access if its network allowlist is not configured correctly.
Shopify announced on November 5, 2026 that IP allowlists are required for public apps. Public apps using bulk operations must configure an allowlist by November 12 at 11:59 PM ET. Other public apps must do so by November 20 at 11:59 PM ET to avoid App Store delisting and blocked new installs. Shopify supports static IP addresses, CIDR ranges, and autonomous system numbers for serverless hosting.
What an IP allowlist changes
An allowlist limits where an app’s Shopify access tokens can be used. When enforcement is active, Shopify checks the source network of GraphQL Admin API and REST Admin API requests. Requests outside the approved addresses or networks fail with a 403 response.
This reduces the usefulness of a stolen token, but it does not make the token harmless. The app still needs secret storage, least-privilege scopes, token rotation, secure logs, and incident response.
Which apps are affected
The requirement applies to public apps. Custom apps and apps created by merchants in Shopify admin or the Dev Dashboard are not required to configure an allowlist at this time, although Shopify recommends the control.
Every public app should identify all production, staging, worker, webhook, migration, reporting, and support services that call Shopify. A forgotten background worker can become the first customer-visible failure after enforcement.
A practical ecommerce example
A small agency runs a Shopify app from a web service, scheduled worker, and serverless function. The team adds the web service’s static IP but overlooks the serverless function used for nightly inventory reconciliation.
Interactive app screens continue to work, while the nightly job receives 403 errors. Inventory data becomes stale and support staff initially blame the merchant’s store. A safer rollout inventories every outbound caller, tests recent traffic, turns on enforcement in a controlled window, and monitors each workflow separately.
Choose the narrowest workable network rule
Static addresses and CIDR ranges
Static egress addresses provide the narrowest control. Confirm them with the hosting provider and application logs. Avoid allowing office or developer networks unless they legitimately make production API calls.
Serverless platforms and ASNs
Shopify now lets apps allow up to ten ASNs and narrow those networks to up to ten countries. This supports dynamic egress, but an ASN can be shared with other customers. Use static addresses when practical. When an ASN is necessary, select only the provider networks and countries the app actually uses.
Merchant infrastructure
If a public app sends Admin API requests from merchant-controlled infrastructure, Shopify recommends moving toward an architecture that better limits token exposure. Document the current dependency and seek an extension if a safe migration cannot meet the deadline.
Implementation guidance
1. Inventory outbound Shopify traffic
List each service, environment, provider, region, IP range, ASN, country, token type, API, and business workflow. Include temporary migration tools and disaster-recovery environments.
2. Review recent traffic
Use Shopify Dev Dashboard logs and hosting records to find real source networks. Investigate unfamiliar traffic rather than automatically adding it.
3. Test before enforcement
Validate development and staging first. Exercise web requests, background jobs, bulk operations, webhook follow-up, reporting, support tools, retries, and recovery paths.
4. Plan rollback and escalation
Assign an owner who can modify the allowlist. Preserve the prior configuration, document how to identify a network-related 403, and define the customer message when a workflow is delayed.
5. Turn on monitoring
Alert on sudden 403 increases, failed bulk operations, missing reconciliations, delayed jobs, and new source networks. Do not treat an HTTP success elsewhere as proof that every Shopify workflow completed.
Measurement guidance
Track allowed and denied requests by workflow, time to detect, time to restore, unrecognized networks, bulk-operation failures, stale-data incidents, blocked installations, and support contacts. Review whether the allowlist is broader than necessary after every infrastructure change.
Measure business continuity as well as security: inventory freshness, order synchronization, customer communication, and exception closure.
Connect the control to DIGIMAR
DIGIMAR’s automation and integration services can map Shopify callers, build visible failure handling, and connect alerts to accountable recovery tasks. Its web development services can help restructure app traffic and deployment environments.
If Maya supports a customer-facing workflow connected to Shopify, it can be configured to acknowledge an inquiry and hand it to staff when the integration is unavailable. It should not confirm inventory, credits, or completed actions until Shopify returns an authoritative result.
Next step
Before November 12, list every service that runs Shopify bulk operations and test its source network. Then complete the wider public-app inventory before November 20. Turn on enforcement only with monitoring, rollback, and a named recovery owner.
Change management for agencies and app teams
An allowlist rollout affects development, operations, support, and merchant success. Create one change record that names the affected app, deadlines, infrastructure owners, testing window, approver, monitoring dashboard, and rollback authority. Share the expected 403 symptom with support so merchants are not asked to reinstall or repeat unrelated troubleshooting.
Freeze unnecessary infrastructure changes during the enforcement window. A new region, worker, proxy, or hosting provider can introduce a source network that was never tested. If a change is essential, update the inventory and validate the allowlist before moving production traffic.
Prepare evidence for incident response
For each denied request, preserve the timestamp, environment, API, operation, application log, source address when available, and Shopify response. Correlate that evidence with the business workflow. Avoid placing access tokens, customer records, or full request bodies into broad alert channels.
Review third-party dependencies
Ask vendors and subcontractors whether they call Shopify with the app’s tokens, which networks they use, how those networks change, and how incidents are communicated. Contractual access does not replace technical verification.
Post-enforcement review
- Remove temporary or unexplained network entries.
- Confirm every production caller appears in the inventory.
- Review whether static egress can replace a broader ASN.
- Test disaster-recovery infrastructure.
- Record customer-impact and recovery lessons.
Repeat the review whenever the hosting architecture, geographic footprint, or Shopify app ownership changes.