Czech Company Registry & ARES Monitor

Monitor Czech companies by IČO and receive only the ARES registry changes that mean something - legal name, entity status, legal form, registered address, VAT ID (DIČ), CZ-NACE activities and register participation - with a persistent baseline that a failed check never overwrites.

Give it 1–1,000 Czech company IDs, run it again with the same monitor key, and use the field-level differences to refresh a supplier list or CRM. Every row includes the official source URL, observation time and a per-company status. Download JSON, CSV or Excel from the Apify Dataset, or read it through the API.

Check your first three companies

{
  "companies": ["27074358", "00177041", "26168685"],
  "monitorKey": "suppliers-cz",
  "mode": "snapshotAndChanges",
  "baselineMode": "emitSnapshot"
}

Open the Actor, keep this example and click Start. In Output, expect three current company records: BASELINE on the first successful observation, then SNAPSHOT or CHANGE on later runs. The configured price is $0.009 for three verified checks. If a source check fails, its row explains why. No ARES API key or proxy is needed.

For a daily or weekly watchlist, keep the same monitorKey and switch mode to changesOnly. An unchanged successful check is still paid. A quiet run can have an empty Dataset; inspect RUN_SUMMARY for the verified counts.

Two example workflows

Start with one of these two published examples, then replace the sample company IDs.

Example	Use it for	Result
Czech Company Registry Lookup by IČO	Export a current supplier or CRM list	A current record for each verified company on every run; use the overview view
Sledování změn dodavatelů v ARES	Repeated supplier checks with a Czech-language example	Baseline on the first run, then changes and diagnostics; use the monitoring view

Both contain three public sample IČO. Replace those company IDs and choose one stable monitorKey per list. Keep the examples' monitor keys separate. Each example caps check fees at $0.009 for the three companies. Increase the cap deliberately when expanding the list; unchanged verified checks still count. For the monitor, zero rows on later runs can mean all three checks succeeded without a change: confirm the counts in RUN_SUMMARY. The examples do not create a schedule or webhook.

What it detects

Change type	Fires when
LEGAL_NAME_CHANGED	the registered business name (obchodní jméno) changes
ENTITY_STATUS_CHANGED	the derived status moves between ACTIVE, INACTIVE, SUSPENDED, FUTURE, MIXED or UNKNOWN
LEGAL_FORM_CHANGED	the legal-form code changes (for example s.r.o. to a.s.)
VAT_ID_CHANGED	a DIČ appears, disappears or changes, including VAT-group membership
ADDRESS_CHANGED	the canonical structured address or RÚIAN address-place code changes
NACE_CHANGED	CZ-NACE activities are added or removed, with added and removed lists
SOURCE_REGISTRATION_CHANGED	ARES reports a different participation state for a source register; this is not a direct VAT or insolvency check
INCORPORATION_DATE_CHANGED	the registration date is corrected
TERMINATION_DATE_CHANGED	a termination date appears or moves
NOT_FOUND	ARES no longer returns a previously observed IČO; this alone does not establish why it disappeared
FOUND	an IČO that was absent now has a record

Order-only changes never fire: NACE codes and register lists are sorted and deduplicated before comparison, and datumAktualizace is carried as provenance but deliberately excluded from change detection, because ARES advances it when it touches a record it did not change.

Who uses it

• Procurement and supplier management - keep a vendor master current, and see a supplier's name, seat or legal form change before the next purchase order.
• Finance, AP and credit control - watch counterparty status and DIČ across a ledger of Czech companies.
• CRM and data operations - schedule a refresh of Czech accounts and ingest only the deltas.
• B2B enrichment pipelines - use it as a Czech company registry monitor behind an ETL job, with stable ids and fingerprints in every row.
• Czech-market researchers - keep a longitudinal record of a company set.

30-second quickstart

{
  "companies": ["27074358", "00177041", "26168685"],
  "monitorKey": "suppliers-cz",
  "mode": "changesOnly"
}

The first run under a monitor key returns the current record for every company and stores the baseline. Every later run with the same key returns only the companies whose official record changed. Nothing else to configure: IČO lookup accepts 27074358, CZ27074358, 45 274 649 and 177041 alike.

Sample change output

Illustrative, shortened example with synthetic company details; it does not assert that a real company moved or changed activities.

