I wanted a simple thing: a weekly feed of new patent filings matching a keyword, so I could watch what competitors in a given technology are up to. The official routes all said no. The USPTO Open Data Portal returned 401 without an API key. The bulk data endpoint answered 503 for days. PatentsView had just moved to key-only access with an approval queue.
Then I opened DevTools on Google Patents and found that the whole site runs on one undocumented XHR endpoint. No key, no login, worldwide coverage.
The endpoint
When you search on patents.google.com, the frontend calls:
https://patents.google.com/xhr/query?url=q%3D(solid%2Bstate%2Bbattery)%26sort%3Dnew
The url parameter is itself a URL-encoded query string. Decode it and you get the same syntax the search box uses: q=(solid+state+battery)&sort=new, plus operators like assignee=Nintendo or country=US. The response is JSON with results.cluster[0].result[], each entry carrying the publication number, title, snippet, assignee, inventor and dates.
It works with plain HTTP requests. I have been running it on a schedule for a couple of days now without drama, which is more than I can say for my week with the official APIs.
Three traps I hit so you don't have to
1. Server-side date filters return zero. The query syntax accepts after=publication:20260101, and on the website it works. Through the XHR endpoint the same filter quietly returns an empty result set. Not an error, just nothing. The fix is to drop the filter, fetch pages sorted by newest, and filter publication_date client-side. Annoying, but reliable.
2. sort=new is not actually sorted. I assumed I could stop paginating once I saw a date older than my window. Wrong: results within sort=new are shuffled inside a rough two-month band, so an old date does not mean the rest of the page is old too. If you early-exit on the first stale date, you silently lose fresh publications. You have to walk the whole window and let the client-side filter do its job.
3. The index lags reality by about two months. A patent published last week will usually not be in Google Patents yet. If you set your watch window to 30 days, most weeks return nothing and you conclude the tool is broken. Ninety days is the sweet spot: you see everything, slightly deferred. For patents that trade-off is usually fine, since the filings themselves are 18 months old by the time they publish.
There is also the ordinary anti-abuse stuff: burst requests from datacenter IPs get 503s, so pace your calls and use decent proxies. And the JSON fields arrive with <b> highlight tags around your search terms, which you need to strip before the data is clean.
Try it
I packaged all of this as an Apify Actor, patent-watch. One call:
curl -s -X POST \
"https://api.apify.com/v2/acts/jdepablos~patent-watch/run-sync-get-dataset-items?token=$APIFY_TOKEN" \
-H "Content-Type: application/json" \
-d '{"term": "solid state battery", "daysBack": 90}'
You can watch a technology (term), a company (assignee: "Nintendo"), or both at once, up to 20 watches per run. Pricing is per watch that returns hits; a quiet week costs nothing.
Wiring it into an AI agent (MCP)
One line of config through Apify's MCP server:
https://mcp.apify.com?tools=jdepablos/patent-watch
Your agent gets a "what's new in patents for X?" tool with structured output. Put it on a weekly schedule and the agent writes your competitive R&D brief for you.
What I took away
Official APIs are the right first choice, and I always probe them before touching anything else. But when the official route is keyed, queued or down, the data-bearing endpoint behind a public website is often better documented by its own network tab than the sanctioned API is by its docs. Just treat it with respect: pace your requests, filter client-side when the server lies to you, and never trust a sort order you have not verified.
If you watch patents for competitive intelligence and there is a field or filter you miss, tell me in the comments. The last feature request I got on one of these feeds turned into a shipped field plus a bug fix within a day, so they do not land in a void.
Top comments (0)