For the complete documentation index, see llms.txt. Every page on this site is also served as Markdown: append `.md` to any URL, or send `Accept: text/markdown`.
Skip to content

Bots

APIs-Google: allow it or block it?

APIs-Google is the agent that delivers push notification messages from Google APIs to endpoints your application subscribed. Allow it: blocking it stops those notifications and changes nothing about search or AI visibility. Google states it ignores the robots.txt wildcard, so only a group naming APIs-Google reaches it, and it verifies under google.com, not googlebot.com.

7 days free · card required

AI traffic · attensira.com30 days to 4 Oct 2026

0requests filed as APIs-Google · 30 days

of 143,601 AI crawler requests from 7 operators

We do not name APIs-Google, and its operator states it ignores the User-agent: * group, so no rule in our file reaches it. Only a group that names APIs-Google would.

Analyst agentAnalyst · reads the AI traffic boardAI traffic board, read over the Attensira MCP, and our live robots.txt · · n=143,601 AI requests
Karl-Gustav KallasmaaKarl-Gustav Kallasmaa, Founder & CEOLast updated

Who runs APIs-Google, and what is it for?

Google runs it, and we file it under product operations. Delivers push notifications from Google APIs to an endpoint that subscribed to them. It reads no pages.

From Google’s documentation, read .

How do I allow or block APIs-Google in robots.txt?

Paste this into the robots.txt at the root of your domain. Only a group that names the token reaches it; your * group does not.

# A wildcard group will NOT stop# this agent. Address the token# directly.User-agent: APIs-GoogleDisallow: / # More usually, leave it alone —# it delivers push messages you# subscribed to.

What is APIs-Google actually delivering to you?

Messages you asked for. Google documents that rules addressed to the APIs-Google user agent affect the delivery of push notification messages by Google APIs1. It arrives at an endpoint your application registered to be notified at. Nobody is indexing you and nobody is training on you; the traffic exists because of a subscription you or a colleague set up.

That makes it the least crawler-like agent in this directory, and it changes the question. The decision is not whether an outside operator may read your site. It is whether one of your own integrations keeps receiving its updates.

Why doesn't your wildcard rule stop it?

Because Google documents that it does not apply. Google gives APIs-Google as the robots.txt token for this agent and states, in the same table, that the global user agent (*) is ignored3.

This surprises people in a repeatable way. Someone writes User-agent: * with Disallow: / on a staging host, the push deliveries keep arriving, and the conclusion is that a scraper is impersonating Google. What they are seeing is the documented behaviour.

Google's framing of the special-case category explains it. These are crawlers or fetchers performing specific functions for Google products where there is an agreement between the crawled site and the product, and Google says they may or may not respect robots.txt4. The agreement is the point. You subscribed. A wildcard group is a message to crawlers that arrived uninvited, and this one did not.

What happens if you name it and block it?

It stops, and so do your notifications. The robots.txt block above shows the only rule that reaches it: a group naming APIs-Google. Writing it is a decision to stop receiving push notifications from Google APIs on that host, not a decision about search or AI visibility.

Before you write it, find out which integration depends on it. The failure is silent. Nothing errors; updates stop arriving, and something downstream goes stale days later in front of people who will not think to look at robots.txt.

Why does verification reject genuine APIs-Google requests?

This catches teams who have already built Google verification once. The special-case crawlers do not resolve under googlebot.com. Google documents their reverse DNS mask as rate-limited-proxy-*.google.com and publishes their ranges in a separate special-crawlers.json file5.

So middleware that admits Google by checking for a googlebot.com hostname rejects every genuine APIs-Google request while admitting any forgery that copies the header. That is the worst of both outcomes. Reverse-resolve the address, accept google.com hostnames for this category, and forward-resolve back to the same address.

  • Common crawlers (Googlebot and others)

    Reverse DNS mask
    googlebot.com
    Range file
    common-crawlers.json
  • Special-case crawlers (APIs-Google, AdsBot, Google-Safety)

    Reverse DNS mask
    rate-limited-proxy-*.google.com
    Range file
    special-crawlers.json
VerificationGoogle
Reverse DNS ends in
*.google.com
Researcher agentResearcherTranscribed from Google documentation ·

How should you match APIs-Google in logs?

Google publishes the header as the token APIs-Google followed by a link to its APIs-Google help page, as shown in the user-agent section above2. Two details matter. The casing is APIs-Google, capital A, P and I, lowercase s, and it is often retyped as Apis-Google in a case-sensitive filter that then matches nothing. And there is no version number, which is unusual among Google's agents: match the bare token and you match everything this agent will ever send.

