Trademark Search Integration Guide

Use POST /v1/trademarks/search to screen a proposed sign against registered trademarks in the ingested IGE dataset.

This guide explains how partner applications and internal review tools can consume trademark matches as an additional screening signal.

Suggested UX flow

1. User or operator provides the proposed brand/sign.
2. Backend calls POST /v1/trademarks/search.
3. If known, include intended niceClasses so goods/services overlap can influence ranking.
4. UI displays candidate marks grouped by risk, with matching reasons and class context.
5. Legal or operations reviewers decide whether follow-up review is needed.

What to show in the UI

• the normalized input echo from input
• the matched trademark text and registration identifiers
• risk as the first-level routing signal
• matchBasis[] as human-readable explainability support
• classOverlap and relatedClassOverlap when Nice classes matter to the workflow

Decision mapping example

• High: escalate to legal or trademark review before continuing.
• Medium: continue only with explicit operator visibility or case-note capture.
• Low: advisory signal only, unless your business policy requires broader review.

Implementation tips

• Treat this endpoint as screening support, not as a legal clearance opinion.
• Provide niceClasses whenever your workflow knows the intended goods/services scope.
• Persist match snapshots if analysts need an audit trail.
• Combine trademark search with POST /v1/name/assessment and POST /v1/conflicts/search rather than replacing either one.