How to Scrape Finland's Company Registry (PRH/YTJ) in 2026

If you need a targeted list of Finnish companies — every limited company in Helsinki, every software firm nationwide, every business registered last quarter — the data already exists in Finland’s official registry. The friction is that it lives behind a deeply nested, multi-language JSON API that returns Finnish, Swedish, and English descriptions in parallel arrays, paginates in blocks of ~100, and does nothing to shape the output for a CRM. This guide covers what the PRH / YTJ open data exposes, how the underlying API is structured, and how to pull clean, English-first company rows at scale.

What’s worth extracting

Finland’s registry is unusually clean for a government source. Every company resolves to a single canonical business ID (Y-tunnus), and each record carries a consistent set of fields. Per company, you can extract:

• Identity — businessId (the Y-tunnus, Finland’s stable company identifier), current registered name, and the public YTJ page url.
• Legal form — companyFormCode and its companyForm description (OY limited company, OYJ public limited, AOY housing company, KY, AY, TMI, and more).
• Industry — mainBusinessLineCode (the NACE / TOL code, e.g. 62010 for computer programming) and its English mainBusinessLine description.
• Location — street, zip, city, and an addressType flag (visiting vs postal).
• Contact — website, when the company registered one with PRH.
• Provenance — registrationDate, lastModified (when present), a source register code, and a scrapedAt timestamp.

That’s roughly 17 fields per row. For lead generation you typically need name, business ID, form, industry, address, and website; for KYC you care most about the business ID, legal form, and registration date straight from the official register.

How the source actually works

The data comes from avoindata.prh.fi — the open-data API published by the Finnish Patent and Registration Office (PRH), which operates the Business Information System (YTJ) jointly with the Finnish Tax Administration. It is genuinely open: fully free JSON, no account, no key, no captcha. The endpoint accepts query parameters that map to the filters you’d expect:

GET https://avoindata.prh.fi/opendata-ytj-api/v3/companies
  ?location=Helsinki
  &companyForm=OY
  &mainBusinessLine=62010
  &registrationDateStart=2025-01-01
  &registrationDateEnd=2025-12-31

The scraper wraps this and takes a flat input object. A realistic run — every limited company in Helsinki — looks like:

{
  "location": "Helsinki",
  "companyForm": "OY",
  "maxResults": 1000
}

You can also search by name (the API’s name parameter), by postCode, or resolve a single company by exact businessId — the last is ideal for CRM enrichment, where you already hold the Y-tunnus and want to append registry fields. A software-sector sweep needs nothing more than a NACE code:

{
  "mainBusinessLine": "62010",
  "maxResults": 2000
}

The real work the actor does on top of the raw API is flattening. PRH returns names, company-form descriptions, and business-line descriptions as arrays of language-tagged objects (a language code and a value) across Finnish, Swedish, and English, plus multiple historical address and name records per company. The scraper picks the current values, prefers the English description where one exists (falling back to the first available language), and collapses everything into one tabular row per business ID.

You can also skip codes entirely and let the output teach you them. Search by name or location, then read the companyFormCode and mainBusinessLineCode columns on the returned rows to discover the exact codes for the forms and industries you care about — then re-run with those codes as filters for a precise segment. Company-form codes include OY, OYJ, AOY, KY, AY, and TMI; NACE / TOL business-line codes are numeric (62010 software, 70220 management consultancy, 73110 advertising).

▶ Open the Finland Company Registry Scraper on Apify — one run turns a town or NACE filter into thousands of clean company rows with business ID, form, industry, address and website. No key, no login. Export to CSV, JSON or Excel.

The access reality

Because the source is open data, there is no anti-bot wall, no TLS fingerprinting, and no login to defeat — the honest friction here is structural, not defensive:

