Short answer
The indexed Estonian Public Procurement Register (Riigihangete register) collection contains five reference records. They describe:
- the register's ;
- , including yearly XML downloads;
- monthly XML files for ;
- monthly XML files for ; and
- the register's .
The underlying data are available from official, no-authentication open-data endpoints. The indexed resource audit recorded a 435 KB procurement-plan XML, a 35.9 MB procurement-notice XML and a 31.7 MB award-notice XML.
But those underlying procurements are not available as individual Legalcode records. Legalcode indexes only the five descriptions and file profiles. It cannot currently search for a procurement, contracting authority, supplier, award or contract by its own identifier.
The five indexed records
Discovery reports exactly five documents for this source, and the source-scoped search returned all five. The number five is therefore a count of reference materials, not a count of procurements.
What the open-data page promises
The open-data reference says that the register provides information about procurements and contracts in machine-readable form for free public use. It identifies manual downloads and machine-interface URL patterns for three groups:
- procurement plans;
- procurement and modification notices; and
- signed-contract/award and modification notices.
The page describes notice XML from 1 September 2017 onward as using a TED format. However, the indexed wording contains unresolved template text and does not reliably identify the TED schema version. That defect is discussed below.
Procurement plans
The procurement-plan record describes both a public JSON listing and yearly XML downloads. Its resource profile recorded a 2026 XML file of 435,231 bytes containing ProcurementPlan records.
The profile identifies fields that would be commercially useful if the rows were ingested:
- year;
- contracting authority code and name;
- target contracting authority code and name;
- status;
- reference number;
- procurement name and description;
- joint- and central-procurement indicators;
- estimated procurement cost;
- expected contract-signing date;
- EU-funds indicator; and
- responsible person's email address.
The same snapshot recorded 2025 and 2027 XML responses of only 27 bytes. That shows why HTTP success alone is not proof that a year contains plan records: payload size and parsed record counts must also be checked.
Legalcode does not expose the 2026 plans individually. A user cannot search the MCP by procurer code, reference number or procurement name and retrieve one plan from this source.
Procurement and modification notices
The notice reference describes monthly XML downloads at a year-and-month URL. For June 2026, the indexed resource audit recorded:
- HTTP status 200;
- a payload of 35,937,913 bytes; and
ContractNoticeas the record element.
This is strong evidence that a substantial official notice file existed at the endpoint when the source was profiled. The Legalcode document does not parse or list its notices, columns or notice identifiers. It records only the file-level facts and URL pattern.
The reference title groups procurement notices and modification notices together. Without row-level ingestion, Legalcode cannot tell a user which notice type applies to a particular procurement or reliably connect a modification to its original notice.
Signed-contract, award and modification notices
The award reference uses the register's notice_award monthly endpoint. For June 2026, its resource profile recorded:
- HTTP status 200;
- a payload of 31,744,227 bytes; and
ContractAwardNoticeas the record element.
Again, the official XML appears to contain underlying data, but the MCP contains no individual award, signed contract or modification record. A supplier name or company identifier appearing only inside that XML is not searchable through the present collection.
The indexed label “signed contract and modification notices” should also be read carefully. It describes the endpoint family; it does not prove that every contract document, annex or performance event is included in each notice row.
What the policy and terms say users may browse
The policy record describes the register as a free self-service environment in which contracting authorities conduct procurements and economic operators participate. It says anyone may freely browse:
- published procurements;
- notices;
- contract information; and
- review committee decisions.
It also identifies the State Shared Service Centre (Riigi Tugiteenuste Keskus) as the register administrator from 1 January 2024.
The terms generally prohibit access through special-purpose programs without prior written consent, but expressly say that the restriction does not apply to open data. That exception supports use of the identified open-data endpoints. It should not be stretched into permission to automate other register surfaces outside the open-data interface or to disregard applicable law and the remaining terms.
The statement about review committee decisions is also a coverage warning. The five-record Legalcode collection contains no individual review committee decision, even though the policy says such decisions are publicly browsable in the register.
Are the underlying records “available”?
The answer depends on where the question is asked.
At the official register: yes, through open-data files
The official interface publishes endpoints and the indexed audit recorded successful, non-trivial XML payloads. Procurement plans, notices and award-related notices therefore exist as source data outside Legalcode.
This does not mean that every period contains records or that every field is populated. The 27-byte plan responses for two years demonstrate the need to inspect each payload rather than infer coverage from a successful request.
In Legalcode: no, not as procurement records
Legalcode contains catalogue-like descriptions of the files. It does not contain searchable rows for:
- a particular procurement reference number;
- a contracting authority or procurer code;
- a supplier or successful tenderer;
- a notice or award date;
- a procurement value or contract value;
- a CPV classification;
- an exclusion finding;
- a modification linked to an original notice; or
- a review committee decision.
That distinction is critical for later questions about financial distress or procurement exclusion. The present collection proves where relevant evidence may be obtained; it does not itself provide the evidence for a named company or procedure.
Collection defects found during the review
Underlying XML rows are not ingested
Legalcode issue asks for the open-data payloads to be normalised into individual procurement records with stable identifiers and structured fields. Until that work is done, a search count must never be described as procurement activity.
Dates and language metadata are wrong
The terms record is an English page with English text but is labelled EST. Its source text contains native “last updated” dates of 30 September 2025 and 26 February 2026, while Legalcode reports 2 July 2026 as the publication date—the same day identified as its database-update date.
Issue tracks the date and language metadata defects. The two source-native dates also suggest that material from more than one page was combined; each date needs page-level provenance.
The open-data description contains unresolved placeholders
The indexed open-data text contains Description: {{:: url}} and an unresolved pre-2017 format description ending in TED (year no. ?). These appear to come from client-side interface or translation assets that were not fully resolved during extraction.
Issue asks for the actual schema/version description to be recovered and for unresolved template expressions to be excluded from canonical source text.
Authority and proper use
The five documents are reference materials about an official register and its open-data interfaces. They are useful evidence of access routes, file families and terms of use. They are not procurement notices, contract awards, review decisions or legislation.
A conclusion about a named supplier, exclusion ground, contract or award must be tied to the actual underlying source record and its identifier. A file profile or endpoint description cannot substitute for that evidence.
Conclusion
The indexed collection accurately points to three useful open-data families: procurement plans, procurement/modification notices, and signed-contract/award modification notices. It also describes the register's public browsing and open-data terms. The source files are real and, in the profiled month and year, substantial.
What is missing is the level users normally mean by “procurement records.” Legalcode has five reference descriptions, not individual plans, notices, awards, contracts or review decisions. It can direct a researcher to the official data but cannot yet answer procedure- or company-specific procurement questions from the indexed corpus.
Sources and audit issues
This article provides general legal information, not advice for a specific matter. Laws, facts and procedural deadlines may change the result. Follow the linked primary sources and obtain local advice before acting.