This post is the reference side of trademark screening: the endpoints, the parameters and the fields. The step-by-step workflow for a seller checking a name is in checking trademarks before you list.
One limit applies to everything below: an API search is screening, not clearance. It returns database records. It does not judge whether two marks are confusingly similar, and it does not replace a trademark attorney or agent.
Four endpoints
| Endpoint | Path | What it does |
|---|---|---|
| Data coverage | /v1/global/brand/range | Lists the office codes the data uses |
| Trademark search | /v1/global/brand/list | Finds records by text, with filters |
| Trademark details | /v1/global/brand/detail | Returns one record in full, by its id |
| Trademark statistics | /v1/global/brand/stats | Counts matching records by office, status, class and more |
Each successful call uses one billing unit.
Office codes
Every query is scoped by office. Codes are mostly two-letter country codes, with a few that are not countries:
| Code | Office |
|---|---|
US, JP, GB, DE, CA, AU … | National offices |
EM | The European Union |
WO | International registrations administered by WIPO |
The coverage endpoint returned about 250 codes when we called it on 12 October 2026. Two things to know about that list:
- A listed code is not a statement about completeness. It tells you the code is valid, not how current or complete that office's records are. Test an office with a mark you already know before you rely on it.
officeLabelcomes back in Chinese. Use theofficecode in your own code and UI.
For a seller, the offices that matter are the ones behind the marketplaces you sell in. A name can be free in US and taken in EM.
Search filters
text is the only required parameter. Everything else narrows the result:
| Parameter | Type | Use |
|---|---|---|
text | String | The words to search for |
office | Array | One or more office codes |
status | Array | Record status, such as Registered or Pending |
niceClass | Array | Goods and services classes, as numbers |
applicant | Array | Who filed |
brandName | Array | An exact mark name |
applicationYear, expiryYear | Array | Years, as strings |
order | Object | field and desc |
returnFields | String | Comma-separated fields to return, to keep the payload small |
page, size | Integer | Paging |
curl --request POST \
--url https://ecommercedataapi.com/v1/global/brand/list \
--header "Content-Type: application/json" \
--header "X-API-Key: ${ECOMMERCE_DATA_API_KEY}" \
--data '{
"office": ["US", "EM"],
"text": "AURORA",
"status": ["Registered", "Pending"],
"niceClass": [11],
"page": 1,
"size": 20
}'The search also accepts an image as imageBase64. We have not tested it for this post, so try it on a logo you know before relying on it.
Why status needs more than one value
Count first, then search. The statistics endpoint shows how records split before you page through them:
curl --request POST \
--url https://ecommercedataapi.com/v1/global/brand/stats \
--header "Content-Type: application/json" \
--header "X-API-Key: ${ECOMMERCE_DATA_API_KEY}" \
--data '{
"office": ["US", "EM", "JP"],
"text": "AURORA",
"returnFields": "office,status,niceClass"
}'On 12 October 2026 that request returned 2,679 records:
| By office | Count | By status | Count |
|---|---|---|---|
US | 2,063 | Ended | 1,419 |
EM | 391 | Registered | 897 |
JP | 225 | Pending | 227 |
Expired | 136 |
Two readings follow from one call:
- More than half the records are dead (
EndedorExpired). A raw hit count overstates the obstacle. - Filtering on
Registeredalone hides 227 pending applications. A pending application can become a registration, so a first pass should include it.
Reading a record
| Field | Meaning |
|---|---|
id | The record identifier. Pass it as brandId to the details endpoint |
brandName | The mark text |
applicant, applicantCountryCode | Who filed, and from where |
applicationDate, applicationNumber | When it was filed and under what number |
registrationNumber | Present once registered |
status, statusDate | Current status and when it last changed |
niceClass | The classes the mark covers |
markFeature | The kind of mark, such as Combined for words plus a design |
office, designatedCountries | The office, and for international registrations the countries designated |
The details endpoint adds the goods and services descriptions, the event history and the expiry date for one record. The class numbers are explained in trademark classes for Amazon sellers.
What the API does not do
It does not judge similarity. A text search finds matching words. Marks can conflict on sound, appearance or meaning without sharing spelling.
It does not assess class conflict. It reports which classes a record covers. Whether your goods conflict is a legal question.
It lags the offices. Publication and data entry take time, so a recent filing may not appear yet.
It is not a marketplace brand registry. Amazon's brand registry has its own requirements.
Questions
Is this an official trademark office API? No. It is a search over records from many offices through one interface. Each office also runs its own search tool, which remains the authority for its register.
How many calls does one name take? One statistics call to see the spread, one search per set of filters, and one details call per record you open.
Can I search several offices at once?
Yes. office is an array.
Where does this fit among Amazon-related APIs? It is one of the endpoint groups listed in Amazon APIs explained, alongside products, keywords and markets.