• Pagination. The API returns ~100 companies per page. Large segments are common — Helsinki alone holds roughly 88,000 registered companies — so a full-town pull means many sequential page requests. The actor pages through automatically and de-dupes by business ID.
• Multi-language nesting. The raw payload is not query-ready. Without flattening you get parallel Finnish/Swedish/English arrays and nested address objects that you’d have to reshape yourself before loading into any warehouse.
• Broad name searches are slow. A very generic name like oy matches an enormous slice of the register. For high-volume runs, location is the more reliable filter than a broad name.
• Proxy is optional. The endpoint is stable whether you go direct or through a datacenter proxy. useProxy defaults to on because datacenter routing is plenty for an open API; there’s no need for residential IPs here.

Example output

One flattened record, straight from the registry:

{
  "businessId": "0100123-2",
  "registrationDate": "1978-03-15",
  "name": "Oy Emar Ab",
  "companyFormCode": "16",
  "companyForm": "Limited company",
  "mainBusinessLineCode": "66190",
  "mainBusinessLine": "Other activities auxiliary to financial services",
  "street": null,
  "zip": "00131",
  "city": "HELSINKI",
  "addressType": "2",
  "website": null,
  "source": "3",
  "url": "https://tietopalvelu.ytj.fi/en/yritys/0100123-2",
  "scrapedAt": "2026-07-06T00:00:00.000Z"
}

Typical use cases

• B2B lead generation — build targeted Finnish prospect lists by combining a town, company form, and NACE code, then push straight to your CRM.
• Sales prospecting — filter by company form and business line, and prioritize companies that registered a website (a rough proxy for digital maturity).
• Market research — count and profile companies by NACE code, town, and founding date to size a segment before entering it.
• KYC, compliance & due diligence — verify a business ID, legal form, and registration date against the official register rather than a third-party aggregator.
• Competitor mapping — survey every company in a vertical or a single town in one run.
• Discovering new incorporations — set a registrationDateStart / registrationDateEnd window to surface firms registered in a given period, so you can reach newly founded companies early.

Build it yourself vs. use the actor

The API is free and unauthenticated, so a proof-of-concept fetch is a five-minute job. The cost shows up once you go past a toy query. You’ll write and maintain the pagination loop, the language-preference logic that flattens three parallel description arrays, the address-record selection, and business-ID de-duplication across pages — then keep it working as PRH revises the open-data schema. None of that is hard; all of it is time.

On the managed side, pricing is pay-per-result: you pay a small fraction of a cent per company row plus a negligible run-start fee, with no proxy bill (datacenter is included and sufficient) and no maintenance hours. For a segment like “every OY in Espoo” that’s tens of thousands of rows for a low single-digit dollar cost, and the flattening/pagination is already solved.

Common pitfalls

Specific gotchas to plan for with PRH / YTJ data:

• Website fill rate varies. The website field is only what the company registered with PRH. Small or dormant firms often never registered one, so expect a partial fill rate — don’t treat a null website as “company has no site.”
• City comes back uppercased. The city value is typically all-caps (e.g. HELSINKI). Normalize casing before display or joining.
• Split huge segments. The API caps at ~100 per page and very large towns hold tens of thousands of companies. For a complete pull of a big segment, split the run by town, postcode, or registration-date range and merge the datasets afterward.
• Codes vs descriptions. Company form and NACE arrive as both a code and an English description. Filter and join on the stable code (companyFormCode, mainBusinessLineCode); descriptions can differ by language and are for humans.
• Business ID is the only stable join key. Names change and addresses get updated; the Y-tunnus does not. Key every downstream join on businessId.
• Address type matters. addressType distinguishes visiting from postal addresses. If you’re mapping physical locations, filter to the right type rather than assuming the first address is the office.

Wrapping up

Finland’s registry is one of the cleaner open-data sources in Europe, but the raw API hands you nested multi-language JSON that isn’t ready for a CRM or a warehouse. If you need it once, the endpoint is open — build the pagination and flattening yourself. If you need refreshed Finnish company lists on a cadence, let the actor handle the paging, language flattening, and de-duplication and hand you tabular rows.

▶ Run the Finland Company Registry Scraper on Apify — reads the official PRH/YTJ open data directly: business ID, company form, NACE industry, address and website, one clean row per company. No API key, no login. Start on Apify’s free monthly credit.