Skip to main content

Start here

This guide contains public integration notes for Latvia. Use it for identifier formats, search behavior, and country-specific caveats. The live source of truth for coverage, pricing, data sources, documents, legal forms, roles, and status values is the pricing page.

Latvia coverage, pricing, and sources

Open the current catalog for supported datapoints, documents, sources, identifiers, and availability.
Country details below are preserved as integration notes. If a table or example conflicts with the live pricing page, use the pricing page as the source of truth and contact support.

Data Sources

Latvia uses two complementary data sources: the real-time UR API for full company profiles and documents, and open data for fast batch-deduplicated search and onboarding.
  • Uzņēmumu reģistrs (UR) API. The Enterprise Register of the Republic of Latvia, maintained by the Register of Enterprises. This is the source for full company profiles with AI enrichment: activity codes (NACE/ISIC), legal representatives with standardized roles, supervisory board, shareholders with ownership details, UBOs with control types, and document access. Accessible at ur.gov.lv. The API uses OAuth2 with JWT client assertion (RFC 7523) for authentication.
  • Latvia Open Data (data.gov.lv). CC0-licensed datasets from the Enterprise Register, updated daily. Covers ~480K entities across 7 CSV files: company register, officers, members (SIA shareholders), stockholders (AS shareholders), beneficial owners, equity capitals, and areas of activity. Used for fast search and the onboarding profile datapoint.
Dual-source model. Search queries hit the fast search index first for fast results from batch data, then fall back to the UR API for supplementary results. The onboarding profile serves data directly from batch staging tables, while the full company profile uses the UR API for AI-enriched data.

Company Identifiers

Query Identifiers

Registration Number Format: Latvian registration numbers are 9-11 digits. The first digit(s) often indicate the entity type: 40 prefix is common for commercial companies (SIA/AS), 50 for older registrations, and shorter numbers (9 digits) appear for legacy entities.

Identifiers in API Response

Once you retrieve company data, the identifiers object contains all available identifiers for that entity:

Search Capabilities

Search Performance: Fast-index results arrive first from batch-deduplicated data covering ~480K entities. UR API results supplement later via progressive streaming. Use registration number searches for exact matching and best performance.
Search architecture: Search queries run all sources in parallel. Fast-index sources return first from synchronized open data. The UR API sources (by ID, by VAT, by name) provide supplementary results. Results are merged with matchType priority (ID > exact name > partial match).

Quirks & Gotchas

Company Status

Company status is determined deterministically from the UR API schema. No AI inference is involved. The API returns a finite enum of statuses with optional status details and liquidation records.
When a company has REGISTERED status with IN_LIQUIDATION details, the insolvencyStartDate is derived from the most recent active liquidation record’s startedOn date. The groundsForLiquidation field provides additional context (e.g., shareholder decision). For REMOVED companies, the closureDate comes from the removedOn field.
Latvia uses a finite set of 18 legal form types from the UR API. The mapping is fully deterministic, and no AI inference is used for legal form identification. ISO 20275 codes are derived via AI enrichment after the deterministic mapping.

Commercial Companies

Sole Entrepreneurs & Individual Entities

Non-Profits & Civil Society

European & International Entities

Other Entity Types

Unknown legal forms not matching the 18 known types fall back to using the raw API value as localName without English translation. ISO 20275 codes are always derived via AI enrichment, not from a static lookup table.
Legal representatives are extracted from the UR API officers array. The classification of a role as legal representative vs. other key person uses a hybrid approach: known roles are mapped deterministically, while unknown free-text roles fall back to AI enrichment. Role determination uses three signals from the API: the free-text role field, the enum position field, and the enum governingBody field.

Representation Mode

The UR API provides structured representation authority data in the rightsOfRepresentation field, which is mapped to representationMode:
  • { mode: "sole" }: Can sign alone (type: "INDIVIDUAL")
  • { mode: "joint", minimumSignatories: N }: Must sign jointly (type: "COLLECTIVE" with minimum count)
  • { mode: "joint" }: Joint signing required, count unspecified
  • null: No representation rights data provided by UR
