# Romanian Registry Change Monitor — New Firms & Status Changes (`darknezz/ro-registry-change-monitor`) Actor

Monitors the Romanian company registry (ONRC) for new registrations, deregistrations and status flips in a target CAEN sector. Run daily and consume only the changes since a date. Emits cui, company\_name, caen, county, event\_type, status\_before, status\_after, event\_date, source\_url.

- **URL**: https://apify.com/darknezz/ro-registry-change-monitor.md
- **Developed by:** [Oaida Adrian](https://apify.com/darknezz) (community)
- **Categories:** Business, Lead generation
- **Stats:** 2 total users, 1 monthly users, 100.0% runs succeeded, 0 bookmarks
- **User rating**: No ratings yet

## Pricing

from $10.00 / 1,000 result records

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

## Romanian Registry Change Monitor (ONRC) — CAEN-Sector Change Feed

Monitor the **Romanian company registry (ONRC)** for changes in a target
**CAEN activity sector**: new registrations, deregistrations, and status
flips (funcțiune / insolvență / dizolvare / lichidare / radiată / …).
A scheduled monitor — run it daily or weekly and consume **only what
changed** since a date, instead of re-pulling the whole registry.

Built for the recurring-revenue slot in the Romanian business-data niche:
directory lookups are one-shot, a change feed is something customers
schedule.

### What it does

For the requested CAEN code (default `6201` — software development), the
actor emits one dataset item per change:

| Field | Meaning |
|---|---|
| `cui` | Company fiscal code (CUI) |
| `company_name` | Registered company name |
| `caen` | Matched CAEN code (version-resolved) |
| `county` | County (județ) |
| `event_type` | `NEW_REGISTRATION` / `DEREGISTRATION` / `STATUS_CHANGE` |
| `status_before` | Previous status (null for new registrations) |
| `status_after` | New status (null-able) |
| `event_date` | Registration date (new) or dump date (status changes) |
| `source_url` | Where the record came from |

Plus `source`, `caen_requested`, and `detected_at` for provenance.

### How it works — two layers

**1. Live freshness layer (cuiscan.ro public API).**
New registrations get sequentially-allocated CUI numbers, so the newest
firms sit at the top of the CUI range. The actor probes a CUI window
(default anchored just above the observed Aug-2026 frontier) and reports
firms whose declared CAEN matches the requested sector and whose
registration date is `>= since`. This is what makes `since` dates inside
the current month return records while the official dump lags.

**2. Official dump delta layer (data.gov.ro monthly ONRC open data).**
Every month ONRC publishes a full-registry snapshot (`od_firme.csv`,
`od_caen_autorizat.csv`, `od_stare_firma.csv`). The actor streams the
newest dump filtered to the target CAEN codes, diffs it against the
last-seen snapshot stored in the key-value store, and emits exactly the
changes — the authoritative source for `STATUS_CHANGE` and
`DEREGISTRATION`. Idempotent: a dump is processed once (keyed by dump id),
and when the newest dump predates `since` the layer is skipped entirely.

**CAEN version aliasing.** The registry migrated from CAEN v2 to v3;
"software la comandă" is `6201` in v2 and `6210` in v3 (same activity name
in the official `n_caen.csv`). The actor resolves the requested code to all
codes sharing its activity name across versions, so `caen: 6201` also
matches v3-coded firms.

### Input

| Field | Type | Default | Description |
|---|---|---|---|
| `caen` | string | `6201` | Target CAEN activity code. Version-equivalent codes matched automatically. |
| `since` | string | last 30 days | Report only changes with `event_date >=` this date (`YYYY-MM-DD`). |
| `county` | string | — | Restrict to one county (e.g. `Cluj`, `Bucuresti`). Empty = all. |
| `output` | string | `json` | `json` = one item per change; `table` = same records plus a human-readable `summary` field. |
| `maxItems` | int | `100` | Max change records emitted per run. |
| `probeBudget` | int | `1500` | Max CUI probes in the live layer per run. |
| `frontierStart` | int | `55449500` | CUI anchor for the first live probe (see frontier note below). |
| `useLiveLayer` | bool | `true` | Enable the cuiscan freshness probe. |
| `useDumpLayer` | bool | `true` | Enable the official dump delta layer. |

Example input:

```json
{
  "caen": "6201",
  "since": "2026-08-12",
  "output": "json",
  "maxItems": 100
}
```

### Frontier note (important for scheduling)

New companies get the next available CUI number, so the frontier moves
up over time. The actor keeps a **frontier cursor** in its named KV store:
the first run probes *downward* from `frontierStart` (default anchored just
above the observed Aug-2026 frontier) to cover the recent window; later
runs probe *upward* from the last-known frontier, catching only newly
allocated CUIs — efficient daily monitoring without re-probing history.

If the registry outgrows the default anchor (months from now), raise
`frontierStart` above the newest CUI you know, or clear the actor's KV
store to force a fresh downward sweep.

### Output

One dataset item per change (see table above). Nothing is emitted when
nothing changed in the window. Example:

```json
{
  "cui": 55449288,
  "company_name": "PIXELMAN GAMING S.R.L.",
  "caen": "6210",
  "county": "MUNICIPIUL BUCUREŞTI",
  "event_type": "NEW_REGISTRATION",
  "status_before": null,
  "status_after": "funcțiune",
  "event_date": "2026-08-18",
  "source_url": "https://cuiscan.ro/api.php?action=company&cui=55449288",
  "source": "cuiscan",
  "caen_requested": "6201",
  "detected_at": "2026-08-19T09:00:00.000000+00:00"
}
```

### Use cases

- **Lead generation** — new companies in a sector = fresh prospects
  (software shops registering this week, etc.).
- **Insolvency / risk monitoring** — status flips (funcțiune →
  insolvență) for a watchlist sector.
- **Market intelligence** — deregistrations and new entrants per CAEN.

### Idempotency & re-runs

- The **emitted-set** in the named KV store (`ro-registry-change-state`)
  prevents duplicate emission across runs with the same `since` date.
- The **frontier cursor** makes consecutive runs probe only new CUIs.
- The **dump snapshot** is keyed by dump id, so a dump is never processed
  twice.

### Pricing

Pay per event — `result` per change record emitted (set at launch; this
build is held private until Adrian decides). Nothing emitted, nothing
charged beyond the actor start.

### Limitations

- The live layer relies on cuiscan.ro's public API, which rate-limits
  aggressive probing — the actor paces probes (~0.4 s) and budgets its
  window per run. Very wide `since` windows with a small `probeBudget` may
  not cover the whole window in one run; the frontier cursor covers the
  rest on subsequent runs.
- Status changes and deregistrations come from the monthly ONRC dump, so
  they reflect the latest published dump, not intra-month flips.
- The official dump is published monthly; when it predates `since`, only
  the live layer contributes records for that window.

# Actor input Schema

## `caen` (type: `string`):

Target CAEN activity code, e.g. 6201 (software development). Version-equivalent codes are matched automatically (6201 v2 == 6210 v3).

## `since` (type: `string`):

Only report changes with event\_date >= this date (YYYY-MM-DD). When empty, the last 30 days are used.

## `county` (type: `string`):

Restrict to firms in one county, e.g. Cluj or Bucuresti. Empty = all counties.

## `output` (type: `string`):

json: one dataset item per change record. table: same records plus a human-readable summary field.

## `maxItems` (type: `integer`):

Maximum number of change records emitted per run.

## `probeBudget` (type: `integer`):

Maximum CUI numbers probed in the live freshness layer per run. Larger budgets cover wider windows but take longer and may hit the source rate limit.

## `frontierStart` (type: `integer`):

CUI to start probing from on the FIRST run (new registrations get higher CUIs; the probe walks down from this anchor to cover the recent window, then the frontier cursor advances automatically on later runs). Default is anchored just above the observed Aug-2026 frontier; raise it as the registry grows.

## `useLiveLayer` (type: `boolean`):

Probe recent CUIs via cuiscan.ro to catch registrations since the newest official dump. Required for same-month `since` dates.

## `useDumpLayer` (type: `boolean`):

Diff the newest monthly ONRC open-data dump against the last seen snapshot for authoritative status changes and deregistrations.

## Actor input object example

```json
{
  "caen": "6201",
  "since": "",
  "county": "",
  "output": "json",
  "maxItems": 100,
  "probeBudget": 1500,
  "frontierStart": 55449500,
  "useLiveLayer": true,
  "useDumpLayer": true
}
```

# Actor output Schema

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

No description

## `cui` (type: `string`):

No description

## `company_name` (type: `string`):

No description

## `caen` (type: `string`):

No description

## `county` (type: `string`):

No description

## `event_type` (type: `string`):

No description

## `status_before` (type: `string`):

No description

## `status_after` (type: `string`):

No description

## `event_date` (type: `string`):

No description

## `source_url` (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 = {
    "caen": "6201",
    "since": "",
    "county": "",
    "output": "json"
};

// Run the Actor and wait for it to finish
const run = await client.actor("darknezz/ro-registry-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 = {
    "caen": "6201",
    "since": "",
    "county": "",
    "output": "json",
}

# Run the Actor and wait for it to finish
run = client.actor("darknezz/ro-registry-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 '{
  "caen": "6201",
  "since": "",
  "county": "",
  "output": "json"
}' |
apify call darknezz/ro-registry-change-monitor --silent --output-dataset

```

## MCP server setup

```json
{
    "mcpServers": {
        "apify": {
            "type": "http",
            "url": "https://mcp.apify.com/?tools=fetch-actor-details,darknezz/ro-registry-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/8XTTvgQIkcxRoGLeT/builds/sd2apneREt5eJcamu/openapi.json