Skip to content

API Reference Overview

Legiqo GmbH's CheckName Partner API exposes one lean primary decision endpoint, one convenience orchestration endpoint, and supporting endpoints for B2B integrations:

  • POST /v1/name/assessment
  • POST /v1/name/screening
  • GET /v1/name/screening/catalog
  • POST /v1/conflicts/search
  • POST /v1/trademarks/search
  • POST /v1/name/eligibility (deprecated)
  • POST /v2/name/eligibility (deprecated)
  • POST /v3/name/eligibility (deprecated)

Endpoint roles in the business workflow

These endpoints do different jobs and should not be treated as interchangeable:

Endpoint Main purpose Best used when
POST /v1/name/assessment Return a business-ready risk outcome for a proposed name You need the lean primary decision API with the simplest response semantics
POST /v1/name/screening Run assessment, company conflict search, trademark screening, and optional domain checks in one call You want a convenience orchestration endpoint for one-call B2B screening
GET /v1/name/screening/catalog Return stable screening codes, enum values, and English fallback descriptions You want to build or refresh frontend copy/routing maps for screening responses
POST /v1/conflicts/search Find already registered Swiss company names that are identical or similar to the proposed name You want to identify registered names that may conflict with the proposed name
POST /v1/trademarks/search Screen for potentially similar registered trademarks in the ingested IGE dataset You want an additional brand/trademark signal before filing, legal review, or customer handoff
POST /v1/name/eligibility, POST /v2/name/eligibility, POST /v3/name/eligibility Legacy eligibility-style outputs only You are temporarily supporting an older integration during migration to POST /v1/name/assessment

This reference documents the integration API, not the end-user workflow at checkname.ch. If you are building a partner product or internal tool, this is the surface you integrate against.

Primary endpoint semantics

  • POST /v1/name/assessment is the main endpoint for partner integrations.
  • POST /v1/name/screening is the convenience endpoint for partners who want one bundled screening call.
  • GET /v1/name/screening/catalog is the discovery endpoint for stable screening response codes and enums.
  • POST /v1/name/eligibility, POST /v2/name/eligibility, and POST /v3/name/eligibility are deprecated and replaced by POST /v1/name/assessment.
  • HTTP 200 means the assessment executed successfully.
  • Business decision outcome is in top-level overallStatus:
  • CLEAR_TO_FILE
  • MINOR_RISKS_DETECTED
  • MANUAL_REVIEW_ADVISED
  • REGISTRY_REJECTION_LIKELY
  • Persist traceId for support/debug correlation.
  • X-Trace-Id mirrors the same identifier in response headers for header-oriented infrastructure.

What POST /v1/name/assessment actually does

At a functional level, the assessment endpoint combines several layers into one response:

  1. Deterministic naming checks for syntax, legal form, geographic wording, and restricted terms.
  2. Optional semantic analysis when checkLevel=full to interpret descriptiveness, purpose mismatch, translations, and implied regulated activity.
  3. Risk-profile mapping that converts triggered rule codes into INFO / WARNING / ERROR severities.
  4. Final aggregation into one top-level outcome in overallStatus.

This means the assessment endpoint is intended to be your operational "decision engine", not just a rule dump.

What POST /v1/name/screening actually does

The screening endpoint is the orchestration layer for partners who prefer one call instead of coordinating multiple endpoint calls in their own backend.

By default it bundles:

  1. company name assessment
  2. company conflict search
  3. trademark search

It can also include optional domain availability checks when explicitly requested.

The response is now decision-first:

  1. overallStatus is the main filing-oriented business outcome.
  2. resultState tells you whether all requested checks completed.
  3. drivers[] explains which checks materially influenced the outcome.
  4. primaryConcern gives one strongest issue for simple UIs and routing logic.
  5. details contains compact supporting detail for completed checks, including risk-tier counts and truncated top matches.

This endpoint is best thought of as a bundled decision API, not as a raw passthrough of four underlying endpoint responses. Keep using POST /v1/name/assessment when you want the leanest primary decision API with the smallest contract surface.

What GET /v1/name/screening/catalog actually does

The catalog endpoint returns the stable machine-readable values used by POST /v1/name/screening:

  • assessment issue codes with default severity, category, and English fallback descriptions
  • screening driver codes with source, default severity, and English fallback descriptions
  • status, action, check-state, risk, and error-code enum values

Partner UIs should use codes and enum values as routing and copy keys. API message fields are English fallback/debug copy only; localized German customer-facing text should come from your own code-to-copy mapping.

What POST /v1/conflicts/search actually does

The conflict-search endpoint is designed to answer a different question: which already registered Swiss company names are identical or similar to the proposed name.

It evaluates similarity using multiple signals, including:

  • identity or near-identity
  • visual similarity
  • phonetic similarity
  • subset and token overlap logic

Use it when you need to identify already registered names that may create confusion or filing risk, whether for customer-facing flows or internal review.

What POST /v1/trademarks/search actually does

The trademark-search endpoint answers a separate brand-screening question: which registered trademarks in the ingested IGE dataset look textually or phonetically similar to the proposed mark.

It evaluates candidate matches using multiple deterministic signals, including:

  • normalized text similarity
  • phonetic similarity
  • token/subset structure
  • optional Nice-class overlap or curated related-class proximity

Use it when you want a trademark-oriented screening step in addition to company-name assessment and company conflict search.

Response model philosophy

For partner integrations, it helps to separate three layers of meaning:

  • transport success: HTTP status and error.code
  • business outcome: overallStatus
  • exact machine triggers: issues[].code, drivers[].code, and catalog values

That separation lets you distinguish "the API call failed", from "the API worked but the name is risky", from "here are the precise reasons why".

Versioning

  • Paths are versioned under /v1.
  • Breaking changes are announced through the changelog and partner communication channel.

Content type

  • Request: application/json
  • Response: application/json

Authentication

All endpoints require X-API-Key.