The storefront is working, the app token has not changed, and the inventory worker has started returning 403 responses. Those observations are compatible. A storefront's availability says little about a background worker's outbound connection, and a valid token does not necessarily grant access from every network location.

Shopify's October 27 update adds an IP allowlist for Admin API access. Developers can enter server addresses or CIDR ranges, test them against recent traffic, and then enable enforcement. Requests using the app's tokens from outside the allowed ranges are rejected for both GraphQL and REST Admin APIs. Source admission therefore becomes a separate condition alongside the app's existing authorization.

For an international commerce team working with a Chinese supplier or an external integration provider, the practical question is not simply whether someone has supplied an IP address. It is whether that address belongs to the process that actually performs the work, including the process used when the normal one is unavailable.

Follow the request out of each environment

A public website address identifies where visitors reach a service. An outbound address identifies where an external platform sees a request originate. Infrastructure can place these behind different network arrangements. Copying the storefront's address into an allowlist is therefore not a reliable substitute for observing the integration's actual egress.

Start with tasks rather than machines. Identify the worker that reads products, the job that updates inventory, the reporting process, and any maintenance tool that uses the same app. Record the environment and owner for each. Two jobs that share code may run on different infrastructure and leave through different addresses; identical software is not evidence of an identical network path.

The backup arrangement matters for the same reason. If a secondary worker is intended to take over during maintenance, its source needs an explicit place in the plan. Otherwise, a control that appears sound during normal operation can prevent the recovery path from functioning exactly when it is needed. A developer's successful test from a laptop does not cover that path.

Shopify recommends static IP addresses and describes support for dynamic serverless environments as forthcoming. Teams with changing egress should not treat the address observed today as a durable solution. Ask the hosting or integration provider what stable outbound option is actually available, and whether it covers all required environments. The announcement alone is not a reason to migrate a working system or to assume a promised future capability exists now.

For a brand buying a managed integration, this is a useful acceptance discussion with the provider. Ask which tasks the proposed ranges cover and how a future infrastructure change will be communicated. An unexplained list of addresses leaves the brand unable to distinguish an obsolete entry from one that supports an infrequent but necessary operation.

Test the business paths, not just one request

Before enforcement, compare the proposed rule with recent traffic and with the tasks the business expects to keep running. Include routine workers, scheduled jobs and the agreed backup route. A quiet period may not include a monthly report or an occasional support action, so recent observations should be read alongside the task inventory rather than treated as a complete inventory themselves.

Use existing logs and read-only operations where possible to establish the path. There is no need to create unnecessary orders, change stock or trigger customer messages merely to prove where a request originates. Testing should answer a network question without creating a separate business cleanup problem.

If failures begin after enforcement, retain the time, affected worker and environment before changing credentials. A 403 is a symptom, not a complete diagnosis: permissions, source restrictions and other controls can produce access failures. Replacing a token without isolating the cause can disrupt healthy consumers while leaving the original source mismatch untouched.

Once connectivity returns, reconcile the work that stopped. A successful request does not establish that missed updates have been applied. Our discussion of backlogged actions after a sales sync pause addresses that separate recovery step. Keep connection recovery and business-state recovery as two explicit checks, especially when jobs may be replayed.

The finished change should be understandable to both the integration owner and the operating team: expected tasks work from known sources, unwanted sources are restricted, backup operation is accounted for, and every permitted range has a documented purpose. That is a more useful result than a green test from one computer followed by uncertainty about the next scheduled job.

Sources