Datasivio logo Datasivio AI Data agent
Technical Documentation

Schema reference for the Baltic data platform

This page describes the data model behind the API: the primary tables, how records relate to each other, and what each dataset is intended to contain. The current database uses one physical PostgreSQL schema, public, with country-specific logical groupings.

PostgreSQL + JSONB Estonia, Latvia, Lithuania Company, filing, procurement, ownership data
Browse Tables Back to API Docs
Platform Overview

One physical schema, multiple logical domains

The application groups data by country and record type. Estonia leans more heavily on JSONB registry payloads, while Latvia and Lithuania include more normalized statement tables for financial reporting and analysis.

3 country domains represented in the API surface
10 core public tables referenced directly by application queries
2 main storage styles: raw JSONB payloads and normalized ledger rows
Logical Model

How the datasets fit together

Company identity tables anchor the rest of the platform. Detail tables either extend a company with related JSON payloads, or attach period-based reporting records that can be filtered and paginated independently.

Estonia

  • basic_companies_data is the canonical company registry payload table.
  • estonia_leaders_data and estonia_shareholders_data extend the same company key, ariregistri_kood.
  • estonia_procurement_company_index links companies to procurement notices, and joins to estonia_procurement_notices by notice_id.

Latvia and Lithuania

  • latvia_companies and lithuania_legal_entities are the company master tables.
  • latvia_financial_statements groups filing-level metadata, while latvia_income_statements stores extracted statement lines linked by statement_id.
  • lithuania_balance_sheets, lithuania_profit_loss, and lithuania_ngos all key off ja_kodas.
public.basic_companies_data (ariregistri_kood) -> public.estonia_leaders_data (ariregistri_kood) -> public.estonia_shareholders_data (ariregistri_kood) public.estonia_procurement_company_index (notice_id, company_id) -> public.estonia_procurement_notices (notice_id) public.latvia_companies (regcode) -> public.latvia_financial_statements (legal_entity_registration_number) -> public.latvia_income_statements (statement_id -> latvia_financial_statements.id) public.lithuania_legal_entities (ja_kodas) -> public.lithuania_balance_sheets (ja_kodas) -> public.lithuania_profit_loss (ja_kodas) -> public.lithuania_ngos (ja_kodas)
Table Catalog

Primary schemas and what each one entails

The summaries below follow the fields and joins used by the current application code, so they map closely to what the API returns today.

Estonia public.basic_companies_data

Company master registry payload

Stores the core Estonian company record. Used by search, autocomplete, advanced search, bulk lookup, stats, and company detail endpoints.

  • ariregistri_kood: canonical company registration code.
  • data: raw JSONB payload containing fields such as nimi, staatus, asukoht, nested addresses, activities, and annual report fragments.
  • created_at / updated_at: ingestion timestamps.
Estonia public.estonia_leaders_data

Company leadership extension

One related JSON payload per company code for directors, board members, or other officer-style records returned by the leaders endpoint.

  • ariregistri_kood: foreign key in practice to the company master record.
  • data: leadership payload stored as JSONB.
  • created_at / updated_at: load tracking timestamps.
Estonia public.estonia_shareholders_data

Ownership and shareholder extension

Holds shareholding payloads keyed by company code and returned by the shareholder endpoint.

  • ariregistri_kood: company lookup key.
  • data: shareholder and ownership structure JSONB payload.
  • created_at / updated_at: ingestion metadata.
Estonia public.estonia_procurement_company_index public.estonia_procurement_notices

Procurement search pair

Implements notice search by supplier or buyer name. The index table is optimized for company lookup and joins into the full notice payload table.

  • company_index: notice_id, company_name, company_id, role.
  • notices: notice_id, data, updated_at.
  • Join path: estonia_procurement_company_index.notice_id = estonia_procurement_notices.notice_id.
Latvia public.latvia_companies

Latvia company master table

Supports search, autocomplete, and company detail lookups. It mixes normalized top-level columns with a full raw payload.

  • regcode: company registration code used as the primary API lookup key.
  • company_name, company_type, status: common search and display columns.
  • registered_date / terminated_date: lifecycle dates.
  • data: full raw company payload.
Latvia public.latvia_financial_statements

Latvia filing-level statement metadata

Represents financial statement documents and filing metadata for a company. This is the parent table for detailed Latvia income statement rows.

  • id: statement record identifier.
  • file_id: source file identifier.
  • legal_entity_registration_number: joins back to latvia_companies.regcode.
  • source_schema / source_type: origin metadata describing the parsed source variant.
  • year, year_started_on, year_ended_on, employees, currency: reporting period attributes.
  • data: raw filing payload.
Latvia public.latvia_income_statements

Latvia normalized income statement lines

Contains extracted numeric metrics for profitability and operating performance, exposed both by company and by statement ID.

  • statement_id: joins to latvia_financial_statements.id.
  • net_turnover, gross_profit, administrative_expenses, net_income, and related decimal columns store normalized measures.
  • data: raw parsed statement payload retained alongside normalized columns.
  • created_at / updated_at: statement extraction tracking.
Lithuania public.lithuania_legal_entities

Lithuania legal entity master table

Provides the company search and detail base for Lithuania, with both flattened columns and the full source payload.

  • ja_kodas: legal entity code used by all Lithuania endpoints.
  • ja_pavadinimas, adresas, form_kodas, stat_kodas: identity and status columns.
  • ja_reg_data, stat_data_nuo, formavimo_data: registration and extract dates.
  • data: full raw legal entity payload.
Lithuania public.lithuania_balance_sheets public.lithuania_profit_loss

Lithuania financial line item tables

Each row represents a financial statement line for a specific entity and reporting period. The two tables have parallel shapes for balance sheet and profit-and-loss reporting.

  • ja_kodas / ja_pavadinimas: entity identity.
  • template_id, template_name, standard_id, standard_name: source taxonomy metadata.
  • line_type_id / line_name: statement line definition.
  • reiksme: decimal amount stored as a numeric value and serialized as a string by the API.
  • beginning_date, turning_date, reg_date, formavimo_data: reporting and publication dates.
Lithuania public.lithuania_ngos

Lithuania NGO profile table

Stores non-profit and NGO-specific registry information keyed by legal entity code and returned as a direct lookup dataset.

  • ja_kodas / ja_pavadinimas: entity identity.
  • form_kodas / form_pavadinimas: legal form metadata.
  • status and filing attributes: current registry positioning for the organization.
  • data style: endpoint exposes the selected row directly rather than paginating a statement series.
Operational Notes

Conventions used across the API and schema

Pagination and access patterns

  • List endpoints use limit with either page or offset.
  • Search tables are ordered by a human-readable company or filing field rather than by insertion time, except procurement and statement history views.
  • Most statement and search endpoints return has_more to support incremental fetching.

Data typing behavior

  • Dates are normalized to ISO 8601 strings in API responses.
  • Decimal values from financial tables are serialized as strings to avoid precision loss in JSON consumers.
  • JSON-heavy tables preserve raw source payloads, making it possible to access fields not yet promoted into top-level columns.

Search semantics

  • Text lookups are primarily case-insensitive partial matches using ILIKE.
  • Estonia category search reads nested JSON activity arrays inside the company payload.
  • Latvia and Lithuania search paths rely more on normalized company name columns.

What this page is meant to support

  • Integration planning for clients that need to understand what each endpoint is actually backed by.
  • Analytics and ETL work that needs to choose between raw payload access and normalized financial line items.
  • Future schema evolution discussions without having to reverse-engineer the application queries first.