# Czech Company Registry & ARES Monitor (`automa-flow/czech-ares-company-change-monitor`) Actor

Monitor Czech companies by IČO in ARES. Track changes to name, status, address, legal form, DIČ and CZ-NACE across runs. Export supplier watchlist snapshots and changes.

- **URL**: https://apify.com/automa-flow/czech-ares-company-change-monitor.md
- **Developed by:** [Vadim Bezrukov](https://apify.com/automa-flow) (community)
- **Categories:** Business, Automation, Developer tools
- **Stats:** 2 total users, 1 monthly users, 100.0% runs succeeded, 0 bookmarks
- **User rating**: No ratings yet

## Pricing

$3.00 / 1,000 company checkeds

This Actor is paid per event. You are not charged for the Apify platform usage, but only a fixed price for specific events.

Learn more: https://docs.apify.com/actors/running/actors-in-store.md#pay-per-event

## What's an Apify Actor?

Actors are web data automations that power AI and operations. They run on the Apify platform to scrape websites, process data, connect APIs, and automate workflows.
In Batch mode, an Actor accepts a well-defined JSON input, performs an action which can take anything from a few seconds to a few hours,
and optionally produces a well-defined JSON output, datasets with results, or files in key-value store.
In Standby mode, an Actor provides a web server which can be used as a website, API, or an MCP server.
Actors are written with capital "A".

## How to integrate an Actor?

If asked about integration, you help developers integrate Actors into their projects.
You adapt to their stack and deliver integrations that are safe, well-documented, and production-ready.
The best way to integrate Actors is as follows.

- **AI agents and MCP clients** — the [Apify MCP server](https://docs.apify.com/integrations/mcp.md) at `https://mcp.apify.com` (remote, streamable HTTP, OAuth on first use).
- **Agentic workflows and local Actor development** — [Agent Skills](https://apify.com/.well-known/agent-skills/index.json) with the [Apify CLI](https://docs.apify.com/cli/docs.md): `npm install -g apify-cli`, then `apify login`.
- **JavaScript/TypeScript projects** — the official [JS/TS client](https://docs.apify.com/api/client/js/docs.md): `npm install apify-client`.
- **Python projects** — the official [Python client](https://docs.apify.com/api/client/python/docs.md): `pip install apify-client`.
- **Any other language** — the [REST API](https://docs.apify.com/api/v2.md).

For usage examples, see the [API](#api) section below.

For more details, see Apify documentation as [Markdown index](https://docs.apify.com/llms.txt) and [Markdown full-text](https://docs.apify.com/llms-full.txt).

# README

## 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

```json
{
  "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](https://apify.com/automa-flow/czech-ares-company-change-monitor/examples/czech-company-registry-lookup) | 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](https://apify.com/automa-flow/czech-ares-company-change-monitor/examples/sledovani-zmen-dodavatelu-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

```json
{
  "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.

```json
{
  "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.

```json
{
  "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:

```bash
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](https://mf.gov.cz/cs/ministerstvo/informacni-systemy/ares)
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`.

# Actor input Schema

## `companies` (type: `array`):

One Czech IČO per entry. Spaces, dots, dashes and a CZ prefix are normalized away, and short forms are zero-padded, so 177041, 00177041 and CZ00177041 are the same company. The check digit is deliberately not validated: real pre-1990s IČO predate that rule. A repeated IČO is fetched, charged and compared once.

## `monitorKey` (type: `string`):

Names the stored baseline this run compares against. Use one key per watchlist (for example suppliers-cz). Changing it starts a fresh baseline. Two runs sharing a key never run at the same time; the second waits or fails rather than corrupting the baseline.

## `mode` (type: `string`):

changesOnly returns the first-run baseline and, after that, only companies whose official record changed. snapshotAndChanges also returns every unchanged company's current record. Both modes check every company, and diagnostics for failed or rejected entries are always returned.

## `baselineMode` (type: `string`):

emitSnapshot returns every company's current record on the first run. storeOnly saves the baseline silently, so the first scheduled alert is a real change rather than a full export.

## Actor input object example

```json
{
  "companies": [
    "27074358",
    "CZ00177041",
    "45 274 649"
  ],
  "monitorKey": "suppliers-cz",
  "mode": "snapshotAndChanges",
  "baselineMode": "emitSnapshot"
}
```

# Actor output Schema

## `changes` (type: `string`):

One row per change type; unwinding omits rows with no change types, including baselines and diagnostics. Inspect RUN\_SUMMARY and the full results separately.

## `results` (type: `string`):

In snapshotAndChanges, one row per watched company. changesOnly suppresses unchanged observations; storeOnly can suppress the initial baseline. Diagnostic rows remain visible.

## `registrations` (type: `string`):

One row per ARES source register per company, with the state that register publishes.

## `diagnostics` (type: `string`):

Failure-focused columns for all rows; filter the status field client-side.

## `monitoring` (type: `string`):

Emitted baselines, changes and diagnostic rows without unwinding. Unchanged observations may be suppressed by the selected mode.

## `runSummary` (type: `string`):

No description

# API

You can run this Actor programmatically using our API. Below are code examples in JavaScript, Python, and CLI, as well as the OpenAPI specification and MCP server setup.

## JavaScript example

```javascript
import { ApifyClient } from 'apify-client';

// Initialize the ApifyClient with your Apify API token
// Replace the '<YOUR_API_TOKEN>' with your token
const client = new ApifyClient({
    token: '<YOUR_API_TOKEN>',
});

// Prepare Actor input
const input = {
    "companies": [
        "27074358",
        "00177041",
        "26168685"
    ],
    "monitorKey": "suppliers-cz",
    "mode": "snapshotAndChanges"
};

// Run the Actor and wait for it to finish
const run = await client.actor("automa-flow/czech-ares-company-change-monitor").call(input);

// Fetch and print Actor results from the run's dataset (if any)
console.log('Results from dataset');
console.log(`💾 Check your data here: https://console.apify.com/storage/datasets/${run.defaultDatasetId}`);
const { items } = await client.dataset(run.defaultDatasetId).listItems();
items.forEach((item) => {
    console.dir(item);
});

// 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/js/docs

```

## Python example

```python
from apify_client import ApifyClient

# Initialize the ApifyClient with your Apify API token
# Replace '<YOUR_API_TOKEN>' with your token.
client = ApifyClient("<YOUR_API_TOKEN>")

# Prepare the Actor input
run_input = {
    "companies": [
        "27074358",
        "00177041",
        "26168685",
    ],
    "monitorKey": "suppliers-cz",
    "mode": "snapshotAndChanges",
}

# Run the Actor and wait for it to finish
run = client.actor("automa-flow/czech-ares-company-change-monitor").call(run_input=run_input)

# Fetch and print Actor results from the run's dataset (if there are any)
print(f"💾 Check your data here: https://console.apify.com/storage/datasets/{run.default_dataset_id}")
for item in client.dataset(run.default_dataset_id).iterate_items():
    print(item)

# 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/python/docs/quick-start

```

## CLI example

```bash
echo '{
  "companies": [
    "27074358",
    "00177041",
    "26168685"
  ],
  "monitorKey": "suppliers-cz",
  "mode": "snapshotAndChanges"
}' |
apify call automa-flow/czech-ares-company-change-monitor --silent --output-dataset

```

## MCP server setup

```json
{
    "mcpServers": {
        "apify": {
            "type": "http",
            "url": "https://mcp.apify.com/?tools=fetch-actor-details,automa-flow/czech-ares-company-change-monitor"
        }
    }
}

```

The hosted server signs you in with OAuth on first connect, so no API token belongs in this config. Clients without OAuth support can send an `Authorization: Bearer <APIFY_API_TOKEN>` header instead, using a token from API & Integrations in Apify Console (https://console.apify.com/settings/integrations).

## OpenAPI specification

Download the OpenAPI definition: https://api.apify.com/v2/actors/pBzBgZNQnXm3Dy752/builds/ucegTXAsUmgEtsDLs/openapi.json