Representation mode is populated from structured UR API data when available. Not all companies have this field populated in the registry.
When the free-text role does not match an exact mapping, pattern matching is used to determine if the role is a legal representative:If a pattern matches but the exact role is not known, the role is flagged for AI enrichment to provide accurate English translation and standardization.
Procurists are mapped separately from the procurations array (not the officers array). Each procuration may contain multiple procurists, and the system also extracts rightsOfRepresentation (e.g., INDIVIDUALLY, WITH_AT_LEAST, JOINTLY) and rightsOnImmovableProperty when available. Both individual and corporate legal representatives are supported.

Other Key Persons

Other key persons (supervisory board members, auditors) are extracted from the same officers array, classified by role, position, or governing body.

Other Key Person Roles (Deterministic Mapping)

Officers with governingBody = SUPERVISORY_BOARD but no explicit role or position are defaulted to “Supervisory Board Member” and flagged for AI verification. Both individual and corporate other key persons are supported.

Shareholders

Shareholders are extracted from the UR API members array for commercial companies only (SIA, AS). Non-profits, foundations, sole traders, and farms do not provide shareholder data.

Extraction Logic

The following fields are extracted from the API but require AI enrichment for full processing:
Both individual and corporate shareholders are supported. Corporate shareholders include registration number and country when available. Foreign corporate shareholders are identified with their home country registration details.

Activity Code Mapping

Latvia uses NACE (Nomenclature of Economic Activities) codes from the Enterprise Register. The system maps activity codes across two levels, with special handling for older NACE revisions:

NACE Revision Handling

NACE Revision Mismatch: Older Latvian companies may have NACE Rev. 1 or 1.1 codes that look similar to Rev. 2 codes but represent entirely different economic activities. For example, Division 15 in Rev. 1.1 = “Food products and beverages” but in Rev. 2 = “Leather and related products.” The system detects the revision and converts automatically.
Non-profit entities (associations, foundations) may have activity area codes (areasOfActivityOfAssociationsFoundations) instead of NACE codes. These use a separate classification (e.g., HEALTH_AND_DISEASE_PREVENTION, EDUCATION, CULTURE, SPORT) and are processed via AI enrichment to derive NACE/ISIC equivalents.

Data Availability Matrix

Legend: ✅ Available | ❌ Not Available | ⚠️ Conditionally Available | Async = Asynchronous processing

Documents by Company Type

Latvia provides comprehensive document access through the Enterprise Register (Uzņēmumu reģistrs). Documents are sourced from two channels: the UR website (for CTRE) and the UR API (for all other documents).

Always Available

From UR API (Public Documents)

Insolvency proceeding documents are retrieved from a separate API endpoint and enriched via AI parsing to extract the proceeding type, status, and descriptive English names.
Document Format Conversion: Documents from the Enterprise Register may arrive in TIF, HTML, EDOC, or ASICE format. All non-PDF formats are automatically converted to PDF before delivery. The format field in available documents reflects the output format (PDF), not the original source format.
Annual Report Deduplication: The UR API may return multiple versions of the same annual report (including DUF structured data files). The system automatically filters out DUF files and deduplicates by year+format, keeping only the most recent version.

Example API Responses

All examples use placeholder data. Query: POST /v2/company with { "id": "<id>", "countryCode": "LV", "dataPoints": ["company", "legalRepresentatives"] }
Note: Closed companies have active: false with a closureDate and closureReason. Different removal reasons (reorganization, liquidation, administrative dissolution) are mapped to specific closure reasons.
Note: Companies in liquidation have status Likvidācijas procesā (Under Insolvency Proceeding) with the liquidation start date. The liquidator replaces board members as the legal representative.
Note: Non-profit associations do not have shareholders or share capital. Legal representatives (board members) are available. Activity codes may use the non-profit activity area classification instead of NACE.
Query with "dataPoints": ["ultimateBeneficialOwners"]:
Note: UBOs are available directly from the Enterprise Register, no separate retrieve required. The natureOfControl field uses known enum values: AS_MEMBER, AS_FOUNDATION_FOUNDER, AS_OWNER, ON_GROUNDS_OF_PROPERTY_RIGHT, AS_SHAREHOLDER. Includes share and voting rights percentages when declared.
Documents are returned when "dataPoints": ["availableDocuments"] is requested.All entity types: