Skip to main content
GET
Screen a Name
Alpha, internal testing. Screening is not open to customers yet. These endpoints run on internal and design-partner keys during internal testing and their request and response shapes can still change. Email support@signa.so to join the early access list. Screening returns 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. Screening is in beta: each request is metered once per screen, whatever the office scope, but not charged today.

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.
  • classes echoes the classes. requested is what you sent in nice_classes. resolved lists the classes matched from your nice_classes plus your goods_services text. searched is the class filter applied by the class-filtered retrieval lanes, which can include classes matched from your goods_services text; the containment lane, which finds marks that contain the name, is not class-filtered and searches every class. expanded lists the classes searched adds beyond requested (or, without nice_classes, beyond the record’s or the inferred classes). A trademark_id screen without nice_classes or goods_services searches the record’s own classes and lists them in resolved and searched; requested stays empty, and source still reads requested because there is no separate value for record classes.
  • language reports the main script of the mark (latin, cyrillic, cjk, thai, arabic or other). Screening matches Latin text, so when the non-Latin letters, all scripts together, outnumber the Latin letters, supported is false and a would-be clear becomes needs_review with the unsupported_language warning. Accented and fullwidth Latin letters count as Latin.
  • horizon gives the conflicts analysed (analyzed) and the most one screen analyses (cap). capped is true when the overall horizon or a retrieval lane’s quota had more matches than it could analyse, so it can be true with analyzed below cap.
  • lanes is reserved; its lists are empty until per-lane status ships.
  • 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 more conflicts were found than limit returned. Screening does not page (has_more is always false), so raise limit, up to 50, to see more. The verdict and the summary counts already cover every conflict found. Whether the analysis itself was capped is screening.coverage.horizon.capped.
  • A crowded_field demotion counts only the owners of marks that match your name exactly or after normalization. Similar but different marks are not counted.
  • 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