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
- Company Identifiers
- Search Capabilities
- Fast search data
- Quirks & Gotchas
- Mappings
- Data Availability
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
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 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
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, 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, 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 fulllocalName 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.
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 registerstaatus 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.Legal Forms
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
European Legal Forms
Branch Offices
Discontinued
Legal Representatives
Legal representatives are determined using two data sources from RIK:- Role Data (
detailandmed_v2endpoint): Provides role codes fromkaardile_kantud_isikud(persons entered on the card) - Representation Rights (
esindus_v1endpoint): Provides theainuesindusoigus_olemasfield 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), therepresentationMode 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.Roles That Imply Representation Rights
Roles That Imply Representation Rights
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.Other Executive & Board Roles
Other Executive & Board Roles
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.Insolvency & Liquidation Roles
Insolvency & Liquidation Roles
Representative & Other Roles
Representative & Other Roles
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 RIKkaardivalised_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.
Board & Supervisory Roles
Board & Supervisory Roles
Executive Roles
Executive Roles
Auditor Roles
Auditor Roles
Other Roles
Other Roles
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 roleOorOSANand a positive ownership percentage. - TÜ / UÜ (partnerships): Partners come from
kaardile_kantud_isikud(card-registered persons) with rolesTOSAN(general partner),UOSAN(limited partner),EUSOSorEUSOS2(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. bothEUSOSandUOSAN), they are deduplicated, keeping the entry with capital contribution 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 RIKtegelikudKasusaajad_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.
Example API Responses
All examples use placeholder data. Query:POST /v2/company with { "id": "<id>", "countryCode": "EE", "dataPoints": ["company", "legalRepresentatives"] }
Active OU (Private Limited Company)
Active OU (Private Limited Company)
Company with Representation Mode (Bolt Technology OÜ - 12417834)
Company with Representation Mode (Bolt Technology OÜ - 12417834)
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.Closed OU (Deleted from Register)
Closed OU (Deleted from Register)
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.Non-profit Association (MTU)
Non-profit Association (MTU)
UBO Response (dedicated datapoint)
UBO Response (dedicated datapoint)
Query with 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.
"dataPoints": ["ultimateBeneficialOwners"]:Available Documents
Available Documents
Query with 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.
"dataPoints": ["availableDocuments"]:Onboarding Profile (Source: Ariregister, fast lane)
Onboarding Profile (Source: Ariregister, fast lane)
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.