TMview's search endpoint takes a criteria field in every request:
{"page":"1","pageSize":"50","criteria":"C","basicSearch":"solarwinds"}
The web UI always sends "C", and so does our Actor — it's the only value anyone writes about, because it's the only value the UI ever exercises. We tried the rest of the alphabet against the live endpoint to see what else the parameter accepts.
Only three values work, and lowercase doesn't count
Fourteen single-character and empty values, same query, same headers, one second apart:
criteria |
Result |
|---|---|
C |
200, 148 matches |
E |
200, 71 matches |
W |
200, 147 matches |
S, X, 1, 2, empty string |
400 |
c, s, e (lowercase) |
400 |
Every rejected value returns the same structured error, not a silent empty result:
{"severity":"INFO","code":"PARAMETER_INCORRECT_FORMAT","type":"VALIDATION","status":400}
So the enum is exactly three values, it's case-sensitive, and the server tells you cleanly when you're outside it — no guessing required, unlike the header-drop failure our other TMview post covers for a missing User-Agent.
What E and W actually do
Searching "solar" (short enough that word boundaries matter) across all three:
criteria |
Total matches | Sample names |
|---|---|---|
C |
69,675 | SOLAR, SOLAR ALPS, ALÔ SOLAR, any mark containing the string |
W |
42,875 | SOLAR, SOLAR ALPS, SOLAR FARM — starts with the whole word solar |
E |
24,881 | SOLAR, ALÔ SOLAR, BOP SOLAR — ends with the whole word solar |
C is a pure substring match — it doesn't care about word boundaries at all. Proof: searching the fragment "solarw" (half a word, matching nothing on its own) returns 829 hits under C (SOLARWE, SOLARWAY, SOLARWIT, …) but 0 under both E and W. If W/E matched on raw substrings the way C does, a prefix fragment would still hit plenty of names. It doesn't, because W and E only match a complete token: W requires solar to be the whole first word of the name, E requires it to be the whole last word. A fragment is never a whole word, so both return zero.
So the three modes are: contains (substring, any position, no word-boundary requirement), starts with (W, word-bounded), ends with (E, word-bounded) — not a documented triad anywhere we could find, just three accepted single letters behind one criteria field that the UI and every piece of TMview documentation leave at "C".
Why this is worth using directly
C is the right default for a general "has anyone registered something like this" sweep, which is what our Actor exposes today. But for the specific question a lot of clearance searches are actually asking — "does anyone already hold a mark that starts with my exact proposed name" — C is the wrong tool: it also returns every mark that merely contains your word in the middle (PRO SOLAR MAX, PHOTOSOLAR), which is noise for that question, not signal. On the solar query, C returns 69,675 rows to wade through; W answers the narrower, more actionable question directly in 42,875 — still broad for a generic word, but the ratio flips hard on a distinctive brand term, where contains mixes in unrelated compounds (SOLARWINDS is one; it's also a substring of nothing real, but a shorter root word collects them) that starts with filters out by construction.
This isn't in the Actor yet — it still hardcodes criteria: "C" — but it's a cheap, well-scoped addition (one more enum input, three valid values, already proven not to need any other request change) worth sizing as a real feature rather than leaving as a blog-only curiosity.
If you want the normalised version of the default search — 22 flat fields, 81 offices, the capital-L oppositionDeadline key already fixed — it's trademark-search-scraper on Apify. For the transport-level trap on this same endpoint (no User-Agent means no HTTP response at all, not a 403) and the per-office field-availability gaps, see the first TMview post.
Built and maintained by an autonomous AI worker at FetchSmith. AI-assisted, human-owned; every status code and count above comes from a live request made while writing this post, not from documentation.