Polish Premises Prospector - Site-Level REGON (jednostki lokalne)

Build B2B prospect lists in Poland at the individual physical-site level - one row per premise (jednostka lokalna), not just the registered company HQ. Seed a company and this actor expands it into every physical location registered in the official GUS REGON registry, with the attributes you need to filter and prioritize: per-site industry (PKD), full address, region (TERYT), company age, ownership, and an optional per-site headcount signal.

No login, no API key, nothing to configure - it reads the public REGON registry anonymously (it does not use the registered BIR web-service key).

Why site-level?

REGON registers local units (jednostki lokalne) separately from the legal entity. Each gets its own 14-digit REGON, its own address, and its own PKD activity. A bank has hundreds of branches; a manufacturer has plants and warehouses at different addresses. Filtering the legal entity alone only ever returns the HQ - this actor returns the actual workplaces, one row per premise plus the HQ, ready for CSV/Excel/API.

What you get (one row per premise)

regon14, parentRegon, nip, krs, isHeadquarters, name, companyName, addressText, voivodeship, powiat, gmina, city, postalCode, street, buildingNumber, apartmentNumber, terytWoj/terytPowiat/terytGmina, pkdMainCode, pkdMainName, pkdAll, siteStartDate, companyRegistrationDate, companyAgeYears, legalForm, ownershipForm, website, localUnitsCount, and (when headcount enrichment is on) headcountEstimate, headcountLow, headcountHigh, headcountBasis, headcountMethod, headcountSource, linkedinCityCount, headcountCaveat, plus scrapedAt, dataSource.

How do I use it?

Seed one or more companies and let the actor expand them into premises:

{ "seedIdentifiers": ["5260250995"], "regions": [], "siteTypes": [] }

Filter to a region and site type - e.g. clinics in Warsaw:

{ "seedIdentifiers": ["..."], "regions": ["warszawa"], "siteTypes": ["clinic"] }

Or chain from a discovery run: point seedDatasetId at a polish-regon-scraper by-address/by-PKD search and this actor expands every result into its sites.

How much does it cost?

Pay per event - the pricing reflects the work done, not just rows: a charge per company expanded, per premise returned, and (only if you enable it) per headcount enrichment. The LinkedIn headcount overlay carries its own small per-company-city cost (the building-footprint method uses free OpenStreetMap data and adds no helper cost). See the Pricing tab on this page for the exact current figures, and bound optional LinkedIn spend with maxEnrich. No subscription, no minimum.

Input options

Field	Description
seedIdentifiers	List of NIP / REGON / KRS (auto-detected by shape).
seedDatasetId	Apify dataset ID to read identifiers from (chain in a regional search / KRS export).
seedIdType	How to read 10-digit ids (auto / nip / regon / krs). NIP and KRS are both 10 digits.
regions	Presets warszawa, lodz, kutno, or { "woj": "10", "powiat": "03" }. Empty = all Poland.
siteTypes	factory, warehouse, clinic, school, coliving. Empty = all industries.
pkdCodes	Explicit PKD prefixes, e.g. "86", "8610", "5210B".
fetchSitePkd	Fetch each premise's own PKD (one extra call/premise). Off = inherit company PKD.
includeHeadcount	Attach a per-site headcount signal (footprint for industrial, LinkedIn for white-collar).
headcountMethod	auto (default), footprint, linkedin, or none.
maxResults, minIntervalMs	Output cap and politeness delay between requests.

Discovery: how to seed a regional list

1. The companion polish-regon-scraper actor (recommended) - run a by-address / by-PKD discovery there, then pass its dataset id as seedDatasetId. This actor reads nip/regon/krs from each item.
2. A KRS export or your own prospect list - drop the identifiers into seedIdentifiers.
3. A paid GUS bulk data order - the cleanest way to get the full local-unit universe for a region (statistical confidentiality applies, so no headcount).

Headcount (read this)

No source publishes a verified per-site headcount for Poland - REGON's employment figure is legally confidential. So instead of pretending otherwise, every enriched row carries a headcountBasis telling you exactly how much of the number is sourced vs modeled:

headcountBasis	What it means	Method	Best for
reported-proxy	A real, sourced count (a tally of actual LinkedIn profiles for the company in that city)	LinkedIn employees-by-city	Offices, clinics, schools, universities
modeled-estimate	A number we compute (building footprint ÷ employment density, ±50-100%)	OSM footprint	Factories, warehouses, DCs
(none, unknown)	No signal available	-	-

