Trademark Search API across USPTO, TMview, Madrid and IP Australia

A trademark search that returns one row per mark from the public registers a brand-protection team actually needs: USPTO TSDR, TMview, WIPO Madrid Monitor, IP Australia and the WIPO Global Brand DB. Give it a word mark or a serial, registration or Madrid international registration number and get back the mark text, owner, a live / dead / pending trademark status with the office's own wording kept alongside it, numbers, Nice classes, goods and services text, dates and per-source status flags. It is a trademark search API as well as a Store actor: rows land in the default dataset as JSON, so the same run feeds a clearance script, a spreadsheet import or a brand-protection sweep.

This trademark search is built for sweeps and for single-file checks. A word query fans out across the readable indexes and merges the hits in a stable order; a number query resolves one dossier and corroborates it in the shared index. Closed national registers are never silently dropped: when you ask for one explicitly and nothing came back through the indexes, the run names that office with a blocked_reason.

What you get

Every dataset row is one mark (or one diagnostic row — see below). Fields match the registers:

• mark, owner, office, office_name
• status_norm (live / dead / pending) and status_raw, the office's own wording (DEAD/APPLICATION/Refused/Dismissed or Invalidated, Registered, Ended, Registered: Registered/protected, …)
• serial, registration_number, st13
• nice_classes (sorted integers 1–45), goods_services
• application_date, registration_date, expiry_date, status_date, publication_date
• t_protection, seniority, mark_type, opposition_period_start, opposition_period_end
• US extras: documents_count, assignments_count, proceedings_count, proceedings
• source_url, a deep link to the record in its own register
• source_status, per-source flags (ok, not_found, rate_limited, blocked, skipped) so a real "not found" is distinguishable from a register that did not answer

Input

field	meaning
mark	word mark to search for, e.g. NIKE or CREATE-A-CUP
number	serial, registration number or Madrid IRN, e.g. 78888801
number_kind	auto (default), application_number, registration_number, irn
mode	lookup (default), search, classes
offices	comma-separated office codes (US,EM,WO,AU); empty means every office
nice_classes	comma-separated Nice numbers 1–45 to filter on
max_rows	upper bound per source, 1–500 (default 50)
include_goods_services	fetch goods and services wording where reachable (default true)

At least one of mark or number is required. Both together run a word search and an exact lookup in the same run. mode: classes returns the Nice classification headings instead of marks — useful when you only need the class wording.

A trademark search in the WIPO registers runs two ways: number_kind: irn resolves an international registration in Madrid Monitor, and a word mark reaches the WIPO Global Brand DB. number_kind: auto reads whichever of serial, registration number or IRN you supplied and picks the right register for it.

Example input

{"number": "78888801"}

{"mark": "NIKE", "offices": "US,EM", "nice_classes": "25,35", "max_rows": 20}

Output

Results land in the default dataset, one object per row. The run summary is the OUTPUT record in the key-value store:

{
  "itemCount": 2,
  "markCount": 2,
  "errorCount": 0,
  "chargeEvent": "trademark",
  "sourceStatus": {"tsdr": "ok", "tmview": "ok", "madrid": "skipped", "ipaustralia": "skipped", "branddb": "skipped"},
  "query": "sn78888801",
  "marksFound": ["CREATE-A-CUP"],
  "statusNormCounts": {"live": 0, "dead": 2, "pending": 0}
}

A dataset row is a real record, not a summary. This is the first row the run above delivered, verbatim:

{
  "mark": "CREATE-A-CUP",
  "owner": "Playtex Products, Inc.",
  "status_norm": "dead",
  "status_raw": "DEAD/APPLICATION/Refused/Dismissed or Invalidated",
  "serial": "78888801",
  "registration_number": null,
  "office": "US",
  "office_name": "United States (USPTO)",
  "nice_classes": [21],
  "goods_services": "Children's spill-proof drinking cup with removable insert for drawing/coloring by child",
  "application_date": "2006-05-22",
  "registration_date": null,
  "expiry_date": null,
  "t_protection": [],
  "st13": null,
  "source": "tsdr",
  "source_url": "https://tsdr.uspto.gov/statusview/sn78888801",
  "documents_count": 17,
  "input": "sn78888801",
  "source_status": {"tsdr": "ok", "tmview": "ok", "madrid": "skipped", "ipaustralia": "skipped", "branddb": "skipped"},
  "mark_type": "Trademark",
  "status_date": "2008-11-24",
  "publication_date": "2007-07-31",
  "assignments_count": null,
  "proceedings_count": 0,
  "opposition_period_start": null,
  "opposition_period_end": null,
  "seniority": [],
  "proceedings": [],
  "billable": true,
  "fetched_at": "2026-10-06T12:21:28.042Z"
}

