Skip to main content
This guide is outdated and will be removed on 1 November 2026. The up-to-date Estonia reference is on the Estonia country page.

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

All Estonian register data comes from the e-Äriregister (Estonian Business Register). In verification mode, the VAT number is also checked against the EU VIES system to fill taxId.verification. Prefill mode skips that check.
  • 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 register data comes from RIK. If an entity is not found in RIK, it does not exist in the Estonian business register. VIES is used only to verify the VAT number, in verification mode.

Company Identifiers

company.identifiers.euid is an optional European Unique Identifier. Domestic OÜ and AS companies. Example: EEARIREG.12417834. It is returned as an output identifier and cannot be used as a search input. See EUID coverage and interpretation.

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 is returned without the EE country prefix, both in identifiers.VAT and in taxId.value. The country is in taxId.country (EE) and the VIES verification result is in taxId.verification.
GLEIF is the supplementary data source for this identifier. company.identifiers.lei is optional. It is returned when the register code (registryCode) matches exactly one LEI through a GLEIF registration or validation reference. The Legal Entity Identifier has 20 uppercase alphanumeric characters, ending in two check digits. Coverage varies by entity. An absent lei does not prove that the company has no LEI. Lapsed, retired or merged LEIs may be returned; annulled LEIs are excluded.

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 reads the fast index and the live register in parallel. Every search (by name, by ID, by VAT) queries both and returns the merged results. When a company appears in both, the live register data is returned.

Active companies only

Search can return companies that are no longer active. Each result carries the register’s status, so activeOnly=true removes the inactive ones.

Fast search data

Estonia company data is periodically synchronized from the e-Business Register (Ariregister) open dataset into a fast search index. Each search reads the fast search index (active entities only) and the live RIK register in parallel, then returns the merged results.

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:

Prefill Mode

The fast search index above backs /v2/search. It does not serve the company datapoint: in prefill mode that datapoint still reads the Ariregister company data live, with a lighter parse to stay inside the prefill deadline. Company data is therefore as fresh in prefill as in verification, and carries the register’s availability rather than an index’s. See the prefill 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, OÜ, 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 OÜ). 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, 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. iso20275Code is returned when an ISO 20275 (ELF) code exists for the form, and is absent otherwise.
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 (the register’s company data service): Provides role codes from kaardile_kantud_isikud (persons entered on the card)
  2. Representation Rights (the register’s representation rights service): 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 the representation rights data
  • 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 in the representation rights data.

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 in the representation rights data 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 come from two sections of the RIK data: the kaardivalised_isikud (off-card persons) section, and any person from kaardile_kantud_isikud (persons entered on the card) who is not classified as a legal representative. Off-card persons with roles O (Shareholder) and OSAN (Shareholder) are excluded since they are processed as shareholders instead, and on-card partners (TOSAN, UOSAN, EUSOS, EUSOS2) are returned as shareholders, not as other key persons.
Other key persons include off-card persons (kaardivalised_isikud) and on-card persons who are neither legal representatives nor partners. Off-card 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). For sole traders (FIE) and non-profits (MTÜ, SA, ERAK, AMETÜ) with no equity records, the shareholders datapoint is not applicable and returns an explicit not-applicable response at no charge instead of an empty array.

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 beneficial owner service. 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 service. 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 Estonia’s national extension of NACE. RIK supplies the edition on each assignment: EMTAK 2008 corresponds to NACE Rev. 2; EMTAK 2025 corresponds to NACE Rev. 2.1. The system maps activity codes across three levels:
The native code remains under activities.EMTAK; recognized edition stamps also produce EMTAK_2008 or EMTAK_2025. EMTAK 2025 NACE classes feed standardized NACE directly. Explicitly labelled EMTAK 2008 classes are preserved under NACE_REV2 and transitioned into NACE with the formal correspondence. NACE_EE always preserves the register’s original NACE string. Unknown or conflicting editions do not receive a guessed standardized class. ISIC is derived centrally from standardized NACE using formal tables. Registered card activity and object text is returned as activityDescription when present, independently of the legal-form label.

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.
Delivery time: Documents are retrieved from the register when you request them, so they can take longer to arrive than datapoints. Use webhooks or poll the request until each document is delivered.

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) in the RIK representation rights data. 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 list comes back under documents: the trade register extract in tradeRegisterExtract, annual reports in financialStatements[] and articles in articlesOfAssociation[]. Annual reports include both PDF and XBRL versions and are sorted by year descending. Historical reports may go back many years. Pass a document’s id in the documents field of a follow-up request to download it.
Prefill is the same register call, parsed shallower — not a different data source. Both modes read the same Ariregister company data; prefill parses it lighter to stay inside the prefill deadline, not to read a cheaper dataset. The fast search 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 prefill:Request UBOs in verification mode; there is no fast source for them.