Skip to content

Getting Started Overview

This section helps partner engineering and product teams go from access request to production launch.

What you are integrating

The CheckName Partner API is Legiqo GmbH's B2B integration surface for Swiss company-name workflows.

It is not the consumer-facing experience at checkname.ch. That public product is designed for end users running searches directly, while this API is designed for partners embedding the capability into their own applications, onboarding flows, and internal tooling.

This API is not self-service. Access, pricing, and onboarding are handled individually for enterprise B2B partners via contact@legiqo.com.

Depending on your product, the API can support:

  • customer-facing onboarding flows
  • internal legal/compliance review desks
  • assisted filing and registry-preparation workflows
  • operational queues where risky names must be escalated

The core idea is:

  • POST /v1/name/assessment tells you how risky or acceptable a proposed name looks from a rules and policy perspective
  • POST /v1/name/screening bundles assessment, company conflict search, trademark search, and optional domain checks in one response
  • POST /v1/conflicts/search finds already registered Swiss company names that are identical or similar to the proposed name
  • POST /v1/trademarks/search screens for potentially similar registered trademarks in the ingested IGE dataset
  • issues[] and overallStatus let you turn the result into product behavior

For POST /v1/name/assessment, the underlying rules are aligned with the published Swiss company-name guidance used by the Federal Office of Justice / EHRA, especially the official document Anleitung und Weisung an die Handelsregisterbehörden für die Bildung und Prüfung von Firmen und Namen (1 April 2021).

Integration flow

  1. Commercial onboarding: contact contact@legiqo.com to discuss your use case, pricing, and rollout model.
  2. Access: receive API key(s) and environment URL(s) from Legiqo.
  3. Connectivity: run the quickstart requests and validate response handling.
  4. Business mapping: map risk levels and issues to your product decisions.
  5. Go-live: configure monitoring, retry behavior, and support escalation.

Typical request workflow

Typical flow:

  1. Assess whether the proposed name is acceptable enough to continue.
  2. If you want a single bundled response, call POST /v1/name/screening instead of orchestrating the follow-up checks yourself.
  3. If manual review is needed, make an explicit approval decision.
  4. Once the name is allowed to continue, always search for already registered identical or similar company names, either through screening or POST /v1/conflicts/search.

In the recommended filing-oriented workflow, company conflict screening should always run after the name is approved to continue, either through POST /v1/name/screening or through POST /v1/conflicts/search. The most important reason is to detect identityMatch: an already registered identical company name can still lead to rejection even if the assessment step did not stop the workflow.

1. Registrability assessment

flowchart TD
    A[Proposed company name] --> B[POST /v1/name/assessment]
    B --> C{overallStatus}

    C -->|REGISTRY_REJECTION_LIKELY| D[Stop or correct the name]
    C -->|MANUAL_REVIEW_ADVISED| E[Manual review]
    E --> F{Review decision}
    F -->|Approved| G[Continue to company name conflict check]
    F -->|Not approved| H[Stop or correct the name]
    C -->|CLEAR_TO_FILE or MINOR_RISKS_DETECTED| G[Continue to company name conflict check]

    classDef input fill:#EFF6FF,stroke:#2563EB,color:#0F172A,stroke-width:1.5px;
    classDef endpoint fill:#ECFDF5,stroke:#16A34A,color:#0F172A,stroke-width:1.5px;
    classDef decision fill:#F8FAFC,stroke:#64748B,color:#0F172A,stroke-width:1.5px;
    classDef stop fill:#FEF2F2,stroke:#DC2626,color:#7F1D1D,stroke-width:1.5px;
    classDef review fill:#FFF7ED,stroke:#EA580C,color:#9A3412,stroke-width:1.5px;
    classDef proceed fill:#EEF2FF,stroke:#4F46E5,color:#312E81,stroke-width:1.5px;

    class A input;
    class B endpoint;
    class C,F decision;
    class D,H stop;
    class E review;
    class G proceed;

2. Company name conflict check

flowchart TD
    A[Continue to company name conflict check] --> B[POST /v1/conflicts/search]
    B --> C{Conflict search result}

    C -->|identityMatch| D[Already registered identical name<br/>Can still lead to rejection or hard stop]
    C -->|similarMatches| E[Already registered similar names<br/>Warning, review, or later conflict risk]
    C -->|No relevant matches| F[Continue with normal workflow]

    classDef proceed fill:#EEF2FF,stroke:#4F46E5,color:#312E81,stroke-width:1.5px;
    classDef endpoint fill:#ECFDF5,stroke:#16A34A,color:#0F172A,stroke-width:1.5px;
    classDef decision fill:#F8FAFC,stroke:#64748B,color:#0F172A,stroke-width:1.5px;
    classDef stop fill:#FEF2F2,stroke:#DC2626,color:#7F1D1D,stroke-width:1.5px;
    classDef review fill:#FFF7ED,stroke:#EA580C,color:#9A3412,stroke-width:1.5px;
    classDef success fill:#ECFDF5,stroke:#16A34A,color:#14532D,stroke-width:1.5px;

    class A proceed;
    class B endpoint;
    class C decision;
    class D stop;
    class E review;
    class F success;
  1. Integrate /v1/name/assessment as your primary decision endpoint.
  2. Add /v1/name/screening when you want the API to orchestrate assessment, company conflicts, trademark screening, and optional domains in one call.
  3. Add /v1/conflicts/search and /v1/trademarks/search directly when you need raw sub-check outputs or custom orchestration.
  4. Use /v1/name/eligibility, /v2/name/eligibility, or /v3/name/eligibility only for legacy compatibility during migration.

In most partner implementations:

  • CLEAR_TO_FILE means the workflow can proceed automatically
  • MINOR_RISKS_DETECTED means proceed with user/operator warning
  • MANUAL_REVIEW_ADVISED means route to compliance/legal/manual queue
  • REGISTRY_REJECTION_LIKELY means block, require correction, or escalate

This mapping is not imposed by the API, but it is the intended integration pattern for most operational use cases.

Choosing a risk profile

riskProfile lets you choose how aggressively the API maps triggered issues into final severity.

Available profiles:

  • balanced: default and recommended for most production partner integrations
  • conservative: stricter handling for partners who want borderline names escalated sooner
  • relaxed: softer handling for early-stage intake flows or exploratory checks

Important: the profile does not change which checks run. It changes how triggered issues are classified, which can change overallStatus.

In the current API version, the practical profile difference is mainly how WARN_PURELY_DESCRIPTIVE is treated:

  • balanced: mapped to WARNING, which usually results in MANUAL_REVIEW_ADVISED
  • conservative: mapped to ERROR, which usually results in REGISTRY_REJECTION_LIKELY
  • relaxed: mapped to INFO, which usually results in MINOR_RISKS_DETECTED

If you are unsure which profile to start with, use balanced.

Deprecation

POST /v1/name/eligibility, POST /v2/name/eligibility, and POST /v3/name/eligibility are deprecated and should not be used for new builds. POST /v1/name/assessment is the replacement endpoint for partner decisioning.

Security baseline

  • Keep API keys in your secret manager only.
  • Never ship keys in client-side code.
  • Rotate keys on employee role changes and incident response.

Use of the partner API is subject to Legiqo's Terms and Conditions, unless your signed partner agreement or order form defines superseding terms.

For enterprise access, pricing, and onboarding questions, contact contact@legiqo.com.