{
  "record_type": "CHANGE",
  "status": "SUCCESS",
  "monitor_key": "suppliers-cz",
  "ico": "10000001",
  "business_name": "Vzorová společnost, a.s.",
  "entity_status": "ACTIVE",
  "legal_form": "Akciová společnost",
  "legal_form_code": "121",
  "vat_id": "CZ10000001",
  "registered_address": "Budějovická 778/3a, Michle, 14000 Praha 4",
  "canonical_registered_address": "Budějovická 778/3a, Michle, 14000 Praha, Česká republika",
  "change_types": ["ADDRESS_CHANGED", "NACE_CHANGED"],
  "changes": {
    "registered_address": {
      "previous": "Na Pankráci 1683/127, Nusle, 14000 Praha, Česká republika",
      "current": "Budějovická 778/3a, Michle, 14000 Praha, Česká republika"
    },
    "nace_codes": {
      "previous": ["62010"],
      "current": ["62010", "63110"],
      "added": ["63110"],
      "removed": []
    }
  },
  "source": "cz_ares_ekonomicke_subjekty",
  "source_id": "10000001",
  "source_url": "https://ares.gov.cz/ekonomicke-subjekty-v-be/rest/ekonomicke-subjekty/10000001",
  "source_last_updated_at": "2026-09-03",
  "observed_at": "2026-09-07T06:00:00Z",
  "schema_version": 2,
  "fingerprint": "3f5c…"
}

examples/sample_output.json holds a full run: a baseline, a change, an unverified check and a rejected input, all in the one column set.

Supplier watchlist example

One monitor key per watchlist. Up to 1,000 IČO per run, checked in batches of 100 against the register's own exact-match endpoint.

{
  "companies": [
    "27074358", "00177041", "26168685", "45274649",
    "45244782", "60193336", "00006947", "00123562"
  ],
  "monitorKey": "accounts-payable-prod",
  "mode": "changesOnly",
  "baselineMode": "storeOnly"
}

baselineMode: "storeOnly" saves the first-run baseline silently, so the first alert your team sees is a real Czech company change rather than a full export. Use separate monitor keys for separate watchlists - suppliers-cz, customers-cz, prospects-cz - and they never interfere with each other. A repeated IČO is fetched, charged and compared once.

Scheduling and webhooks

Use a daily or weekly schedule. ARES aggregates upstream registers; the observation time tells you when this Actor checked ARES, not when an upstream authority made a change. Avoid rapid polling and overlapping schedules.

1. Save your watchlist as a Task and create a daily or weekly schedule with mode: "changesOnly" and a stable monitorKey.
2. Add a Run succeeded webhook to your integration endpoint. The notification contains resource.defaultDatasetId; your integration then fetches its rows:

GET https://api.apify.com/v2/datasets/<defaultDatasetId>/items?clean=true&format=json
Authorization: Bearer <your Apify token>

3. Send business alerts only for record_type == "CHANGE" with status of SUCCESS or NOT_FOUND. Route SOURCE_FAILED, PARTIAL, INVALID_INPUT and SKIPPED to a separate operational notification.

A non-empty Dataset can contain a baseline or diagnostics. Dataset views select columns; they do not apply these alert filters. Retrieve RUN_SUMMARY from the run's default KVS for counts, budget limits and recovery_only. Recovery rows retain their original timestamps; deduplicate if you also consume failed runs.

Pricing

Configured pricing: pay per verified company check, with platform usage included and no separate start fee.

Event	Price	Charged
Company checked	$0.003 per company	once per unique IČO the register returned a complete current record for

A verified check is the product, so an unchanged company is charged once even though changesOnly writes no row for it - that check is what lets the next run tell you nothing changed.

Never charged: internal retries, source failures, truncated responses, invalid IČO, an IČO listed twice, authoritative NOT_FOUND results, discarded watchlist anomalies, recovered delivery of saved observations, or companies beyond the run's charge limit.

Verified companies	Maximum check fee per run	30 daily runs
1	$0.003	$0.09
10	$0.030	$0.90
100	$0.300	$9.00
1,000	$3.000	$90.00

Set maxTotalChargeUsd in Apify run options to cap the bill. The minimum selectable cap is $0.003; the default is $3.00 for the 1,000-company input ceiling. Apify may return a lower effective cap because of account limits; the Actor respects that returned cap. The Actor selects the affordable input prefix before fetching. The remainder receives SKIPPED rows and keeps its previous baseline. Capacity freed by a NOT_FOUND or failed check is not reused for later entries in that run; rerun the remaining entries with an appropriate cap.

Prices apply equally to all plans; no subscription tier discount is configured. ARES itself is free to query. The paid product is normalized watchlist checking, persistent comparison state and ready-to-use changes. Check the Pricing tab for the current configured price before running.

Failure semantics

Three states that other registry tools tend to collapse are kept apart here:

NO CHANGE  !=  NOT_FOUND  !=  SOURCE_FAILED

status	Meaning
SUCCESS	ARES returned a complete current record. A record_type of SNAPSHOT with an empty change_types means no change.
NOT_FOUND	ARES conclusively has no record for this IČO.
PARTIAL	The observation was discarded by a watchlist-wide safety check. Nothing was concluded.
SOURCE_FAILED	The register could not be verified: timeout, rate limit or 5xx after the retry budget, a malformed body, an HTML error page, or a short page.
INVALID_INPUT	The entry is not a Czech IČO. Rejected before any request is sent.
SKIPPED	The run's charge limit could not fund this check.

