Skip to main content

Start here

This guide contains public integration notes for Estonia. 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.

Estonia 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.

Table of Contents

Data Sources

Estonia uses a single official registry for all company data. There is no fallback or secondary source. The system follows an all-or-nothing model where all attributes for a given entity come from a single source.
  • RIK (Registrite ja Infosüsteemide Keskus / Centre of Registers and Information Systems), operated under the Estonian Ministry of Justice since 1995, RIK maintains the Commercial Register (Ariregister), the Non-Profit Associations and Foundations Register, and the Commercial Pledge Register. It is the sole data source for all Estonian entity data including commercial companies, sole entrepreneurs, non-profits, foundations, and cooperatives. The API provides structured company profile data, legal representatives, shareholders, beneficial owners, activity codes, and documents.
All company data is sourced exclusively from the RIK registry via its SOAP/XML API. If an entity is not found in RIK, it does not exist in the Estonian business registry. There is no fallback source.

Company Identifiers

Query Identifiers

Registrikood Format: The registry code is always exactly 8 digits. Both commercial companies and non-profits use the same format. No letters, no prefixes.

Identifiers in API Response

The VAT number in the identifiers object is stored without the EE country prefix. The full EU VAT number (e.g., EE102090374) is available in the taxId object with VIES verification status.

Search Capabilities

Search Performance: Use identifier-based searches (Registrikood, VAT) for best performance and exact matching. Name searches query the RIK registry live and may return multiple results. Name queries must be at least 3 characters long.
Search uses live registry lookups. All search types (by name, by ID, by VAT) perform live queries to the RIK registry.

Fast search data

Estonia company data is periodically synchronized from the e-Business Register (Ariregister) open dataset into a fast search index. Search queries hit the fast search index first for instant results, with automatic fallback to the live RIK API if the fast search index misses.

Companies in fast search data

The fast search index contains only active Estonian entities from the Ariregister. Companies are filtered by status: All other statuses are excluded from the fast search dataset:

Onboarding Mode

The fast search index above backs /v2/search. It does not serve the company datapoint: in onboarding mode that datapoint still issues a live detailandmed_v2 lookup to the Ariregister, parsed at a shallower depth to stay inside the 10s onboarding deadline. Company data is therefore as fresh in onboarding as in verification, and carries the register’s availability rather than an index’s. See the onboarding example response below for exactly what the shallower parse changes (raw addresses, no taxId, no UBOs).

Quirks & Gotchas

Mappings

The Code column is reference only — it is never returned by the API. RIK classifier codes (R, , JUHL, JAH, O, …) are documented here so you can trace a value back to the Ariregister, but no response field carries them. What you actually get:localName is the register’s Estonian label (Osaühing, not ). company.status has no englishTranslation.standardized uses two different vocabularies. On legalRepresentatives[].role it is the standard role enum; on otherKeyPersons[].role it is the narrower other-key-person enum, which has no Managing Director, Chairman of the Board, Owner or Liquidator. The same register code therefore standardizes differently depending on which array it lands in — Nõukogu esimees is Chairman of the Board as a legal representative but Board Member as an other key person. Key off localName + the array you found it in if you need to tell those apart.representationMode is sole-or-absent in Estonia. RIK’s JAH maps to { mode: "sole" }; EI and EI TEA omit the field entirely rather than emitting a value. Estonia never returns mode: "joint", namedCoSigners, minimumSignatories or particularity, and the field is only ever set for individuals, never for corporate legal representatives.UBO control has no localName. The human-readable field is control.description, and it is the one local field that comes back in English. control.types is an array but Estonia always populates exactly one entry, and control.details is present only for the ownership types (O, K), not for voting-rights or significant-influence entries.On bankruptcy statusDetails grows. It gains closureReason, insolvencyStartDate and an additionalInfo string that is free text from the register, in Estonian (e.g. "Harju Maakohtu kohtumäärusega (2-26-14436) kuulutati välja ... pankrot 27.08.2026 kell 11.00."). Do not parse it; branch on statusDetails.status and closureReason.

Possible values

