Skip to content

Quickstart

This quickstart verifies end-to-end connectivity and payload handling for a backend partner integration.

Use it to confirm that your system can authenticate, send assessment requests, and interpret the decision-oriented response model exposed by Legiqo's CheckName Partner API.

1) Send the main assessment request

curl -X POST "https://api.test.checkname.ch/v1/name/assessment" \
  -H "X-API-Key: <your-api-key>" \
  -H "Content-Type: application/json" \
  -d '{
    "companyName": "Alpen Data AG",
    "legalForm": "stock_corporation",
    "activityScope": "Software development services",
    "language": "de",
    "ownerSurname": null,
    "legalSeat": "Zurich",
    "languageVariants": [],
    "checkLevel": "full",
    "riskProfile": "balanced"
  }'

Confirm all of the following:

  • HTTP 200 OK
  • overallStatus is present and parsed by your client
  • Use issues[].code and issues[].severity for deterministic client behavior
  • Treat message fields as English fallback/debug copy; use your own localized UI copy keyed by code
  • Persist traceId as the canonical support identifier
  • If you log response headers, also record X-Trace-Id, which mirrors the same value
  • Your client can distinguish transport success from business outcome

riskProfile controls how triggered issues are mapped into final severity:

  • balanced is the default
  • conservative is stricter
  • relaxed is more permissive

See API Reference > Assessment Checks and Codes for the exact current differences.

2) Bundled screening

If your integration wants CheckName to coordinate the common follow-up checks, validate the bundled screening endpoint next:

curl -X POST "https://api.test.checkname.ch/v1/name/screening" \
  -H "X-API-Key: <your-api-key>" \
  -H "Content-Type: application/json" \
  -d '{
    "companyName": "Alpen Data AG",
    "legalForm": "stock_corporation",
    "activityScope": "Software development services",
    "language": "de",
    "ownerSurname": null,
    "legalSeat": "Zurich",
    "languageVariants": [],
    "checkLevel": "full",
    "riskProfile": "balanced",
    "checks": {
      "ehraCompliance": { "enabled": true },
      "conflicts": { "enabled": true, "limit": 25, "minRisk": "Low" },
      "trademarks": { "enabled": true, "limit": 10, "minRisk": "Low", "niceClasses": [9, 42] },
      "domains": { "enabled": false }
    }
  }'

Confirm all of the following:

  • overallStatus is present and used as the bundled business outcome
  • resultState is COMPLETE, or your client can handle PARTIAL
  • drivers[] and primaryConcern can be parsed for routing or UI summaries
  • details.conflicts and details.trademarks are present when those checks are enabled

3) Screening catalog

Fetch the screening catalog if your frontend needs a complete list of codes and enum values for routing or localized copy mapping:

curl -X GET "https://api.test.checkname.ch/v1/name/screening/catalog" \
  -H "X-API-Key: <your-api-key>"

Confirm all of the following:

  • assessmentIssueCodes[] contains stable issue codes for details.ehraCompliance.issues[]
  • driverCodes[] contains stable driver codes for drivers[] and primaryConcern
  • message values are English fallback/debug descriptions
  • your UI maps stable codes to your own localized German copy

Use the standalone conflict search endpoint when you want the raw sub-check response or you orchestrate checks yourself.

curl -X POST "https://api.test.checkname.ch/v1/conflicts/search" \
  -H "X-API-Key: <your-api-key>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Alpen Data AG",
    "limit": 25,
    "minRisk": "Low"
  }'

Expected outcome:

  • Ordered matches by risk level and similarity strength
  • Your UI can use risk level as the first-level decision signal

Use the standalone trademark endpoint when you want the raw trademark response or you orchestrate checks yourself.

curl -X POST "https://api.test.checkname.ch/v1/trademarks/search" \
  -H "X-API-Key: <your-api-key>" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "Alpen Data",
    "limit": 10,
    "minRisk": "Low",
    "niceClasses": [9, 42]
  }'

Expected outcome:

  • goodsServicesBasis reflects whether Nice-class context was applied
  • Returned matches are ordered by trademark risk
  • Your integration can read matchBasis[], classOverlap, and relatedClassOverlap for explainability

6) Non-200 handling check

Before calling the integration done, verify that your client also handles:

  • 401 for missing or invalid API key
  • 400 or 422 for malformed or invalid payloads
  • 429 with Retry-After
  • transient 5xx responses with bounded retry behavior

Done means

  • You can call sandbox successfully.
  • You map overallStatus into your own workflow.
  • You can consume /v1/name/screening if you want the bundled orchestration flow.
  • You can consume /v1/name/screening/catalog to populate or verify UI copy/routing maps.
  • You persist traceId consistently.
  • You can consume both company conflict and trademark search responses.
  • You handle 400, 401, 422, 429, and transient 5xx responses.
  • You can switch base URL cleanly by environment.

If you are migrating from legacy eligibility endpoints, use Integration Guides > Name Eligibility Integration Guide rather than extending the quickstart with deprecated flows.