APIs-Google

APIs-Google is the user agent Google APIs use to deliver push notification messages. Instead of repeatedly polling Google’s APIs to discover whether a resource has changed, an application can register a notification channel and provide an HTTPS callback URL. When the watched resource changes, Google sends a POST request to that URL.

APIs-Google does not discover links, build a search index, or browse an unregistered website. It is a special-case Google crawler whose traffic is tied to an explicit relationship between a Google API, an application, and a registered callback URL.

Google requires developers to verify domain ownership before registering a callback URL—though the user-agent can be spoofed, so receiving applications should still validate the request and notification context.

Google Drive and Google Calendar are common examples: when a resource changes, a POST request is sent to the registered URL, signaling the application to retrieve the updated state.

• Google API push notifications: Applications receive an event when a watched Google resource changes, avoiding continuous polling.
• Google Drive and Calendar webhooks: Drive and Calendar notification channels send HTTPS POST callbacks for supported resource changes.
• Retry delivery after temporary failures: If a notification request fails because of a temporary error, APIs-Google retries using exponential backoff, potentially for several days.
• Domain-controlled callback registration: Google requires the developer to prove ownership of the domain before registering a callback URL for APIs-Google messages.
• Event-driven application workflows: A callback can trigger a synchronization job, cache refresh, workflow update, or follow-up API request without exposing the full resource contents in the webhook request itself.

The legitimate use case is narrow, but the identity can still be imitated or misconfigured:

• Spoofed callback traffic: An attacker can copy the APIs-Google user-agent and send requests to a webhook that assumes the label proves the caller’s identity.
• Webhook endpoint probing: Public callback paths can reveal whether an integration exists, how the application responds, or which headers and payload formats it expects.
• Unauthenticated event injection: If the receiver accepts any POST that looks like a Google notification, an attacker may trigger unnecessary synchronization jobs, queue work, or downstream API calls.
• Retry-pattern mimicry: Genuine retries can be sporadic or bursty. Malicious requests can imitate that pattern to blend into normal webhook traffic.
• Orphaned subscriptions: A notification channel may remain associated with a deprecated integration or a URL that was later repurposed for another application.
• Confusion with generic Google traffic: Googlebot, Google API fetchers, Cloud Pub/Sub, and other Google services do not all represent the same product or authentication model. A broad Google allowlist can therefore authorize traffic that the application never intended to receive.

Spoofed APIs-Google requests do not create or modify the underlying Google notification channel. Their impact is local to the receiving environment, where they can create load, queue work, pollute logs, or exploit weak webhook authorization.

If APIs-Google traffic appears in your logs, an application likely registered one of your domain’s URLs as the callback for a Google API notification channel. Google notes that subdomain or URL-space owners may have configured a separate integration, so the responsible application may not be obvious to the current team.

A few traffic characteristics are important:

• Traffic volume is uneven. The rate depends on how many notification channels exist, how frequently the watched resources change, and whether Google is retrying failed deliveries.
• HTTPS is required. The receiving site needs a valid certificate. Self-signed, revoked, or untrusted certificates cause delivery failures and can lead to repeated retries.
• Fast responses reduce retries. The receiver should acknowledge notifications promptly, within seconds, to avoid unnecessary retry traffic.
• The request may contain a signal rather than the changed resource. Drive and Calendar notifications commonly rely on headers and require the receiver to make a follow-up API request for the current state.
• A legacy integration may be the cause. A former employee, vendor, subdomain owner, or scheduled workflow may have created the notification channel.

1. Inspect the user-agent. The documented value is APIs-Google (+https://developers.google.com/webmasters/APIs-Google.html). Treat it as a claim, not proof of origin.
2. Run a reverse DNS lookup. Google says an APIs-Google request should resolve to a hostname under google.com or googlebot.com.
3. Perform forward-confirmed reverse DNS. Resolve the returned hostname and verify that it maps back to the original source IP. A user-agent match without this check is insufficient.
4. Use Google’s published special-crawler ranges as an additional signal. Google publishes a special-crawlers.json file for special-case crawlers, including APIs-Google. Keep the range data current.
5. Do not rely on AS15169 alone. Google ASN ownership can support an investigation, but it is weaker than forward-confirmed reverse DNS and published range validation.
6. Match the endpoint and integration context. Confirm that the URL is a known webhook, that the request uses HTTPS POST, and that its headers, channel identifiers, resource identifiers, and expected source fit the integration.
7. Separate notification receipt from authorization. For Drive and Calendar, treat the callback as a change signal and retrieve resource data through the authenticated Google API rather than trusting arbitrary request data.
8. Review Cloud Pub/Sub separately. For authenticated Pub/Sub push subscriptions, validate the JWT in the authorization header and the expected audience. Do not use APIs-Google rules as a substitute for Pub/Sub authentication.

Do not block verified APIs-Google traffic by default if your organization depends on Google API notifications. Blocking the callback can silently break synchronization, cache refreshes, or other event-driven workflows.

Restrict or block the traffic when:

• the callback belongs to a deprecated or unknown integration;
• requests fail forward-confirmed reverse DNS or published-range checks;
• the endpoint is not registered as a Google API webhook;
• the application cannot validate the notification context; or
• the endpoint has been repurposed and should no longer receive callbacks

If the integration is no longer required, unregister the notification channel or disable the application that created it. This is more reliable than blocking requests downstream. If the integration is still required, protect the endpoint with scoped verification and application-level controls rather than a user-agent-only allowlist.

• Use an explicit robots.txt rule when appropriate. APIs-Google does not follow the global * rule. To control it, use the dedicated token:

User-agent: APIs-Google

Disallow: /path-to-webhook/

Google notes that robots.txt changes may take time to take effect, and existing traffic may continue for several days. Use this as a traffic-preference control, not as the only security boundary.

• Use a dedicated, unguessable callback path. Avoid placing notification receivers on a generic login, API, or state-changing route.
• Validate the request at the edge and in the application. Combine User-Agent, source verification, HTTPS, expected method, endpoint, headers, channel identifiers, and integration state.
• Use signed authentication when the transport supports it. Cloud Pub/Sub push subscriptions can include a Google-signed JWT. For Drive and Calendar notifications, use a protected callback path and validate the notification headers and channel context, because the notification itself is not a substitute for API authentication.
• Acknowledge quickly and process asynchronously. Return a success response promptly, then queue the synchronization work. This reduces avoidable retries and protects the webhook from work amplification.
• Audit notification channels. Record the owning application, Google API, callback URL, channel ID, resource ID, creation time, expiry, and responsible team. Remove channels associated with decommissioned integrations.
• Avoid a broad Google allowlist. Google operates multiple crawlers, fetchers, and delivery services. Authorize APIs-Google only for endpoints and workflows that require it.

APIs-Google should be handled as a narrowly scoped Webhook or Technical Partner integration, not as unrestricted Google traffic. A safe authorization decision should combine identity verification with endpoint context and observed behavior. DataDome’s bot-authentication guidance supports reverse DNS, forward DNS confirmation, static or dynamic IP lists, and other multi-signal approaches rather than trusting a user-agent alone.