Shopify’s latest security change turns network configuration into an immediate operating concern for merchants that depend on custom integrations. On November 11, 2026, Shopify announced that custom apps installed on stores outside the organization that owns the app must use an IP allowlist. New installs face a November 20, 2026 deadline, while existing installs must comply by January 1, 2027. The change is designed to limit where an app can call the Admin API if credentials are exposed.
For a small or midsize business, this is not merely a developer setting. A custom app may connect orders, inventory, customer service, fulfillment, reporting, or a CRM. If its network access is not configured correctly, an installation or business workflow can be interrupted. The practical response is to identify every affected connection, confirm how it reaches Shopify, apply the narrowest workable rules, and test the full business process.
What the Shopify custom app IP allowlist rule covers
Shopify says the requirement applies to custom apps installed on stores outside the organization that owns the app. Apps used only within their owner’s organization, merchant-created apps, and public apps fall into different categories. Public apps already have a separate allowlist requirement.
The important distinction is ownership, not simply whether an app is “private.” An agency, integration provider, or software company may own a custom app that is installed on a client’s store. That cross-organization installation is the pattern merchants and providers should review first.
Shopify’s official notice also explains two configuration paths. Apps with stable outbound addresses can allow specific IP addresses or CIDR ranges. Apps whose outbound addresses change can use the hosting provider’s autonomous system numbers, or ASNs, together with the countries where the app operates. Read the Shopify custom-app allowlist announcement before changing production access.
Why this matters beyond compliance
An Admin API token can authorize sensitive actions. An allowlist adds a network boundary: possession of a token alone is not enough when a request originates outside the approved network. That is useful defense in depth, but only when the rules match the application’s real architecture.
A rushed rule can also block legitimate work. Serverless functions, background jobs, staging systems, failover regions, and third-party automation platforms may originate from different networks. The business risk therefore has two sides: leaving access too broad weakens the control, while configuring it too narrowly can stop order or customer workflows.
Map the workflow before the network
Start with the business event, not the infrastructure. Write down what triggers the app, what data it reads or writes, and what must happen next. A simple map may be: paid order → integration → fulfillment system → tracking update → customer notification. Another may be: website inquiry → qualification → CRM record → callback task.
This approach exposes dependencies that an app inventory alone can miss. A nightly export, a retry queue, or an exception-handling job may use a different environment from the primary application.
A practical implementation checklist
1. Inventory affected apps and owners
Record the app name, owning organization, stores where it is installed, business owner, technical owner, hosting provider, and critical workflows. Confirm whether each installation crosses an organization boundary. Do not assume that an app’s label accurately describes its ownership.
2. Identify every outbound network path
Ask the technical provider for production egress IPs, CIDR ranges, ASNs, operating countries, staging addresses, and failover paths. If an automation platform or integration service makes the Shopify call, document that platform’s network behavior rather than the merchant office IP.
3. Choose the narrowest stable configuration
Specific static addresses are easier to reason about when the infrastructure supports them. ASN-based rules can fit serverless or dynamic hosting, but they may cover a larger network. The right choice depends on the architecture and should be paired with country declarations and monitoring.
4. Test success and failure cases
Use a development store when possible. Confirm that approved production-like traffic succeeds and that a request from an unapproved network fails. Then test the complete workflow, including retries, scheduled jobs, webhooks, manual reprocessing, and exception alerts.
5. Prepare rollback and escalation
Document who can change the allowlist, how quickly they can respond, and how the business will operate if the integration is unavailable. A manual order-export procedure or temporary customer-communication process can reduce operational confusion during an incident.
Practical SMB example
Consider a hypothetical specialty retailer whose agency-owned custom app copies Shopify orders into a warehouse system. The main application runs on a cloud server with a static address, but failed orders are retried by a serverless job. If the team allows only the primary address, normal orders appear to work while retries silently fail.
The retailer maps both paths, adds the appropriate network rules, sends test orders, deliberately triggers a retry, and confirms inventory and tracking updates. It also assigns an operations owner to review failed jobs daily during the transition. The result is not a guarantee of uninterrupted service; it is a controlled rollout with known dependencies and clear accountability.
How to measure the change
Track operational measures before and after rollout: successful Admin API calls, denied requests, retry volume, failed order syncs, average recovery time, and unresolved exceptions. Add business-facing checks such as orders missing from fulfillment, inventory updates delayed beyond the normal window, and customer notifications awaiting data.
A short baseline matters. Without it, every post-change error may be blamed on the allowlist even when the underlying issue is unrelated. Segment errors by app, store, environment, and source network so the team can diagnose patterns quickly.
Where DIGIMAR can help
DIGIMAR can help SMBs document Shopify workflows, review integration architecture, coordinate configuration with hosting or app providers, and build monitoring around the business events that matter. Our AI automation and integration services focus on reliable handoffs among commerce, CRM, email, calendars, and operational systems. When the work also involves storefront performance or custom functionality, see our web development services.
The best next step is a focused inventory: list every custom app, its owner, its stores, and the workflows it supports. Then validate network requirements with the people who operate each app. Security controls work best when they are tied to real business processes, tested deliberately, and owned after launch.