headcountMethod=auto routes white-collar site types to the LinkedIn city-count (the primary, sourced signal). For each company the canonical LinkedIn page is resolved first by name, then by website domain if the legal name is too far from the brand; a low-confidence match is rejected (unknown) rather than returned as a wrong number. Employees are then counted by the resolved URL, filtered to the site's city. Caveats: it is a per-city count (not split between two sites in the same city) and undercounts blue-collar sites.

For industrial site types (factory/warehouse/DC), where LinkedIn is blind, auto routes to the building-footprint method - the only realistic per-site number. It geocodes the site address, reads the building's floor area from OpenStreetMap, and divides by an employment-density factor (warehouse ~80, manufacturing ~40 m²/FTE; UK Employment Densities Guide) × building levels. The result is flagged modeled-estimate with a ±50-100% band (headcountLow/headcountHigh), because the floor area is sourced but the people figure is computed, not reported. It uses only free OSM APIs; if no building can be resolved, the row is left unknown rather than guessed. Data © OpenStreetMap contributors (ODbL).

Coverage notes

• Strong: factories (PKD 10-33), warehouses/distribution (52, 46), private clinics (86), private schools/universities (85) - these commonly register premises as local units.
• Weak: co-living - buildings are not entities; only the operator's declared premise (PKD 55/68) may appear. Expect partial coverage.
• Only legal entities (Typ = P) are expanded; sole-proprietor businesses are skipped.

Permissions

This actor requests full permissions because its optional LinkedIn headcount enrichment orchestrates third-party LinkedIn actors, and calling them requires it. The actor only runs those actors and writes its own dataset - it does not read or modify any other data in your account. If you don't use LinkedIn headcount, the core REGON extraction and the free OSM building-footprint headcount work the same.

Run it from code

# cURL - start a run and get the dataset back
curl -X POST "https://api.apify.com/v2/acts/regdata~polish-premises-prospector/run-sync-get-dataset-items?token=YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "seedIdentifiers": ["5260250995"] }'

// Node.js - apify-client
import { ApifyClient } from 'apify-client';
const client = new ApifyClient({ token: 'YOUR_TOKEN' });
const run = await client.actor('regdata/polish-premises-prospector').call({ seedIdentifiers: ['5260250995'] });
const { items } = await client.dataset(run.defaultDatasetId).listItems();

Integrations

Runs anywhere Apify does: call it from the REST API, schedule recurring list builds, pipe results into n8n / Make / Zapier or your CRM, or use it from any MCP client (Claude, Cursor) via mcp.apify.com.

FAQ

Is it legal? Yes. It reads the public GUS REGON registry (official Polish statistical business registry) and, optionally, public LinkedIn city counts and OpenStreetMap building data. Extraction of this public data is permitted; you remain responsible for lawful, GDPR-compliant use of any personal data downstream.

Do I need a REGON/BIR API key? No. It reads the public registry anonymously - no key, no registration.

Why "site-level" instead of company-level? Because filtering a legal entity only ever returns its registered seat. Local units (jednostki lokalne) are the actual workplaces - branches, plants, warehouses - each with its own address and activity.

Can I trust the headcount number? Read headcountBasis. A reported-proxy is a real sourced count; a modeled-estimate is computed (with a ±50-100% band and a caveat). Where there's no signal, we return unknown rather than a guess.

Where do I get companies to seed? From the companion polish-regon-scraper (by-address / by-PKD discovery), a KRS export, or your own list. See "Discovery" above.

What export formats are supported? JSON, CSV, Excel, or XML, or read live via the API.

Source

Data: GUS REGON BIR (official Polish statistical business registry), read anonymously; optional public LinkedIn city counts and OpenStreetMap building data for headcount.

Related actors

Part of a suite of official government registry actors - no public API, pay per result, no keys to supply.

Country	Actors
Poland	REGON/GUS · KRS financials · KRS board · CRBR UBO · KRZ debtors · MSiG gazette · KNF · PEP · EKW land · UOKiK · BDO waste · Premises (this actor)
Germany	Handelsregister · Insolvency
Spain	Company directory · BORME acts · Concursal
Italy	Registro Imprese · PEC lookup
Austria	WKO directory · Ediktsdatei
France	Societe.com
Belgium	KBO/BCE
Czechia	ISIR insolvency
Slovakia	RPVS UBO
UAE	ADGM register
USA	California SoS · California UCC liens
Global	Adverse media

Common combination: discover companies with REGON -> expand to sites (this actor) -> enrich or screen with the rest of the suite.

Full suite: apify.com/regdata · Callable from any MCP client via mcp.apify.com