Network and WAF configuration

When you integrate with the Universal Commerce Protocol (UCP), Google servers send server-to-server HTTP requests to your API and OAuth 2.0 endpoints. To allow this traffic, configure your:

  • Perimeter firewall
  • Content Delivery Network (CDN)
  • Web Application Firewall (WAF)
  • Rate limiter
  • Bot management rules

This configuration prevents false-positive blocks on live customer checkouts, profile discovery, and account linking requests.

Recommended request verification

Google routes outbound requests dynamically across global data centers and doesn't guarantee static egress IP ranges or country-specific source IPs. As an alternative to static IP allowlists or geographic IP filtering, authenticate incoming Google traffic at the transport and application layers:

  • Mutual TLS (mTLS): Configure your perimeter load balancer, CDN, or API gateway to verify Google client certificates signed by Google's UCP Root Certificate Authorities (CN=Google UCP Root CA, O=Google LLC for production and CN=Google UCP Root CA (stg), O=Google LLC for staging). For Root CA downloads and gateway configuration examples, see Mutual TLS (mTLS) and the Partner Security & mTLS Integration Guide.
  • Application-layer credentials: Verify the OAuth 2.0 Authorization: Bearer <token> header or X-API-Key header on every checkout and order request. See Application-layer authentication.
  • Cryptographic request signatures (RFC 9421): Verify ES256 message signatures in the Signature and Signature-Input headers (and Content-Digest when a request body is present). Verify signatures against Google's public JSON Web Key Set (JWKS) in https://ucp.goog/.well-known/ucp.json or the versioned URL in the UCP-Agent header. Always fetch keys dynamically from the published JSON URL. For signature verification details, see the UCP Signatures Specification.

Traffic profiles by subsystem

Google uses separate outbound subsystems for UCP checkout and discovery requests versus OAuth 2.0 Account Linking requests. Configure your network and WAF rules to allow all applicable traffic profiles in the following sections.

1. UCP checkout, cart, and order API requests

Outbound requests to your UCP checkout, cart, and order endpoints have the following network and HTTP characteristics:

  • Source Autonomous System Number (ASN): AS15169 (Google LLC), published in https://www.gstatic.com/ipranges/goog.json.
  • User-Agent header: Matches one of the following values:
    • Google-Shopping-Merchant-Integration (default outbound client)
    • Google/UCP* (sent when origin user-agent propagation is enabled)
    • Google-UCP-Prober/1.0 (periodic endpoint health checks)
  • UCP-Agent header: Present on UCP checkout, cart, and order calls in the format profile="https://ucp.goog/..." (for example, profile="https://ucp.goog/profiles/2026-04-08/ucp.json").
  • HTTP headers by method:
    • POST and PUT requests send Content-Type: application/json, Request-Id (UUID), Idempotency-Key (UUID), Payment-Environment (live or sandbox), and Authorization: Bearer <token> (or X-API-Key). They also send Content-Digest (sha-256=:...: on RFC 9421 signed bodies) and X-Forwarded-For (when an origin shopper IP is present). POST and PUT requests don't send an Accept header. Don't require Accept: application/json on POST or PUT checkout rules.
    • GET requests send Accept: application/json, Request-Id (UUID), Payment-Environment (live or sandbox), and Authorization: Bearer <token> (or X-API-Key).
  • OAuth 2.0 client_credentials token requests: If you use machine-to-machine OAuth 2.0, Google sends POST requests with grant_type=client_credentials from AS15169 with User-Agent: Google-Shopping-Merchant-Integration (Content-Type: application/x-www-form-urlencoded or application/json). These token requests don't include UCP-Agent or User-Agent: OpenAuth.

2. UCP profile discovery (GET /.well-known/ucp)

Google periodically fetches your business profile at GET /.well-known/ucp to discover your endpoints, capabilities, and public keys. See Prepare your UCP profile.

  • Source ASN: AS15169 (Google LLC).
  • User-Agent header: Google-Shopping-Merchant-Integration, Google/UCP*, or Google-UCP-Prober/1.0.
  • Standard HTTP headers: Accept: application/json and Request-Id.
  • No UCP-Agent header: Profile discovery requests don't include the UCP-Agent header. Don't require UCP-Agent on GET /.well-known/ucp.

3. Google Account Linking (OAuth 2.0) requests

If you support Identity Linking - OAuth 2.0, Google's Account Linking infrastructure sends server-to-server requests to your OAuth 2.0 token, revocation, and JWKS endpoints for user-delegated authorization_code and refresh_token grants.

Account Linking runs on a separate Google infrastructure pool from UCP checkout:

  • Source ASNs: AS15169 (Google LLC) and AS396982 (Google Cloud). Because AS396982 also hosts Google Cloud customer workloads, always pair ASN rules for AS396982 with OAuth 2.0 client authentication.
  • User-Agent header: OpenAuth or Google-AccountLinking-Fetcher/1.0 (match *OpenAuth* or Google-AccountLinking-Fetcher*).
  • No UCP headers: Account Linking requests don't send the UCP-Agent header and don't use UCP RFC 9421 message signatures. They authenticate with your configured OAuth 2.0 client credentials.

CDN, WAF, and bot management checklist

Enterprise CDNs (for example, Akamai, Cloudflare, Fastly, or AWS CloudFront) evaluate traffic across multiple independent security modules. An IP or header allowlist in a network firewall rule frequently doesn't exempt the request from downstream rate limiters or bot management challenges.

Verify that your CDN and WAF configuration satisfies all four requirements in the following list:

  1. Exempt from geographic IP blocking (Geo-Firewall): Don't block non-domestic source IPs on your UCP API paths, /.well-known/ucp, or OAuth 2.0 endpoints. Google routes UCP and Account Linking requests from global data centers (AS15169 and AS396982). Source IPs frequently resolve to countries outside your primary market.
  2. Exempt from consumer per-IP rate limits (Rate Controls): Consumer rate-limiting policies typically cap requests per client IP (for example, 15 to 20 requests per second per IP). Google multiplexes requests from many concurrent shoppers over a small number of shared outbound NAT IPs. Per-IP rate limiters trigger HTTP 429 or 403 blocks as traffic scales. Exempt verified Google UCP and Account Linking traffic from per-IP rate limits. As an alternative, apply rate limits per user token or checkout session.
  3. Exempt from browser-based bot challenges (Bot Management): Bot management modules (for example, Akamai Bot Manager or Cloudflare Bot Management) frequently enforce browser checks on checkout and login endpoints. Configure a bot-management exception for your UCP API paths, /.well-known/ucp, and OAuth /token endpoints. Don't require the following browser checks on these endpoints:
    • Browser JavaScript challenges or CAPTCHAs
    • Browser telemetry cookies (for example, Akamai _abck or bm_sz)
    • Browser TLS / JA3 / JA4 fingerprint matching
  4. Don't use Google web crawler IP lists for UCP allowlisting: Don't use Google web crawler or fetcher IP range files for your UCP or Account Linking firewall allowlists. This restriction applies to googlebot.json, common-crawlers.json, special-crawlers.json, user-triggered-fetchers.json, and user-triggered-fetchers-google.json (see Verifying Requests from Google). Those IP lists cover web and search crawlers, not the full outbound pool used by UCP and Google Account Linking.
Previous
Authentication
Next
Cart overview