What follows from that:

• A failed check never overwrites a good baseline. The stored observation is carried forward untouched and the next run compares against it.
• A failed check never becomes a change. No NOT_FOUND event is invented from a timeout.
• One failure never invalidates the rest. Batches fail independently; a company answered in another batch still advances.
• A short page is a failure, not an absence. The register paginates at 20 by default; every response is checked against the count ARES itself reports, and a mismatch fails the batch rather than striking off the missing companies.
• A watchlist cannot collapse quietly. If most companies with a stored baseline suddenly go missing, lose active status, or lose their name and address at once, the run reports PARTIAL, emits no change, keeps every baseline and says so in the run status message.
• State is saved or the run fails. If the baseline cannot be written, the run fails rather than claiming the monitor advanced.
• Malformed fields are unverified. A wrong field type or a missing business name produces SOURCE_FAILED for that company, with no charge or state update. A record without a usable identity makes the whole batch unverified; it never proves that a watched company disappeared.
• Unacknowledged output can be recovered. The baseline and a bounded copy of that run's emitted rows are saved atomically. Delivery is acknowledged only after the Dataset, summary and baseline are durable. If acknowledgment is missing, recovery returns those exact rows with their original timestamps, without new ARES checks or charges. RUN_SUMMARY.recovery_only=true identifies this recovery run; run again to perform a fresh check. Acknowledged output is not automatically replayed. The latest journal remains in the monitor state for inspection. Acknowledgment confirms saved data, not delivery of a webhook or the later platform run status. If a run fails after acknowledgment, inspect its existing Dataset and summary; downstream integrations should reconcile failed runs too.
• Two runs on one monitor key never overlap. The second waits or fails rather than writing from a stale baseline.

After an interrupted run, the fail-closed lock may require manual recovery: stop all runs using that monitor key, then remove only its marker from the czech-ares-company-monitor-locks request queue (the failed run's status message identifies its unique key). Keep the named KVS state and its pending delivery. Start a new run with the same monitor key to recover the saved output. Resurrecting an incomplete delivery in the same run is refused to avoid duplicate charges and ambiguous Dataset writes; completed delivery reuses its existing Dataset. Consumers reading failed-run Datasets as well as successful ones should deduplicate replayed observations by monitor_key, source_id, observed_at and fingerprint.

Private builds through 0.1.3 used version-1 delivery receipts requiring access to another run's status. New builds fail closed on those receipts. Before migrating an existing private monitor, stop its runs and have the account owner verify the receipt's run: keep all company state, rows and summary, set receipt version=2 and phase=COMPLETE only for a confirmed SUCCEEDED run with a complete delivery checkpoint; use phase=PENDING for a terminal failed, aborted or timed-out run. An unavailable or still active run must be investigated before migration. Never delete the baseline to resolve a permissions error. New monitors need no migration.

Data and source limitations

• ARES is an aggregate of Czech public registers. A change is visible here when ARES publishes it, not at the moment it is recorded by a court or authority.
• entity_status is a mechanical summary of three core registers (ROS, VR, RES). ACTIVE means every core register that knows the company says active; MIXED means they disagree, which commonly indicates liquidation or winding-up. Read source_registrations for what each register actually said.
• termination_date may be empty. A missing ARES record does not independently prove dissolution, insolvency or a legal restriction.
• The IČO check digit is not validated. Real pre-1990s IČO predate that rule
  • 00123562 is live in ARES today and fails it - so existence is left to the register to decide.
• Only the current CZ-NACE (2025) classification is carried. The superseded CZ-NACE 2008 list describes the same activities and would report one reclassification twice.
• legal_form is resolved from the official ARES dictionary and is presentation only. If the dictionary is briefly unavailable the field falls back to the code, and change detection - which uses legal_form_code - is unaffected.
• Schema version 2 adds canonical_registered_address for address comparison. registered_address keeps the source's display text. Removing or restoring that text does not create a relocation when the structural address is unchanged. Text-only addresses still use source text. Existing baselines are preserved; on their first version-2 check, matching RÚIAN codes or matching display text prevent a change caused solely by normalization. Legacy records without either comparison anchor retain text comparison for that first check.
• Directors, shareholders and beneficial owners are not collected. ARES also contains sole traders: a business name, registered seat or DIČ can be personal data. Choose a watchlist and retention period appropriate to your purpose.
• Companies with no assigned IČO exist in ARES under an ARES_… identifier. They cannot appear in an IČO watchlist and are ignored.

API and MCP usage

Start a run through the authenticated Apify API:

curl -X POST "https://api.apify.com/v2/acts/automa-flow~czech-ares-company-change-monitor/runs?maxTotalChargeUsd=0.006&memory=512&timeout=120" \
  -H "Authorization: Bearer $APIFY_TOKEN" \
  -H 'content-type: application/json' \
  -d '{"companies":["27074358","00177041"],"monitorKey":"suppliers-cz","mode":"changesOnly"}'

The response contains the run ID. Wait for a terminal run status, then fetch defaultDatasetId and defaultKeyValueStoreId. On success inspect RUN_SUMMARY as well as the rows; a completed run can still contain individual failures.

Permissions and MCP: this Actor uses limited permissions for its own Dataset, KVS and lock queue. Repeat checks and recovery use a durable output acknowledgment in the monitor's KVS; they do not read another run or require account-wide access. Each customer's monitoring state belongs to their account. Authenticated MCP initialization and the Actor tool's input schema have been verified with tools/list. MCP execution and agentic payments are not yet verified. Regular authenticated API use is the validated execution path.

The direct MCP address for authenticated clients is:

https://mcp.apify.com?tools=automa-flow/czech-ares-company-change-monitor

Connect using your own Apify account. Direct authenticated tool access and public input/output schema retrieval are verified; search ranking can vary.

Output surfaces: monitoring for baselines and diagnostics, the changes dataset view for alerts, registrations for per-register state, diagnostics for anything unverified, and RUN_SUMMARY in the key-value store for run health.

Legal and source disclaimer

ARES (Administrativní registr ekonomických subjektů) is public registry information published by the Czech Ministry of Finance. This Actor reads only that public information over the official documented REST API. It does not bypass authentication, paywalls or access controls, uses no proxy or browser, and solves no CAPTCHA.

Every row records what one public register said at one moment, with its source URL and timestamp. It is not a creditworthiness assessment, a due-diligence or sanctions check, or a statement about whether it is advisable to trade with a company. Interpreting the registry data, and any decision taken on it, remains yours. Verify anything material against the official record before acting on it.

This is an independent integration, not a Czech government service. ARES DIČ and registration flags are not VIES VAT validation, an ADIS unreliable-payer check or an ISIR proceedings search. Consult the official ARES service and access conditions for the source's scope and restrictions.

Stored data and retention

The named KVS czech-ares-company-change-monitor-state stores the latest verified baseline and pending delivery rows in your Apify account. Run Datasets hold the observations that were emitted. The Actor does not send them to another service or log watchlist identifiers. The monitor key is a namespace within your account, not an access-control boundary between teams sharing that account.

Entries no longer watched are pruned after 90 days when that monitor runs again; this is not an automatic expiry for an abandoned monitor. Active baselines stay available for future comparison. Manage Dataset retention in Apify, and delete the relevant ARES_MONITOR_STATE_V1_<hash> KVS record when retiring a watchlist. Stop its runs first. Deleting comparison state starts a new baseline next time.

Support

Use the Actor's Issues tab. Include the run ID, error code and a sanitized input example; omit tokens and private watchlists. No response-time SLA is advertised.

Technical source details

• Source: https://ares.gov.cz/ekonomicke-subjekty-v-be/rest - the official Czech business registry API, OpenAPI 3.0, no authentication.
• Endpoint: POST /ekonomicke-subjekty/vyhledat with an exact ico filter, the register's documented maximum of 100 IČO per request. The single-record GET endpoint returns byte-identical data, so this Actor uses one code path. POST /ciselniky-nazevniky/vyhledat is called once per run for the legal-form dictionary.
• Never fuzzy. Only exact IČO matching. Name search is never used to resolve a watchlist entry.
• Transport: HTTP only, httpx, one shared client per run, at most 3 requests in flight. No browser, no proxy, no cookies. Retries are bounded at 3 attempts with exponential backoff and jitter, and Retry-After is honoured. The ARES access conditions restrict excessive, repeated and invalid traffic. A successful 1,000-company run without retries makes 11 requests including the legal-form dictionary; retries add requests. Space scheduled runs apart.
• State: Apify key-value store only, one record per monitor key under ARES_MONITOR_STATE_V1_<hash>, holding the last successful observation and its fingerprint per company. No database. Run datasets are the history.
• Fingerprint: SHA-256 over the semantic fields only, using the canonical address in schema version 2. Compare fingerprints within the same schema version. Run metadata, observation time, the register's own update date and the legal-form name are excluded, so equal fingerprints across runs really do mean nothing changed.
• Notification feed: ARES publishes ekonomicke-subjekty-notifikace batches. They were evaluated live and found complete on the sample tested, but they carry no field-level detail, lag one to two days behind the record, and would save well under a cent per run against the cost of cursor state, gap handling and replay idempotency. Direct exact re-fetching of the whole watchlist is used instead. The evaluation is recorded in experiments/czech-ares-company-monitor/README.md.