Daily US trademark application leads and register search from USPTO: new filings 1-2 days after filing, or search by mark text or owner name. Owner name & address, attorney, correspondent email & phone, pro-se flag, classes and goods — for IP law firms and brand protection. No key required.
0.1.13 — 2026-10-08 — README: the Python example works with the current Apify client
The README's Python example read the results with run['defaultDatasetId']. With the current Apify client for Python (version 3) call() returns a run object, not a dict, and that line raised TypeError: 'Run' object is not subscriptable — after the run itself had finished. The example now reads run.default_dataset_id; with client version 1 or 2, keep run['defaultDatasetId']. Checked with apify-client 3.2.1, 2.5.1 and 1.12.2.
No code, output field or pricing change.
0.1.12 — 2026-10-07 — a run that Apify starts again keeps to maxResults
A run that the platform starts again no longer writes past maxResults or repeats rows. Apify can move a run to another server while it is going (or reboot it); the Actor then starts again with the same run ID and the same dataset. Until now it started counting from zero and did not know which leads it had already written. Measured on 0.1.11: a run with maxResults 30 that was rebooted after 14 rows ended with 44 rows, 4 of them written twice, 44 leads charged, and the status message "30 trademark leads delivered" (run JNjmLfiKbgXSZfqNZ). In the modes without onlyNewSinceLastRun the run started from the top again, so up to maxResults rows could come twice.
The Actor now first reads what its own dataset already holds: those leads count towards maxResults, are not fetched or written again, and the status message counts them. All four modes. A run that was not started again reads an empty dataset and behaves as before.
No output field changed, no pricing change.
0.1.11 — 2026-10-07 — fresh filings again, and search by mark text or owner name
Build 0.1.10 was a test build of this release and was never published; what its tests turned up is part of this one.
New filings mode returns new filings again. Since about 20 July 2026 it had been returning the same filings of that date as "the freshest" (a run on 2026-10-06 still said "Freshest published filing date right now: 2026-07-20", run zl8oqf2cCzy69C9Ey). The cause: USPTO changed how it numbers applications — a new 50… series since 18 July 2026, and 99… numbers that are no longer in filing order — while the Actor found new filings by walking down from the highest serial number.
The list of applications now comes, by filing date, from the search service behind USPTO's own trademark search page; the contact details are read from each application's status page as before. Measured on 2026-10-06: the filings of 5 October were available (1,779 that day, 627 of them without an attorney), and a run no longer starts by spending about two minutes looking for the newest serial number.
New: Search mode ("mode":"search") — find applications anywhere in the register by markText and/or ownerName. Every word must match; results come newest first. The README had promised this since September without the Actor doing it.
New filters for New filings and Search: intlClasses (Nice classes) and liveOnly. markText and ownerName also narrow the New filings feed.
Behaviour change — onlyNewSinceLastRun: the Actor now remembers the filings it has delivered (per set of filters) and looks back 14 days on every run. Each filing is delivered once; whatever a run does not get to — Max results, a time limit, your spending limit — comes with the next run. The first runs of a new feed therefore work back through the last 14 days before they are down to only the newest filings. The marker of 0.1.9 and earlier is no longer read.
onlyNewSinceLastRun — the memory is written while the run goes (every 10 leads), when the run ends and when Apify asks it to stop (a graceful abort; the lead being written is finished first). Each write first takes in what is stored, so one run cannot wipe out what another wrote. A run that is killed without warning — an immediate abort, a crash — can repeat at most its last 10 leads in the next run.
onlyNewSinceLastRun — one run per feed at a time. Two runs of the same feed (same filters) at once go down the same list and deliver the same leads: on test build 0.1.10 a 5-lead run started while a 300-lead run of the same feed was still going, and delivered that run's first five leads again (runs qkDX5EREvuR0puZgL and bOuLcBHe43L8jLFac). A run now marks its feed as taken; a second run that starts meanwhile ends at once with the status message "Nothing delivered: another run of this same feed is in progress …", without delivering anything or contacting USPTO. The mark of a run that was killed stops counting after three minutes. Feeds with different filters do not affect each other, and runs without onlyNewSinceLastRun are not affected.
Mark text matching is USPTO's own. A search for canopy in class 28 returned four marks, one of them KANOPEO (run BsFfoJhDAm56bbK0w): the index also returns some marks that are spelled differently. The input description and the README now say so instead of "words that must all appear in the mark".
Behaviour change — pro-se filter: it is applied when the list is made (no attorney on the record), so the run no longer spends requests on applications that have one. The status page still has the last word: an application that turns out to have an attorney there is left out.
Behaviour change — "Freshest": it means the filings of the last 14 days. A filing appears one to two days after it is filed, not seven to ten as the Actor's texts said for the old method.
If USPTO's search service does not answer (it is not a documented API and sits behind a firewall), the run ends with a message that says so. Rows already delivered are kept; a run that delivered nothing ends as failed, because the cause is not in your input. The Actor does not try to get around a browser check. Serial number modes do not use the search service.
serialFrom / serialTo accept the 50… series.
The Actor's title and description now mention search.
No output field changed, no pricing change.
0.1.9 — 2026-10-07 — a run that is cut short stops cleanly, says why, and the next one carries on
A run that reaches its maximum charge now stops by itself and tells you. The maximum charge is the limit you set for the run, or else what is left of your monthly usage limit. Until now the Actor did not look at it. Measured on 0.1.8 with a limit that covered 3 leads: the scan went on through all 10 serials and logged "Pushed 10", only 4 leads were in the dataset, and nothing in the run said that leads were missing (run HcgcBFpcba9LeWBTD). A longer scan — 60 serials, same limit — was aborted by Apify after 56 seconds (run Sdbfd82LdDVgYF0do).
Now the Actor checks the room left before every USPTO request. When there is none it stops the scan and finishes as a normal run with the status message "N trademark leads delivered — stopped because the maximum charge for this run (or what is left of your monthly usage limit) was reached. To get the rest, raise the limit and run again — …". A run whose limit does not cover a single lead ends at once, without sending a request to USPTO.
onlyNewSinceLastRun: a cut-short run no longer loses the rest of its batch. Before, a run that stopped early — at maxResults or on the time budget — still moved the "already fetched" marker to the newest filing, so the filings it had not reached were never delivered by any later run. Now a run that stops early for any reason (maxResults, time, maximum charge) saves the part it did not reach, and the next incremental run continues with it after the new filings. Nothing is skipped and nothing is delivered twice. If more than 5,000 serial numbers pile up this way (about two filing days), the oldest are let go and the log says so.
Behaviour change for scheduled feeds: a daily run with onlyNewSinceLastRun and a maxResults smaller than the day's filings used to return only the freshest part of each day. It now also works through what earlier runs left over whenever it has room, so a run can return filings older than the previous run's newest one.
The time limits hold. The Actor stops 30 seconds before the run timeout instead of being cut off by it, and maxRunSeconds now also covers the first step, locating the newest filing (it did not: a slow source could run past the budget there).
Every run ends with a status message that says what was delivered and, for a partial run, why it stopped and what the next run will do. An empty run says so instead of ending silently.
A custom filing-date range (a backfill) no longer moves the onlyNewSinceLastRun marker.
No output field changed, no pricing change.
0.1.8 — 2026-09-20 — README examples corrected against the real input schema
The README's code examples did not match this Actor. They used queries and maxResultsPerQuery — keys that do not exist in this Actor's input schema — with a placeholder value, and the input table listed those same phantom fields. Anyone who copied the AI-agent, cURL, JavaScript or Python example got a failing run. Every example now uses the real schema and matches the Console prefill: {"mode":"new_filings","maxResults":20}
The input table is regenerated from input_schema.json, so it lists the fields the Actor actually accepts.
Removed claims carried over from the same generator template where present: "formation / status monitoring", "a canonical registry record for KYB and due diligence", "every row carries query", and industry described as a NACE code.
No code, output field or pricing change.
0.1 — 2026-09-07
Enabled AI-agent payments (x402) + rebuilt the README to the full standard (What-is / when, AI-agents + x402 agentic payments + MCP, Overview, Features, Use cases, Integration, FAQ, Troubleshooting, Support & contact).
0.0
Initial release: data from the USPTO trademark database (official open data) by name or registry ID.
![✨Leads Finder - $1.5/1k leads with Emails [Apollo Alternative] avatar](https://images.apifyusercontent.com/hQh95d2BMIK4aiNBVTAopmRKraOLFaDFmflsEsCTEKM/rs:fill:76:76/cb:1/aHR0cHM6Ly9hcGlmeS1pbWFnZS11cGxvYWRzLXByb2QuczMudXMtZWFzdC0xLmFtYXpvbmF3cy5jb20vaUpPU0hXZDl4ZmFoRzBTWm0tYWN0b3ItSW9TSHF3VFI5WUdoemNjZXotYmdMcjdPbmo0Qy1jb21wYW55X3NjcmFwZXIucG5n.webp){kind=avatar}