The same serial arrived a second time through TMview, so this lookup delivered two rows for the same mark: one per register that knows the file. Fields the register did not answer stay null rather than being dropped, so a schema diff between two runs is never a surprise.

itemCount and markCount count the full list the run produced. Diagnostic rows are delivered but never charged:

• a source: "none" placeholder when a search found nothing (still a successful run, so you can read source_status and tell which register said "not found")
• Nice class headings in mode: classes
• named stubs for closed national registers (UK IPO, INPI, DPMA, J-PlatPat, CIPO) when you asked for that office explicitly and no readable source had anything for it

Those rows carry billable: false. Real mark rows carry billable: true and are what the trademark charge event counts.

Pricing

Pay per event. One trademark event = one billable mark row delivered ($0.006 per mark row on the current pricing model). Placeholder rows, Nice headings and stubs are free. Empty results are free. A free run delivers at most 10 rows and charges at most 10 events; a paying run charges exactly the billable mark rows it delivered. There is no start fee and no platform surcharge in this actor's own charge map.

Use cases

• Trademark clearance search. Before a name is adopted, run the candidate word mark across every readable register, keep the live hits and read owner, nice_classes and goods_services next to each one. One run, one dataset, no per-office tab switching.
• Brand protection sweep. Search a word mark across the indexes, filter status_norm == "live", and keep status_raw for the lawyer's reading.
• Trademark status check. Look up the serial or registration number and read status_norm, owner, nice_classes and goods_services in one row per register that knows the file — plus status_date and publication_date for the timeline.
• Madrid international files. An IRN hits Madrid Monitor for the official action list (madrid_actions) and TMview for the mark wording the action list does not carry.
• Portfolio audit. Run a list of numbers with include_goods_services: true and diff the goods text and expiry dates against your own register.
• Nice class wording. mode: classes returns the official headings for the classes you name, without consulting any register.

How this trademark search compares

	this actor	a USPTO-only scraper	a single office's web form
sources	five readable registers in one run	one register	one office
offices	US plus the shared TMview index (dozens of offices, EM among them), WIPO Madrid, IP Australia, Global Brand DB	US only	that office
status	normalised plus the office's raw wording	office vocabulary only	office vocabulary only
closed offices	named stubs instead of silence	n/a	n/a
TMview search	one query, corroboration across offices	not covered	not covered
billing	per mark row, diagnostics free	varies	n/a
machine-readable	dataset rows + OUTPUT summary	dataset rows	HTML

Most of what the Store offers in this niche is a single-office scraper — a USPTO trademark scraper, an EUIPO scraper, an India scraper — each of which is the right tool for one jurisdiction. The gap is the cross-office question: does this mark conflict anywhere? That is one query here, and it is the reason the office field matters as much as mark.

A single-office form is still the right place to file. This trademark search is the right place to look, across offices, unattended.

FAQ

What is the difference between status_norm and status_raw?

status_norm is the three-way verdict a brand check acts on: live, dead or pending. status_raw is the office's own wording, kept verbatim, so nothing the register said is lost. USPTO rows keep the TM5 Common Status Descriptor; TMview and Brand DB rows keep Registered, Filed, Ended or Expired.

Why do I sometimes get a row with source: "none"?

The search ran and every readable register said it had nothing. The placeholder row carries the query and the per-source source_status map so you can see which registers were asked and which answered not_found. It is a successful run and it is not charged.

Which offices can this trademark search actually read?

US (TSDR), the shared TMview index (dozens of offices including EM), WIPO Madrid, IP Australia and the WIPO Global Brand DB. UK, France, Germany, Japan and Canada keep their national registers closed to unattended callers; their marks still arrive through the shared indexes, and a stub row names the closed office only when you asked for it explicitly and the indexes had nothing.

How is a trademark search run priced?

Per billable mark row. A billable row is a real mark from a register with a mark text, ST.13 id or registration number. The not-found placeholder, Nice class headings and closed-office stubs are free. Empty results are free.

Can I limit how many rows I get back?

Yes, with max_rows (per source, 1–500) and with offices / nice_classes filters. Free runs deliver at most 10 rows. Broad word searches are partitioned by filing-date window rather than cut off at the index ceiling, so max_rows is a real bound on what you receive.

Can I call this trademark search API from my own code?

Yes. Start a run through the Apify API with the same input object you would paste into the console, wait for it, then read the dataset items — that is the normal integration. The OUTPUT record in the key-value store carries the counts if you would rather not walk the rows. Input fields and defaults are the ones documented under Input, including the defaults Apify fills in for you.

Does a run that finds nothing fail?

No. Nothing found is a successful run with a placeholder row carrying source: "none" and the per-source source_status map, and it costs nothing. The same holds for a register that refuses to answer: you get the reason, not a red run.