Skip to content

Integration Guides Overview

Use the integration guides in this order:

  1. POST /v1/name/assessment as the primary decision endpoint.
  2. POST /v1/name/screening when you want one bundled assessment, conflict, trademark, and optional domain response.
  3. POST /v1/conflicts/search when you want to identify already registered Swiss company names that are identical or similar.
  4. POST /v1/trademarks/search when you want an additional trademark-oriented screening step.
  5. Legacy eligibility endpoints only when migrating older integrations.

In most partner integrations, the endpoints relate to each other like this:

Endpoint Role in the workflow Main question it answers When to use it
POST /v1/name/assessment Primary decision endpoint Does this proposed company name look likely acceptable or risky under Swiss company-name rules and EHRA-oriented review logic? Use first and use by default in new integrations
POST /v1/name/screening Bundled screening endpoint What is the overall screening outcome across assessment, company conflicts, trademark signals, and optional domain checks? Use when you want breadth in one request instead of orchestrating sub-checks yourself
POST /v1/conflicts/search Company name conflict check endpoint Are there already registered Swiss companies with identical or similar names? Use when you want to identify already registered identical or similar company names
POST /v1/trademarks/search Trademark screening endpoint Are there registered trademarks in the IGE dataset that may be similar enough to require review? Use when you want a brand/trademark signal in addition to company-name checks
POST /v1/name/eligibility and legacy versions Migration-only endpoint How did older integrations consume compliance-style output? Use only while migrating legacy clients to assessment

Typical workflow diagram

Typical flow:

  1. Assess whether the proposed name is acceptable enough to continue.
  2. Use POST /v1/name/screening when you prefer one bundled call for assessment, company conflicts, trademark search, and optional domains.
  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;

This is a typical partner workflow, not a technical API requirement. POST /v1/name/assessment remains the primary decision endpoint, but once a name is allowed to continue, the recommended next step is company conflict screening through either POST /v1/name/screening or POST /v1/conflicts/search, especially to detect already registered identical names that can still lead to rejection.

How the endpoints work together

  1. Your system sends the proposed name to POST /v1/name/assessment.
  2. Use overallStatus and issues[] as the main product decision signal.
  3. If your integration wants one bundled response, call POST /v1/name/screening and read overallStatus, resultState, drivers[], and details.
  4. If you orchestrate checks yourself, call POST /v1/conflicts/search to check for already registered identical names and other similar registered names.
  5. Treat identityMatch as a critical follow-up signal, because an identical registered name can still lead to rejection.
  6. Use conflict and trademark search results as supporting evidence, not as the replacement for assessment.
  7. Keep legacy eligibility endpoints only if you are migrating an older integration that still depends on them.

In other words:

  • POST /v1/name/assessment evaluates the proposed name against Swiss company-name rules and EHRA-oriented review logic, then returns the main decision signal for your workflow
  • POST /v1/name/screening bundles assessment, company conflict search, trademark search, and optional domains into one decision-first response
  • POST /v1/conflicts/search identifies already registered Swiss company names that are identical or similar and may require warning or review
  • legacy eligibility endpoints exist only for backward compatibility

How to use the guides

1. Name Assessment

Start with POST /v1/name/assessment.

This is the main endpoint for most partner integrations. It turns a proposed name into a business decision signal using machine-readable statuses and flags.

Use it when you need to answer:

  • does this name look acceptable enough to continue the workflow
  • should the case be warned, reviewed, or blocked
  • which exact rule findings should drive product behavior

2. Bundled Screening

Use POST /v1/name/screening first when you want CheckName to coordinate the common assessment, conflict, trademark, and optional domain checks in one request.

This endpoint returns a decision-first response with compact supporting detail. Use top-level overallStatus for workflow routing, resultState for execution completeness, and drivers[] / primaryConcern for the material reasons behind the result.

Add POST /v1/conflicts/search when you want to identify already registered Swiss company names that are identical or similar.

This endpoint complements assessment. It does not replace the primary decisioning model in POST /v1/name/assessment.

Use it when you need to answer:

  • are there existing names that look identical or confusingly similar
  • should an operator review potential conflicts before filing or submission
  • which matching companies should be displayed to users or analysts

Add POST /v1/trademarks/search when you want to screen a proposed sign against registered trademarks in the ingested IGE dataset.

This endpoint complements both assessment and company conflict search. It is best treated as an additional legal or brand-review signal, not as a replacement for company-name decisioning.

Use it when you need to answer:

  • are there potentially similar registered marks that deserve trademark review
  • does intended Nice-class context strengthen or weaken the concern
  • which trademark matches should be shown to analysts or stored in the case file

5. Legacy Eligibility

POST /v1/name/eligibility, POST /v2/name/eligibility, and POST /v3/name/eligibility are deprecated.

Use these endpoints only to support older client integrations during migration to POST /v1/name/assessment.