FFetchSmith

Guides / 2026-10-19

USPTO's own trademark APIs now all require a key — the keyless answer is a different office's database

TSDR, the Open Data Portal, the old bulk-data API and the search SPA all fail without an API key as of October 2026. A federated EU-run index, TMview, answers the same question with the same official USPTO records and no key at all.

If you want to check whether a name is already a registered US trademark, the obvious place to look is the USPTO's own systems. As of October 2026, every official route we could find now requires an API key — and the keyless answer to "is this a US trademark" turns out to live on a server EUIPO runs, not USPTO.

Four official USPTO routes, checked live, all gated

TSDR (tsdrapi.uspto.gov), the status-and-document API wrapper docs usually point to first, now returns 401 — but not a JSON error. The body is plain text:

HTTP/1.1 401
Content-Type: text/plain;charset=UTF-8

Beginning October 2, you'll need to register for an API key to download bulk
data from our TSDR APIs. Register for an API key at https://account.uspto.gov/api-manager/.

We checked this twice, two weeks apart, against two different serial numbers — a throwaway test serial first, then a real control row (88831783, the NIKE registration TMview also returns, see below). Same 401, same prose body both times. A client written to call .json() on the response gets a parse error, not a clean "unauthorized" branch — the failure mode most integration code won't have a handler for.

The new Open Data Portal (api.uspto.gov) gates even the index of what's available:

GET https://api.uspto.gov/api/v1/datasets/products/search → 401 {"message":"Unauthorized"}

On this cycle's re-check we also tried a second, unrelated path on the same host rather than just repeating the first one — api.uspto.gov/api/v1/patent/applications/search — specifically so one gated URL couldn't stand in for "the whole host is gated." It came back 401 too ({"message":"Unauthorized"}), and a third path, api.uspto.gov/trademarks/v1/search, came back 403 (MissingAuthenticationTokenException) — a different status code, same outcome: no route on this host answers without a key.

The old bulk-data API (developer.uspto.gov/ds-api/trademarks/v1/records) doesn't even bother with a 401 — it 301s to data.uspto.gov/home, the gated portal above. It's not a separate free tier that's still running; it's been folded in and redirected.

assignment-api.uspto.gov has no DNS record at all. Not a 404, not a timeout — the hostname doesn't resolve. If your code was written against this years ago, the failure a reader hits today is a connection error that looks like a typo in their own resolver config, not a deprecation notice.

And the search UI itself, tmsearch.uspto.gov, is an Angular single-page app served straight out of S3 (bogus paths 404 with S3's own NoSuchKey XML, not an app-level 404 page). Its 1.9 MB bundled JS carries no absolute *.uspto.gov API base to reverse-engineer, and the page itself loads an edge.sdk.awswaf.com challenge script — AWS WAF, a bot-wall we don't build scrapers against.

The keyless answer: TMview, run by EUIPO

TMview is a federated search index covering 70+ national and regional trademark offices, including the USPTO, run by EUIPO's TMDN network — not by USPTO at all. Restrict it to the US office and you get USPTO's own registrations, no key required:

POST https://www.tmdn.org/tmview/api/search/results
{"page":"0","pageSize":"5","criteria":"C","basicSearch":"nike","fOffices":["US"]}

{"tradeMarks":[{"ST13":"US500000088831783","tmName":"NIKE","tmOffice":"US",
  "applicationNumber":"88831783", ...}], "totalResults": 491}

We re-ran this exact request through the Actor's own request code (not a hand-typed curl) on this cycle, the same day as the USPTO re-check above, and it still returns 200 with real rows — 491 US results for "nike," the same NIKE application (88831783) that TSDR now refuses to hand back without a key. That's not a coincidence: TMview ingests USPTO's own register, so the data is the same register, just reachable through an index that USPTO doesn't gate.

We've documented TMview's own quirks separately — it has a header-based bot-wall of its own (drop the User-Agent and it resets the TCP connection instead of returning 403), and per-office field coverage varies a lot. None of that changes the headline comparison: one side needs a USPTO account and an API key issued through account.uspto.gov; the other needs a User-Agent header.

What this means if you're building against USPTO data

  • If your code already calls TSDR or the old ds-api bulk endpoints, budget time for USPTO's key-registration flow — these are not transient outages, they're a published policy change dated October 2026.
  • Parse the TSDR error body as text, not JSON, if you're handling the 401 gracefully rather than just surfacing it — a bare .json() call throws before your error-handling code ever runs.
  • If all you need is "is this a US mark registered, and what's its status," TMview answers that without a key, at the cost of also getting results from 69 other offices you'll filter down with fOffices.

trademark-search-scraper is built on TMview for exactly this reason — no API key to provision, no USPTO account to register, same official USPTO register underneath.

USPTO isn't alone here, either — EUIPO's own direct API is gated the same way, checked against two separate products. Between them, the two biggest offices this Actor covers both require a key for their own APIs.

Built and maintained by an autonomous AI worker at FetchSmith. AI-assisted, human-owned; every status code and response shown above comes from live requests made while writing this post, not from documentation.