Where does APIs-Google belong in a report?

Nowhere near a visibility number. In the four-way job taxonomy of the AI crawler guide, it is product operations. Its volume tracks your API subscriptions, so in a crawler total it makes the number move when you change integrations and stay still when your standing in search changes. Give it its own row, next to your webhook telemetry, and read it as infrastructure.

Its siblings in Google's special-case group are AdsBot-Google, which checks your ad landing pages, and Google-Safety, which checks links for abuse. They share the verification path and the habit of ignoring the wildcard.

What can Attensira show you about APIs-Google?

Mainly where it does not belong. AI traffic, on Growth and Business, groups fetches by operator and declared purpose at the edge, so infrastructure traffic like this is kept apart from the crawlers and agents that bear on AI answers. It reports user agents as sent; the special-case reverse DNS check stays yours. See crawler logs and the robots.txt generator.

User-AgentGoogle
APIs-Google (+https://developers.google.com/webmasters/APIs-Google.html)
Researcher agentResearcherTranscribed from Google documentation ·

Should I allow APIs-Google in my situation?

Concrete cases, and what each one implies for this agent.

  • You added a blanket wildcard disallow and APIs-Google kept arriving, so you assumed it was a spoof.

    Check the source addresses before concluding anything, then address the token by name if you really want it gone.

    Google documents that the global user agent is ignored for this crawler. Continuing to arrive after a wildcard block is the documented behaviour, not evidence of a forgery — and blocking it by name may break a push subscription your own application depends on.

  • Your bot-verification middleware rejects anything not resolving to googlebot.com and Google API pushes started failing.

    Widen the verification to Google's special-case mask under google.com and the special-crawlers.json range file.

    Google publishes three separate categories with three separate reverse DNS masks and range files. The special-case crawlers resolve under rate-limited-proxy-***-***-***-***.google.com, so middleware written around Googlebot alone rejects every legitimate request from this agent while proving nothing about the forged ones.

  • You are writing a crawler report and want to know whether APIs-Google traffic means anything about visibility.

    Exclude it from any visibility measure and keep it with your webhook telemetry.

    Google documents this agent's effect as the delivery of push notification messages by Google APIs. It is infrastructure for something you subscribed to, not discovery of your content, so its volume tracks your own integrations rather than anyone's interest in your pages.

What else do people ask?

What is APIs-Google?
APIs-Google is the user agent Google documents for delivering push notification messages from Google APIs. It arrives at an endpoint your application asked to be notified at, because of a subscription you or a colleague set up. It does not index or train on anything.
Is APIs-Google traffic a scraper pretending to be Google?
Not if it verifies. Its reverse DNS mask is rate-limited-proxy-*.google.com and its ranges are in Google's special-crawlers.json file. Middleware that only accepts googlebot.com hostnames will reject the genuine requests and call them fake.
Does APIs-Google traffic say anything about my visibility?
No. Its volume tracks your own API subscriptions. Put it in its own row next to your webhook telemetry, not in a crawler total that people read as interest in your content.

Where do these facts come from?

5 claims on this page, each with the page it was read from; last checked . The numbers in the text point here.

  1. Google documents that crawling preferences addressed to the APIs-Google user agent affect the delivery of push notification messages by Google APIs.

    developers.google.com · retrieved

    “affect the delivery of push notification messages by Google APIs.”
  2. Google publishes APIs-Google's User-Agent in HTTP requests as "APIs-Google (+https://developers.google.com/webmasters/APIs-Google.html)".

    developers.google.com · retrieved

    “APIs-Google (+https://developers.google.com/webmasters/APIs-Google.html)”
  3. Google documents APIs-Google as the robots.txt user agent token for this crawler and states that the global user agent (*) is ignored.

    developers.google.com · retrieved

    “The global user agent (*) is ignored.”
  4. Google documents the special-case crawlers as crawlers or fetchers performing specific functions for Google products where there is an agreement between the crawled site and the product, states that they may or may not respect robots.txt rules, and notes that they operate from a different IP range from the common crawlers.

    developers.google.com · retrieved

    “The special-case crawlers may ignore robots.txt rules and so they operate from a different IP range than the common crawlers.”
  5. Google documents the special-case crawlers' reverse DNS mask as rate-limited-proxy-***-***-***-***.google.com and publishes their IP ranges in the special-crawlers.json object.

    developers.google.com · retrieved

    “The special-case crawlers' reverse DNS mask matches rate-limited-proxy-***-***-***-***.google.com”

Want whatever it takes to win the answer?

7 days free · card required