Skip to main content
POST
Check a Listing
Beta. Requires the screening:read scope — granted to design partners during beta. Not legal advice.
Known limitation (beta). The current build over-flags listings that contain common dictionary words, so it returns caution for the large majority of ordinary listings. A verdict-separation redesign is in progress to restore precision. Until it lands, treat a caution verdict as no-signal, not evidence of risk, and do not rely on the endpoint for automated enforcement decisions. Real-world validation against the full production register superseded the earlier precision numbers measured on a small synthetic test index.

Overview

POST /v1/screening/listings answers “is this LISTING risky?” — one level up from screening a name. You send the commerce text of a product listing (title, brand, description, keywords) and it:
  1. Extracts candidate marks deterministically (no LLM at request time), with provenance (source field + character span per candidate).
  2. Fans out each candidate through the screening core.
  3. Aggregates to one listing-level verdict (clear / caution / high_risk), deduplicating conflicts across candidates.
Billed flat at 25 units per checked listing, regardless of internal fan-out.

Request

Only title is required. Fields are generic — there are no marketplace-specific fields (Etsy/Amazon mappings live in docs recipes, not the schema).

Response

A bespoke envelope: a leading listing decision block, an evidence-first matches[] payload, the back-compatible data[] of listing_candidate (each conflict is byte-identical to a screening hit), and a trailing suppressed[] audit list explaining why candidates were not screened.

Reading the result

analysis_status is a closed completeness enum and is orthogonal to the tri-state verdict. Automated approval must key off auto_approve_eligible (equivalent to verdict === "clear" and analysis_status === "complete") and must not use verdict alone. Incomplete or unsupported analysis is never auto-approvable. class_provenance explains where the class set came from; provided_unverified means the caller supplied it and Signa has not verified it against a platform taxonomy. resolved_nice_classes is the listing-level set actually screened. dictionaries_version and decision_asset_version make the deterministic decision assets auditable. There is no public risk_score. The GA scope is English-only. When the title and brand are majority non-Latin (CJK, Thai, Arabic, or Cyrillic), the endpoint returns analysis_status: "unsupported_language", floors the verdict to caution, and does not run the text through English screening.

Safety guarantees

  • Never a false clear. Any search-backend error → 503 (never a partial “clear”). If the candidate budget is exceeded, the listing can never be clear — it is forced to caution with a candidate_budget_capped warning.
  • Coverage-gated clear. A would-be clear is forced to caution (with an incomplete_office_coverage warning) when a requested territory’s register is not covered live in Signa, on the same protection-scope basis as Screen a Name. The listing verdict enum stays clear / caution / high_risk, so the incomplete-coverage case surfaces as caution here rather than a distinct verdict.
  • Informational-only conflicts. A tier-S identical name in an unrelated class (e.g. a famous word used descriptively) is surfaced with "informational": true but does not escalate the listing verdict.

SDK