The complete set Estonia can return for each field. The per-code tables below give the full localName list; these are the standardized vocabularies you would branch on. company.status.statusDetails.status — 4 reachable of the shared enum: ACTIVE (R), UNDER_INSOLVENCY_PROCEEDING (L and N), CLOSED (K), UNKNOWN (defensive default, not observed in production). Estonia never returns INACTIVE_NOT_CLOSED or PENDING_DISSOLUTION. The only closureReason Estonia sets is BANKRUPTCY, on N. The matching localName values are the four in the table below. legalRepresentatives[].role.standardized — 11 values: Administrator, Auditor, Board Member, Chairman of the Board, Director, General Partner, Limited Partner, Liquidator, Managing Director, Other, Owner. otherKeyPersons[].role.standardized — 7 values, from a different and narrower enum: Auditor, Board Member, C-Level Executive, General Partner, Limited Partner, Liquidator, Other.
The two role vocabularies are not interchangeable. C-Level Executive exists only for other key persons; Managing Director, Chairman of the Board, Owner, Director and Administrator only for legal representatives. 19 of the 57 register codes standardize differently depending on which array they appear in, so the same person in the same role can carry a different standardized value in each. For example Nõukogu esimees (E) is Chairman of the Board as a legal representative and Board Member as an other key person; Juhatuse liige (juhataja) (JUHJ) is Managing Director vs C-Level Executive. Key off localName plus the array if you need to tell them apart.
ultimateBeneficialOwners[].control.types — all 4 of the shared enum are reachable: ownership-of-shares, voting-rights, appoint-and-remove-directors, significant-influence-or-control. Estonia always populates exactly one entry. company.legalForm.standardized — 9 values: Branch or Representative Office, Cooperative, Corporation, Government Owned Entity, Limited Liability Company, Nonprofit Organization, Other, Partnership, Sole Proprietorship.
No AI produces these sets. Status, roles and UBO control types are resolved by deterministic lookup tables, and the legal form map covers all 19 forms present in the register today, so the AI enrichment fallback does not fire in practice.Two open-ended cases exist at the edges. An unrecognised role code returns localName: "Tundmatu roll: <CODE>" with standardized: "Other", so the role sets above stay closed. An unrecognised legal form code is the one place the register can outrun us: localName falls back to the raw code, the AI fallback picks standardized, and isAIEnriched: true is set on the object. Check that flag if you need to know whether a legal form was inferred rather than mapped.

Company Status

Company status is extracted deterministically from the RIK register staatus field. No AI inference is involved.
When status is N (bankruptcy), the system also searches for the bankruptcy declaration event (PANKV) in the status change history to extract the insolvency start date and additional context.
The local legal form (oiguslik_vorm) is preserved from the register and deterministically mapped to an English translation. For known codes, standardized classification is applied directly; for unrecognized codes, AI-based classification is used as fallback. ISO 20275 (ELF) codes will be populated in a future update.
Legal forms are classified from official registry data. For known codes, standardized classification is applied directly; for unrecognized codes, AI-based classification is used as fallback.

Companies

Sole Proprietorships

Partnerships

Cooperatives

Non-profit Organizations

Government & Public Law Entities

Branch Offices

Discontinued

Legal representatives are determined using two data sources from RIK:
  1. Role Data (detailandmed_v2 endpoint): Provides role codes from kaardile_kantud_isikud (persons entered on the card)
  2. Representation Rights (esindus_v1 endpoint): Provides the ainuesindusoigus_olemas field indicating exclusive representation rights

Classification Logic

A person is classified as a legal representative if either:
  • They have JAH (exclusive/sole representation rights) from esindus_v1
  • OR Their role code implies representation rights (see tables below)

Representation Mode

For individuals (not companies), the representationMode field is set based on the ainuesindusoigus_olemas value:
Companies (corporate legal representatives) are classified based on role only. They do not have personal representation rights data. The representationMode field is only applicable to individuals.
EI TEA (Unknown) is returned for roles where representation rights cannot be clearly determined (procurators, branch directors, certain board positions). These individuals ARE legal representatives due to their roles, but we cannot determine if they have sole or joint representation rights.
Partnership representation rights: General partners (TOSAN) have inherent representation rights under Estonian Commercial Code (Äriseadustik) §98(1): each partner may represent the partnership in all transactions unless the agreement restricts it. §100 allows a court to deprive this right on request of the other partners, confirming it is inherent, not granted. Limited partners (UOSAN) have no representation rights by default. EUSOS/EUSOS2 (“esindama volitatud usaldusosanik” = limited partner authorized to represent) are the exception: the authorization is explicitly entered in the commercial register, which is why the role code exists. Regular limited partners (UOSAN) are classified as shareholders only.
These roles trigger automatic classification as a legal representative when the person does not have JAH from esindus_v1.

Explicit representation roles

The role name itself contains “represent” in the RIK ISIKROLLID classifier.

Implied representation roles

These roles do not mention “represent” in their classifier name but carry representation authority by the nature of the role.
JUHA, JUHE, and JUHJ are sub-roles of management board membership. In practice they always receive JAH from esindus_v1 and are classified as legal representatives via that path, not via the role code.
Legal representative classification is deterministic, based on the role code and the ainuesindusoigus_olemas field. No AI is involved. Both individuals (isiku_tyyp = F) and corporate entities (isiku_tyyp != F) can hold legal representative roles.

Other Key Persons

Other key persons are extracted from the RIK kaardivalised_isikud (off-card persons) section. Persons with roles O (Shareholder) and OSAN (Shareholder) are excluded from other key persons since they are processed as shareholders instead.
Other key persons are extracted from the kaardivalised_isikud (off-card persons) section. Persons with role code O or OSAN (both mean “Shareholder”) are excluded from other key persons and processed as shareholders instead. Both individuals and corporate entities can appear as other key persons.

Shareholders

