Skip to main content
GET
Screen a Name
Beta. Requires the screening:read scope — granted to design partners during beta. This endpoint provides a risk signal, not legal advice.

Overview

GET /v1/screening answers “could this candidate name conflict with an existing mark?” Send a name and, optionally, its intended Nice classes or goods/services. Screening searches live register coverage, assigns each surfaced conflict a coarse band, and derives one request-level verdict. The endpoint is synchronous, deterministic within its rules and corpus versions, and text-only. It never returns a numeric similarity score. A clear verdict means that no high- or medium-band conflict was found; it does not mean that the mark is registrable. Each request is billed at 10 units.

Request

Array query parameters use comma-separated values, without brackets.

Screen an existing mark

Use trademark_id instead of q for register-to-register discovery. Screening uses the record’s mark text and, when you omit both nice_classes and goods_services, its own Nice classes as the intended-use profile. The candidate’s collapsed family is removed before conflicts are banded, so it cannot appear as its own result.
The response echoes the source in screening.candidate.trademark_id. Unknown records return 404 not_found; records without textual mark content, such as design-only marks, return 422 not_screenable.

Bands and verdicts

Every item in data[] is a screening_hit with one closed risk band: The leading screening.verdict summarizes the full banded result set, not only the returned page: Found conflicts always band high or medium regardless of coverage: observed risk is never suppressed. The coverage gate only ever downgrades a would-be clear, it never upgrades a genuine conflict. Treat needs_review as “we could not rule this out”, not as a weaker clear. Hits also explain the coarse classification through reason_codes, mark_match, goods_services_match, jurisdiction_match, and a separate litigation_risk block. Reason codes and warnings are extensible; clients should tolerate values they do not yet recognize.

Coverage

A clearance verdict for a territory is only as trustworthy as the registers Signa can actually see there. If the national register that protects a requested territory is not connected live (for example a request scoped to DE when the German national register is dark), national-only marks in that territory are invisible, so a zero-conflict screen must not read as clear. The screening.coverage block reports exactly which registers gated the verdict.
This example is abridged to the coverage-gate axes. The served coverage object also always includes classes, lanes, language, and horizon, the other completeness inputs that can hold a verdict at needs_review.
  • offices is the register-freshness axis. Each entry is a public office code in WIPO ST.3 form (US, EM for the EUIPO), with a status (complete / partial / stale / unavailable) and an as_of corpus watermark. It lists the offices that gated this verdict: the requested offices when offices was supplied, the national plus regional and member registers when jurisdictions was supplied, or every live office when the request is unscoped.
  • territories is the protection-scope axis, present when jurisdictions was supplied. Codes here are jurisdiction codes (DE, EU), not ST.3 office codes. For each requested territory it reports its own national_register, the regional_registers that also protect there (a country belonging to EU shows an EU entry), and whether the whole set is complete.
  • For a regional request (jurisdictions=EU) a territory entry adds member_registers: { total, uncovered[] }, summarizing how many member-state national registers are dark; regional_registers is still present but empty (the region is its own register). An EU screen stays needs_review while member registers are uncovered, and flips to clear only once they are live and fresh, the same principle as the DE example.
  • complete_for_clear is the single boolean the verdict gate reads. When it is false, a would-be clear is downgraded to needs_review and screening.note names the dark register. coverage is present on every screened response. When the coverage assessment itself cannot be completed, the block fails closed with complete_for_clear: false and an empty offices, which signals that coverage could not be verified and forces the verdict to needs_review.

Response

screening.rules_version and screening.as_of identify the rules and corpus freshness behind the result. screening.inferred_nice_classes appears only when class inference ran (i.e. nice_classes was omitted from the request).

Warnings and limitations

  • warnings is an open set. Handle known values and safely display or log new values rather than rejecting the response.
  • A missing goods/services description may produce no_goods_services; the result then has less context for class and goods/services matching.
  • summary.truncated: true means the analysis horizon was capped. It is separate from has_more, which describes response pagination.
  • Screening v1 is text-only. It does not compare logos, designs, Vienna codes, or images.
  • Backend failures return an error rather than a partial or false clear.
  • Screening responses are served Cache-Control: private, no-store. A screening result reflects live register coverage at request time, so it is not safe to cache client-side, re-run the screen rather than replaying a stored response.

SDK