Apollo API IP Allowlist Policy
Apollo’s products connect to a number of Apollo-operated domain names, listed at our Trust Center: GraphOS data privacy and compliance page. For a subset of those services, we publish the underlying IP addresses, to support customers that restrict outbound network access by IP address rather than by hostname.
This network IP allowlisting policy documents:
Apollo’s general policy and practices for maintaining published IP lists.
The services for which we currently publish such IP lists, and service-specific information of which customers should be aware.
Use of this page is optional. Customers that do not restrict outbound network access do not need to take any action based on this page. Customers that restrict outbound access by hostname rather than by IP address also do not need this page. Rather, such customers can allow outbound connectivity to the hostnames documented in Apollo’s service-specific documentation. Where a customer’s network controls support it, Apollo recommends restricting outbound access by hostname rather than by IP address. Hostname-based controls automatically adapt to Apollo’s infrastructure changes, whereas IP-based controls require customers to monitor this page and update their allowlists as the published list evolves.
IP allowlisting policy
Required customer behavior. Where Apollo publishes an IP list for a service, customers that use IP-based egress for that service must allow outbound connectivity to every IP listed for that service. Apollo uses multiple IPs to support availability, rollover, and operational changes. Allowlisting only a single IP or a subset of the list will not provide reliable connectivity and may result in connection failures.
Additions to a published list. Apollo may add new IPs to a published list from time to time. For any addition of an IP that will require customers using IP-based egress to update their allowlist, we will use commercially reasonable efforts to provide at least 60 calendar days’ advance notice before that change takes effect. Typically this means the hostname for the covered service will begin resolving to the newly added IP at the end of the notice period. During the notice period, the list for that service will show both the current IPs and the future IPs, together with the planned effective date.
For purposes of this policy, an “addition requiring customer allowlist update” means an IP not previously listed as current for a covered service will become reachable as part of normal connectivity to that service in a way that requires customers using IP-based egress to allowlist it. It does not include: (i) IPs added to the list ahead of being placed into normal use for the covered service; (ii) changes within a CIDR range already listed; (iii) changes to protocols, ports, hostnames, or other connectivity parameters; or (iv) changes to Apollo infrastructure for services not covered by this policy.
Retirements from a published list. Apollo may stop serving traffic from a previously listed IP at any time. Retirements will be reflected on this page when they occur but are not subject to the 60-day notice period - retiring an IP does not require customers to update their allowlists to maintain connectivity, since Apollo simply stops serving traffic from that IP. Where we have relinquished a previously listed IP back to its cloud provider for potential reassignment, we will indicate that on this page so that customers can choose to remove the IP from their allowlists.
Shorter-notice changes. Apollo may make changes on shorter notice, or without advance notice, where we determine doing so is necessary for incident response, security, abuse prevention, cloud-provider requirements, regulatory requirements, or other urgent operational reasons.
Authoritative source and notifications. This page is the authoritative source for the current published IPs for each covered service, and for any planned changes. A change log appears at the bottom of this page, with a “last updated” date. Apollo may also provide notifications through additional channels (such as a mailing list or RSS feed). Customers remain responsible for monitoring this page (or subscribing to available notifications) and keeping their network allowlists current.
No guarantee of availability or routing behavior. The published IP lists are provided solely to support customer network allowlisting. They do not constitute a service-level commitment, security commitment, or dedicated networking feature, and they do not guarantee service availability, latency, routing behavior, geographic origin of traffic, uninterrupted access to any Apollo service, or compatibility with any particular customer network configuration.
For clarity, Customers remain responsible for designing, operating, and maintaining their own network, firewall, proxy, and client (including GraphOS Router) deployment architecture to meet their availability, resiliency, and security requirements.
Services currently covered by this policy
Apollo Uplink - GCP endpoint
Hostname: uplink.api.apollographql.com
Currently published IPs:
34.117.186.194
Future published IPs (effective no earlier than 2026-Aug-12):
34.117.186.19434.149.219.4
Hostname: persisted-queries.api.apollographql.com
Currently published IPs:
34.36.202.125
Future published IPs (effective no earlier than 2026-Aug-12):
34.36.202.1258.233.57.214
Service-specific notes:
GraphOS Router is configured by default to use two groups of Uplink endpoints: one group in Apollo’s GCP environment and one group in Apollo’s AWS environment, as described in the Apollo Uplink documentation. GraphOS Router uses the AWS endpoint as a fallback when the GCP endpoint does not respond. Each group consists of two domain names. One is used for all GraphOS Routers configured to use Uplink traffic, and the second is used in addition by GraphOS Routers with the Persisted Queries feature enabled.
This policy currently covers the GCP Uplink endpoint only. Apollo does not currently publish the underlying IPs for the AWS Uplink endpoint (https://aws.uplink.api.apollographql.com/ and https://aws.persisted-queries.api.apollographql.com/).
Customers using IP-based outbound egress and relying on this list should be aware that, in scenarios where Router fails to reach the GCP Uplink endpoint, Router will by default attempt to reach the AWS Uplink endpoint. If AWS Uplink IPs are not allowed by the customer’s egress rules, those fallback attempts will fail. Customers wishing to avoid this fallback behavior can configure Router to use only the GCP Uplink endpoint — doing so removes the dual-cloud fallback that Apollo’s default Router configuration provides and may reduce resilience to disruption affecting Apollo’s GCP environment. Customers that take this approach are responsible for understanding and accepting that trade-off.
Change Log
Changes to this policy (including announcement channel updates) will be listed here, and announced on Apollo’s blog in the “Announcement” category.
2026-Jun-07: Initial policy published. The currently published IPs for each covered service are unchanged from prior practice. This publication also constitutes notice of additional IPs to be added no earlier than 2026-Aug-12 (see service-specific sections above).