Shareholders are extracted from two different sections of the RIK data depending on the company type:
  • OÜ / AS: Shareholders come from kaardivalised_isikud (off-card persons) with role O or OSAN and a positive ownership percentage.
  • TÜ / UÜ (partnerships): Partners come from kaardile_kantud_isikud (card-registered persons) with roles TOSAN (general partner), UOSAN (limited partner), EUSOS or EUSOS2 (limited partner authorized to represent). These are returned as shareholders since partners are the owners of partnerships. When the same person appears under multiple roles (e.g. both EUSOS and UOSAN), they are deduplicated, keeping the entry with capital contribution data.
Supported entity types: OÜ (private limited companies), AS (public limited companies), TÜ (general partnerships), and UÜ (limited partnerships). Other entity types (FIE, MTÜ, SA) typically do not have shareholder data.

Ownership Fields

For OÜ/AS: Shareholders with osaluse_protsent = 0.000000 or no ownership percentage are automatically filtered out. Both individual and corporate shareholders are supported, with address parsing for both types.For TÜ/UÜ partnerships: Partners do not have ownership percentages (sharePercentage is absent). General partners (TOSAN) have unlimited liability and no capital contribution. Limited partners (UOSAN, EUSOS, EUSOS2) have a capital contribution (osamaks) returned as nominalCapitalHeld.

UBO Control Types

Ultimate Beneficial Owner (UBO) data is sourced from the RIK tegelikudKasusaajad_v2 SOAP endpoint. Each UBO has a control type code (kontrolli_teostamise_viis) defined by the Estonian Money Laundering and Terrorist Financing Prevention Act (RahaPTS §9).
Commercial Register only. UBO data is queried from the Äriregister (Commercial Register), which covers commercial entities: OÜ, AS, TÜ, UÜ, FIE, and branches of foreign companies. Non-profit associations (MTÜ) and foundations (SA) are registered in a separate register (Mittetulundusühingute ja sihtasutuste register) and are not covered by this API endpoint. As a result, control type codes S, Z, and C (which are specific to foundations and non-profits) are unlikely to appear in practice through our integration.

Activity Code Mapping

Estonia uses the EMTAK (Eesti Majanduse Tegevusalade Klassifikaator) classification, which is the Estonian national extension of the European NACE Rev. 2 standard. The system maps activity codes across three levels:
EMTAK codes are 5-digit extensions of NACE Rev. 2 codes. The RIK registry provides both EMTAK and NACE codes together in the teatatud_tegevusalad section, so the EMTAK-to-NACE mapping is always deterministic. EMTAK descriptions are in Estonian; NACE descriptions are mapped to English using an internal mapping table (EMTAK_DESCRIPTIONS_MAPPING). ISIC codes are derived from NACE using formal mapping tables where possible, with AI fallback. Check the isAIInferred flag to distinguish official vs. AI-derived codes.

Data Availability

Data Availability Matrix

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

Documents by Company Type

Annual reports are available in both PDF and XBRL formats when both exist. The documents list is sorted by year descending (newest first). Historical annual reports going back many years may be available.
Document retrieval timeout: Document fetching from the RIK portal uses extended timeouts (up to 60 minutes) with 5 retrieval attempts, as the portal can be flaky with HTTP 303 redirects on session expiry. The trade register extract requires a separate login-based flow through the RIK portal.

Example API Responses

All examples use placeholder data. Query: POST /v2/company with { "id": "<id>", "countryCode": "EE", "dataPoints": ["company", "legalRepresentatives"] }
Note: This example shows representationMode set to "sole" for legal representatives who have JAH (exclusive/sole representation rights) from the RIK esindus_v1 endpoint. Both board members can sign independently on behalf of the company. The representationMode field is only set for individuals (not companies) who have confirmed sole representation rights.
Note: Closed companies have active: false and status “Kustutatud” (Deleted from register). Address data may be empty. VAT verification is unavailable for closed entities. UBO data is deleted 5 years after closure.
Note: Non-profits do not have shareholders or capital information. Legal representatives (board members) are available. Birth dates are extracted from Estonian personal ID codes (isikukood).
Query with "dataPoints": ["ultimateBeneficialOwners"]:
Note: UBOs are available for commercial companies registered in the Äriregister (Commercial Register). UBO data is automatically deleted 5 years after a legal person is removed from the register. See the UBO Control Types section below for the full mapping of control type codes.
Query with "dataPoints": ["availableDocuments"]:
Note: The trade register extract is always listed first. Annual reports include both PDF and XBRL versions and are sorted by year descending. Historical reports may go back many years.
Onboarding is the same register call, parsed shallower — not a different data source. Both modes issue the same detailandmed_v2 request to the Ariregister; the fast lane exists to keep onboarding inside its 10s deadline and to hold a separate cache identity, not to read a cheaper dataset. The Meilisearch index built from the Ariregister open data backs /v2/search only.So status, legalForm and every role are identical to verification, standardized and iso20275Code included, and shareholders and activity codes are returned.What actually differs in onboarding:Request UBOs in verification mode; there is no fast source for them.