# Austria Insolvency Scraper — Ediktsdatei Konkurs + Verwalter (`scrapersdelight/edikte-insolvency-at-scraper`) Actor

Scrape Austria's official Insolvenzdatei (edikte.justiz.gv.at): newly opened company insolvencies with Firmenbuchnummer, court, case number, address, the Masseverwalter's name, e-mail and phone, the creditor claims deadline and the first hearing. Filter by date, Bundesland, court and type.

- **URL**: https://apify.com/scrapersdelight/edikte-insolvency-at-scraper.md
- **Developed by:** [Scrapers Delight](https://apify.com/scrapersdelight) (community)
- **Categories:** Lead generation, Business, Automation
- **Stats:** 3 total users, 2 monthly users, 100.0% runs succeeded, 0 bookmarks
- **User rating**: No ratings yet

## Pricing

$3.00 / 1,000 per insolvency returneds

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

## 🇦🇹 Austria Insolvency Scraper — Ediktsdatei Konkurs + Masseverwalter

Scrape Austria's **official insolvency register** — the Insolvenzdatei inside the Justiz
Ediktsdatei (`edikte.justiz.gv.at`) — and get newly opened **company** insolvencies as clean lead
rows: Firmenbuchnummer, court, case number, address, the **Masseverwalter's name, e-mail and
phone**, the **creditor claims deadline**, and every scheduled hearing.

No login, no API key, no cookie. Public court data, published by the Republic of Austria.

***

### 🤔 What does this actor do?

It runs the register's own search, opens each case document, and gives you one row per case:

- 🏢 **Company** — name, **Firmenbuchnummer** (the join key to Austria's company register), street, postcode, town
- ⚖️ **Court** — Dienststelle, its register code, the Bundesland, and the Aktenzeichen
- 📋 **Proceeding** — Konkursverfahren · Sanierungsverfahren mit/ohne Eigenverwaltung · Konkurseröffnungsverfahren
- 👤 **The administrator** — **Masseverwalter / Sanierungsverwalter name, e-mail, phone, fax and practice address**, plus the deputy where one was appointed
- ⏰ **The deadlines** — opening effective date, **Anmeldungsfrist** (creditor claims deadline) and days remaining
- 📅 **The hearings** — every Tagsatzung with date, time, courtroom and purpose, with superseded ones flagged
- 🚦 **Case state** — business continued or ordered shut, main proceeding under the EU regulation, self-administration, refused for lack of funds, estate insufficient, legally final, appeal lodged, proceeding closed
- 📈 **Restructuring plan** — the offered quota (%) and its terms, when there is one
- 🗂️ **The whole document** — every labelled section verbatim, plus the case's full publication history

Filter by date window, Bundesland, court district, individual court, proceeding type, debtor name,
postcode, claims-deadline window, and whether the administrator published an e-mail.

***

### 🎯 Who buys this data

| Buyer | What they do with the row |
|---|---|
| **Inkasso / debt-collection agencies** | An open Anmeldungsfrist is a hard deadline. They file claims for creditors — and the person they file with is the Masseverwalter. |
| **Turnaround & restructuring advisers** | A `Sanierungsverfahren` with the business still running is a live mandate. `business_status` tells them which. |
| **Industrial auctioneers & liquidators** | "Die Schließung des Unternehmens wird angeordnet" means an estate is about to be sold. The administrator decides who sells it. |
| **Credit-risk & B2B data teams** | The Firmenbuchnummer joins straight onto their existing Austrian company master data. |
| **Insolvency law firms** | The Tagsatzung calendar, the claims deadlines and who was appointed on what. |
| **Journalists & researchers** | A complete, dated corporate-insolvency time series with the court's own wording. |

The common thread: **nobody in this list contacts the bankrupt company.** They contact the
administrator. That is the field this actor exists to deliver.

***

### 📊 Measured field fill rates

Measured on a corpus of **745 real case documents** — every insolvency edict registered between
**01.08.2026 and 07.09.2026**, downloaded through the Apify datacenter proxy and re-parsed offline.
On the **default settings** (companies only, newly opened proceedings only, KV/SVOE/SVME) that
corpus produces **226 delivered rows**. These are the numbers on those 226 rows:

| Field | Fill | |
|---|---|---|
| `company_register_number` (Firmenbuchnummer) | **100%** | 226/226 — it is the gate, so it cannot be otherwise |
| `company_name`, `street_address`, `postal_code`, `city` | **100%** | 226/226 |
| `court`, `court_code`, `federal_state`, `case_number` | **100%** | 226/226 |
| `proceeding_type` + `proceeding_type_code` | **100%** | 226/226 |
| `administrator_name` | **100%** | 226/226 |
| **`administrator_email`** | **99.6%** | **225/226 — 164 distinct chambers in 5.5 weeks** |
| `administrator_phone` | **100%** | 226/226 |
| `administrator_fax` | 81.4% | 184/226 |
| `claims_deadline` (Anmeldungsfrist) | **100%** | 226/226 |
| `opening_effective_date` | **100%** | 226/226 |
| `next_hearing_date` + `next_hearing_location` | 99.1% / 100% | 224/226 have a live hearing; every hearing has a courtroom |
| `is_main_proceeding` (EU Insolvency Regulation) | 52.2% | 118/226 |
| `business_status` (continued vs ordered shut) | 36.7% | 83/226 |
| `administrator_deputy_name` | 22.6% | 51/226 |
| `restructuring_plan_quota_pct` | 7.1% | 16/226 — a Sanierungsplan usually arrives after the opening edict |
| `participants` (AKV / KSV1870 / ÖVC, debtor representatives) | 4.9% | 11/226 |

**Structural counts, same corpus:** 745 documents → **745 distinct (court, case number) pairs, zero
duplicates**. 49 distinct courts. Hearings per case: 188 with one, 37 with two, 1 with three.
Edicts per case: 121 with one, 90 with two, 11 with three, 4 with four. The lag between the opening
decision and its publication was **0 days on 223 of 226 cases and 1 day on the other 3** — this is a
same-day trigger feed, not an archive.

**The company gate is doing real work.** Across all 745 documents in the corpus only **388 (52.1%)**
carry a Firmenbuchnummer; within the three default proceeding types (KV / SVOE / SVME, 379
documents) it is **262 (69.1%)**. Either way, without the gate a large minority of what you receive
is not a registered company — and `regdata`'s competing actor states plainly that its debtor field
holds a "person **or** company".

***

### 🗓️ The one thing to understand: the date window is a *first-appearance* filter

The register's date field, `[DATBMA]`, is **the day the CASE first appeared in the Insolvenzdatei —
not the date of its most recent edict.** This is measured, not assumed:

- a 01–31.07.2026 search returned **2,107** documents and a 01–31.08.2026 search returned **1,263**, with **zero overlap**;
- five sampled July cases that each gained a fresh August edict were still **absent** from the August search;
- a case registered 03.08 with later edicts on 07.08 and 04.09 matched `[DATBMA]=03.08.2026` and **neither** of the other two dates.

Three consequences, all of them good, and all of them visible in the output:

1. **A `lookbackDays: 7` run is a clean new-case feed.** You are not wading through status updates on cases from 2018.
2. **`last_edict_date` can legitimately fall after your window.** A case registered on 3 August whose closure was ordered on 4 September is a *3 August row* carrying a *4 September* last edict. `registered_date` is what the window filtered on; `last_edict_date` is the case's current state. Both are in every row.
3. **`newOpeningsOnly` still has work to do.** Not every case's first edict is an opening: some are refusals for lack of funds (`Kostendeckung`), some are mere applications. On the default 7-day scope, 65 candidate edicts became 41 rows — 18 dropped as non-companies, 6 as non-openings.

Because one case is one document that the court edits in place, **`unid` is a stable primary key**
and `onlyNew` gives you exact once-only delivery across scheduled runs.

***

### 🧱 The 4,998-hit ceiling — and why this actor never reports a false empty window

The register refuses to list more than **4,998 hits**, and it does not do so by truncating. It
returns **HTTP 200 with ZERO rows**, no result table, no hit count, and one sentence:

> *Ihre Suche … hat mehr als **4998 Einträge** gefunden. Bitte verfeinern Sie Ihre Suche!*

Measured: a plain `01.06.2026–31.08.2026` request comes back with **0 rows and 16,601 bytes**. A
crawler that only looks for rows would report an empty quarter for one of the busiest windows of
the year. `SearchMax=0`, `9999`, `50000` and `100000` all clamp to the same 4,998 — it cannot be
raised.

So this actor:

- crawls in **1-day slices by default** (the busiest single day in the last 120 had **127** edicts — 39× under the ceiling; the 120-day census cost 22.9 s in total);
- **detects the ceiling notice explicitly** and splits any offending slice in half, recursively, down to a single day. Verified live: a 243-day slice (01.01–31.08.2026, all proceeding types) tripped the ceiling, split into 01.01–02.05 and 03.05–31.08, and came back with 2,602 + 2,593 = **5,195 rows from 3 searches** — where an undetected ceiling would have returned nothing at all;
- if even a single day is over the ceiling, sets **`search_complete: false`** on every row, lists the date in `search_missing_ranges`, and says so in the log.

The same honesty applies to every other way a run can come up short — see below.

***

### ✅ `search_complete` — what the run actually read, not what it asked for

Every row carries `search_window_from` / `search_window_to` (what you asked for) **and**:

| Field | Meaning |
|---|---|
| `search_complete` | `false` the moment anything truncated the read |
| `search_incomplete_reasons` | `failed_date_slices` · `server_hit_ceiling` · `partial_result_list` · `max_items_cap` · `charge_cap` · `max_detail_fetches` · `run_timeout` · `unreadable_documents` |
| `search_missing_ranges` | the exact `dd.mm.yyyy–dd.mm.yyyy` ranges never read, so you can re-run precisely the gap |

A sort or a filter that ran over a truncated read is a partial answer, and the row says so rather
than looking complete. A run that returns zero rows names the actual cause — your filters, an empty
window, the ceiling, a failed slice, or **your own `maxTotalChargeUsd` / `maxItems` / run timeout** —
and never blames the register for something the run did. Set `maxTotalChargeUsd` below `$0.003` and
the run tells you the budget bought zero rows; it does not report a scraping failure.

***

### 🚦 Reliability — measured, not asserted

All through the standard **Apify datacenter proxy** (`auto`), no residential, no browser:

| Test | Result |
|---|---|
| Search requests | **5/5 HTTP 200**, byte-identical responses, 0.8–4.4 s |
| Detail documents, concurrency 8 | **745/745 (100%)** in 106 s (7 req/s) |
| Detail documents, concurrency 6 | **149/150 first attempt (99.3%)**, 150/150 within 2 retries |
| 120 single-day searches, concurrency 8 | **120/120** in 22.9 s |
| Full default 7-day run on the Apify platform at 256 MB | **17.7 s and 31.1 s** on two runs, 41 rows each |
| Anti-bot challenges encountered in ~1,700 requests | **none** |

There is nothing here for a browser to do, so the actor runs at **256 MB**. Residential-Austria
proxies also work and are pointless — they would only add proxy bytes to your bill.

The only failures observed were transient connection resets that recovered on the first retry. Each
retry rotates the proxy session.

***

### 🚫 What this actor will not return

**Schuldenregulierungsverfahren (consumer debt settlement) — never, at any setting.** The same
database view carries them: **117 of 286** edicts in a sample week were private individuals' debt
settlements, with full name, home address and date of birth (100% of them carry a birth date). They
are not company insolvencies, and this actor **does not ask the register for them** — `SRV` is not
an accepted value for `proceedingTypes`, and the request that goes to the server never includes it.

**Dates of birth — off by default.** This is the part that a Firmenbuchnummer filter alone does not
solve, so it is worth stating exactly:

- **83 of 388 company documents (21.4%)** print a natural person's date of birth *inside the company's own `Schuldner` field* — "vertreten durch den GF: `<name>`, geb. 31.05.1977, `<private street>`, `<postcode town>`" — or as a sole trader's `Gebdat:` line. Some appear inside the **company name itself**.
- **20 of the 226 default rows (8.8%)** are Firmenbuch-registered sole traders (e.U.) who carry one.

With `includeBirthDates` off (the default), `debtor_birth_date` is `null` **and** every string in
the row is passed through a redaction pass that removes the date of birth and the private address
trailing it. Verified across the whole 745-document corpus: **0 documents leak a date of birth**.
Turn it on only if you have a lawful basis for processing it.

**`companiesOnly: false`** widens to corporate-type proceedings opened against *natural persons* —
sole traders and entrepreneurs. It does **not** open the consumer debt-settlement stream, and birth
dates stay redacted unless you also switch `includeBirthDates` on.

***

### 💵 Pricing

**Pay per event — one event, `$0.003` per insolvency row delivered.** No per-run charge, no
per-dataset-item surcharge. Both Apify auto-events are removed.

You are **never** charged for:

- a row dropped by the company gate, the new-openings gate, or any filter;
- a case document opened only to *test* a filter;
- a row your `maxItems` cap excluded;
- anything, when a run legitimately returns zero rows.

Delivery is budget-aware: rows are pushed and charged atomically, so a run that hits a
`maxTotalChargeUsd` cap cannot hand you rows you were not charged for — and it tells you the cap
was the cause.

The cap is read **before** the crawl, not at delivery, so the run does not pay to read documents it
cannot deliver. Measured on the same input (21-day window, `maxTotalChargeUsd` $0.02): the old
behaviour opened **217** case documents to deliver 6 rows in 82 s; reading the cap up front does it
in **15** documents and 22 s, with the same 6 rows delivered and charged and every row carrying
`search_complete: false` with reason `charge_cap`.

| What you want | Cost |
|---|---|
| A daily monitor, all of Austria (41 rows on the measured 7-day run; ~51/week at the 2025 rate) | **~$0.12–0.15 / week ≈ $6–8 / year** |
| One month of new company openings (~220 rows at the 2025 rate) | **~$0.66** |
| Every company opening in the whole archive (~7,900 rows) | **~$24** |
| Every company edict in the whole archive (~9,100 rows) | **~$27** |

The archive figures come from a full month-by-month census of the register (282 searches, 59 s):
**76,703 live edicts**, of which **13,179** are Konkurs- or Sanierungsverfahren. Applying the
company and opening shares measured on the 745-document corpus (69.1% carry a Firmenbuchnummer,
59.6% are openings) gives the two totals above.

For comparison, read live on 2026-09-08: the one other actor on this exact site charges **$0.005
per run start plus $0.004 per dataset item**; European insolvency actors elsewhere run $0.01–$0.05
per record.

***

### 🚀 Quick start

**A daily new-openings monitor for the whole country** (this is also the default — an empty input
does exactly this):

```json
{ "lookbackDays": 7, "onlyNew": true }
```

Schedule it daily. The 7-day window covers weekends and public holidays; `onlyNew` remembers every
case already delivered (by `unid`, in a named key-value store) so you are never charged twice for
the same company.

**Vienna commercial court only, biggest cases:**

```json
{ "lookbackDays": 30, "courtCodes": ["007"], "sortBy": "claims_deadline", "sortOrder": "asc" }
```

**Claims deadlines still open next month, anywhere in Austria:**

```json
{ "lookbackDays": 60, "claimsDeadlineFrom": "2026-10-01", "claimsDeadlineTo": "2026-10-31" }
```

**Construction companies in Styria:**

```json
{ "lookbackDays": 90, "courtDistricts": ["638", "609"], "debtorNameQuery": "*bau*" }
```

**Full historical backfill of company openings:**

```json
{ "publishedFrom": "01.01.2024", "publishedTo": "31.12.2025", "sliceDays": 1 }
```

**Everything, including refusals and applications, with the full text:**

```json
{ "lookbackDays": 7, "newOpeningsOnly": false, "proceedingTypes": ["KV", "SVOE", "SVME", "KEV"], "includeFullText": true }
```

***

### ⚖️ Court codes

`courtDistricts` takes a **Gerichtshofsprengel** — a Landesgericht *and every Bezirksgericht under
it*. `courtCodes` takes a **single Dienststelle**. Measured on one week: `[GH]=638` returned 31 hits
where `[Ger]=638` (the LGZ Graz itself) returned 17.

| Code | Court | Bundesland |
|---|---|---|
| `007` | **Wien, HG** — the Vienna commercial court, where Vienna's corporate insolvencies go | Wien |
| `003` | Wien, LGZ | Wien |
| `638` | Graz, LGZ | Steiermark |
| `609` | Leoben, LG | Steiermark |
| `458` | Linz, LG | Oberösterreich |
| `469` | Ried im Innkreis, LG | Oberösterreich |
| `499` | Steyr, LG | Oberösterreich |
| `519` | Wels, LG | Oberösterreich |
| `569` | Salzburg, LG | Salzburg |
| `818` | Innsbruck, LG | Tirol |
| `929` | Feldkirch, LG | Vorarlberg |
| `729` | Klagenfurt, LG | Kärnten |
| `309` | Eisenstadt, LG | Burgenland |
| `119` | Korneuburg, LG | Niederösterreich |
| `129` | Krems an der Donau, LG | Niederösterreich |
| `199` | St. Pölten, LG | Niederösterreich |
| `239` | Wiener Neustadt, LG | Niederösterreich |

All **211** Dienststelle codes from the register's own advanced-search form are accepted by
`courtCodes`, including Bezirksgerichte; an unknown code is rejected at input time rather than
silently returning nothing.

**Volume by Bundesland**, measured across 5 quarterly windows (2025-07-01 → 2026-09-07, ~20,400
edicts of every type): Wien 7,028 · Niederösterreich 3,212 · Oberösterreich 2,883 · Steiermark
2,311 · Tirol 1,390 · Kärnten 1,308 · Salzburg 976 · Vorarlberg 836 · Burgenland 439.

The `federal_state` on every row comes from that same calibration — 130 distinct courts resolved,
**zero** assigned to two different Bundesländer — not from guessing at postal codes.

***

### 📤 Output sample

```json
{
  "unid": "285b7e54c343fc4ec1258e6b0073b1db",
  "case_url": "https://edikte.justiz.gv.at/edikte/id/idedi8.nsf/0/285b7e54c343fc4ec1258e6b0073b1db!OpenDocument",
  "court": "HG Wien",
  "court_code": "007",
  "federal_state": "Wien",
  "federal_state_code": "0",
  "case_number": "2 S 125/26h",
  "proceeding_type": "Konkursverfahren",
  "proceeding_type_code": "KV",
  "debtor_type": "company",
  "company_name": "A&A Elektrotechnik GmbH",
  "company_register_number": "621689z",
  "firmenbuch_url": "https://justizonline.gv.at/jop/web/firmenbuchabfrage?fbnr=621689z",
  "street_address": "Odoakergasse 22/2",
  "postal_code": "1160",
  "city": "Wien",
  "registered_date": "2026-09-07",
  "last_edict_date": "2026-09-07",
  "opening_effective_date": "2026-09-08",
  "claims_deadline": "2026-10-20",
  "days_until_claims_deadline": 42,
  "is_new_opening": true,
  "administrator_role": "Masseverwalter",
  "administrator_name": "DALLINGER Klemens Dr.",
  "administrator_email": "dallinger@anwaltsteam.at",
  "administrator_phone": "513 28 33",
  "administrator_fax": "513 28 33-22",
  "administrator_address": "Schulerstraße 18, 1010 Wien",
  "hearings": [
    {
      "date": "2026-11-03", "time": "10:15", "location": "Zimmer 1605, 16.Stock",
      "purposes": ["Berichtstagsatzung", "Prüfungstagsatzung"],
      "source": "Tagsatzung", "superseded": false, "published_date": "2026-09-07"
    }
  ],
  "next_hearing_date": "2026-11-03",
  "next_hearing_location": "Zimmer 1605, 16.Stock",
  "self_administration": false,
  "is_main_proceeding": false,
  "no_cost_coverage": false,
  "proceeding_closed": false,
  "edict_count": 1,
  "publications": [
    { "published_date": "2026-09-07", "decision_date": "2026-09-07",
      "section_labels": ["Firmenbuchnummer", "Schuldner", "Masseverwalter", "Eröffnung", "Eigenverwaltung", "Tagsatzung"] }
  ],
  "sections": {
    "Masseverwalter": ["DALLINGER Klemens Dr.\nSchulerstraße 18\n1010 Wien\nTel.: 513 28 33, Fax: 513 28 33-22\nE-Mail: dallinger@anwaltsteam.at"],
    "Eröffnung": ["Beginn der Wirkungen der Eröffnung: 08.09.2026\nAnmeldungsfrist: 20.10.2026"]
  },
  "search_window_from": "2026-09-02",
  "search_window_to": "2026-09-08",
  "search_complete": true,
  "search_incomplete_reasons": [],
  "search_missing_ranges": [],
  "scraped_at": "2026-09-08T03:33:40.830Z"
}
```

***

### ❓ FAQ

**How fresh is the data?**
Same day. On 226 measured cases the opening decision was published on the day it was made (223) or
the next day (3). Edicts appear during the working day, so a morning run picks up yesterday's.

**How far back does the archive go?**
To 2015 — but the register prunes old years, so the early ones are thin. Measured by a full
month-by-month census on 2026-09-08 (282 searches, 59 s), **76,703 live edicts** in total:

| Year | All edicts | Konkurs / Sanierung | Busiest month |
|---|---|---|---|
| 2015 | 244 | 56 | 33 |
| 2016 | 298 | 67 | 34 |
| 2017 | 347 | 80 | 51 |
| 2018 | 2,050 | 137 | 261 |
| 2019 | 3,558 | 195 | 372 |
| 2020 | 5,274 | 210 | 619 |
| 2021 | 4,547 | 233 | 569 |
| 2022 | 6,546 | 483 | 695 |
| 2023 | 10,391 | 1,339 | 1,130 |
| 2024 | 14,658 | 3,012 | 1,418 |
| 2025 | 16,445 | 4,440 | 1,518 |
| 2026 (to 08.09) | 12,345 | 2,927 | **2,107** |
| **Total** | **76,703** | **13,179** | |

No month in twelve years reaches the 4,998-hit ceiling — the busiest was July 2026 at 2,107, which
is why 31-day slices are safe today and 1-day slices are safe with 39× headroom.

**Why is `last_edict_date` after my date window?**
Because the window filters on `registered_date` — the day the case first appeared. See *the date
window is a first-appearance filter* above. It is the register's behaviour, not a parsing bug.

**Can I look up whether one specific company is insolvent?**
Not with this actor. The register does support it (`[FN]=484188t` returns exactly one row), but
"screen 5,000 company numbers" is a different function with an inverted cost profile — thousands of
searches for a handful of rows — and it belongs in its own actor.

**Do I get the creditors' claim amounts?**
No. Austrian insolvency edicts do not publish claim amounts or a list of creditors. What is
published is what you get: the debtor, the administrator, the deadlines, the hearings and the
court's own findings.

**What about Exekutionen (foreclosures) and Firmenbuch announcements?**
Different databases inside the same Ediktsdatei, and deliberately out of scope. One site, one
function, one actor.

**Does `onlyNew` survive between scheduled runs?**
Yes — it uses a **named** key-value store (`seenStoreName`, default `edikte-insolvency-at-seen`), so
it persists. Point two schedules at two different store names to run independent monitors.

**Why is the default `sliceDays: 1`?**
Two reasons, both measured: it keeps every request 39× under the register's zero-rows-at-4,998
ceiling, and it tells the crawler each case's registered date *before* it pays to open anything, so
a `maxItems` cap keeps the newest cases instead of an arbitrary middle. 120 day-searches cost 22.9 s.
Bigger slices are safe — up to 366 days — because a slice that trips the ceiling is halved
automatically: a live 243-day slice split into two and returned 2,602 + 2,593 = 5,195 rows from
3 searches, where an undetected ceiling would have returned zero.

**Why is `KEV` off by default?**
A Konkurseröffnungsverfahren is an *application* for a proceeding, not an opening. **0 of the 366
KEV documents** in the test corpus carried an Eröffnung section, so with `newOpeningsOnly` on every
KEV page fetched is read and discarded. The actor warns you if you select both.

**The run said `search_complete: false`. What now?**
Read `search_incomplete_reasons`. If it is `max_items_cap` or `max_detail_fetches`, raise the cap;
if it is `charge_cap`, raise `maxTotalChargeUsd` (the crawl stops at the number of rows your budget
covers, so nothing you were not charged for was read). If it is `failed_date_slices`,
`server_hit_ceiling` or `partial_result_list`, `search_missing_ranges` gives you the exact dates to
re-run — narrow the scope for those.

**Do I need residential proxies?**
No. 745/745 documents and every search came back through the plain Apify datacenter proxy. The site
has no anti-bot challenge.

***

### ⚖️ Legal, robots and personal data

- **The source is official public court data.** The Ediktsdatei is the Republic of Austria's statutory publication channel for insolvency proceedings, published under the Insolvenzordnung so that creditors can find out about them. Access is free (*gebührenfrei*), needs no account, and carries no terms-of-use gate.
- **robots.txt.** `https://edikte.justiz.gv.at/robots.txt` returns **HTTP 200 with `Content-Type: text/html`** — it is the Domino database's own welcome page, and it contains **zero** `User-agent` and **zero** `Disallow` directives. There is no robots directive to observe on this host.
- **Page-level meta tags, quoted verbatim.** Case documents carry:
  `<meta name="robots" content="noindex">`, `<meta name="robots" content="nofollow">`,
  `<meta name="robots" content="noarchive">`, `<meta name="googlebot" content="nosnippet">`,
  `<meta name="robots" content="noimageindex,nomediaindex">`.
  These are **search-engine indexing directives**, not access controls, and they are why these
  edicts do not show up in Google. This actor reads the pages; it does not index or republish them.
- **A licensed feed also exists.** The Republic offers an official machine-to-machine data feed that requires an IWG government licence and a formal application. This actor uses the **free public web interface** instead. If your use case needs the licensed feed's guarantees, apply for it.
- **Personal data.** Read *What this actor will not return* above before you run this at scale. Consumer debt-settlement proceedings are never requested; dates of birth are redacted out of every field by default; the administrator's e-mail and phone are a named lawyer's **professional** contact details, published by the court under a statutory transparency mandate.
- **Rate.** The actor runs at concurrency 6 by default (≈5 requests/second) and a full 7-day run makes about 70 requests. Please do not raise the concurrency above 8 — the register is a public service, and 8 already reads 745 documents in 106 seconds.

You are responsible for how you use the output, including compliance with the GDPR and with
Austrian law.

# Actor input Schema

## `lookbackDays` (type: `integer`):

Scrape cases that FIRST appeared in the register in the last N days, ending today. This is the right setting for a scheduled monitor. Ignored when you set both fixed dates below. The register keeps roughly 76,700 live edicts going back to 2015, so a large value is a full backfill — see "Slice size" for how it is split.

## `publishedFrom` (type: `string`):

Start of a fixed date range, e.g. 01.08.2026 (YYYY-MM-DD also accepted). Must be set together with "Published to". This is the register own \[DATBMA] field, filtered inside the search query — and it is the date the CASE FIRST APPEARED in the Insolvenzdatei, not the date of its most recent edict. Proven: a July search returned 2,107 documents and an August search 1,263 with ZERO overlap, and July cases that later gained an August edict stayed out of the August result. So a row can legitimately carry a last\_edict\_date after your window.

## `publishedTo` (type: `string`):

End of the fixed publication-date range, e.g. 07.09.2026. Must be set together with "Published from".

## `sliceDays` (type: `integer`):

The date range is crawled in slices of this many days. Leave at 1. Two measured reasons: (a) past 4,998 hits the register returns ZERO rows with "Bitte verfeinern Sie Ihre Suche" instead of a truncated list — a single 3-month request comes back empty — and the busiest single day in the last 120 had only 127 edicts, so a 1-day slice sits 39x under the ceiling; (b) a 1-day slice tells the crawler each case registered date before it opens anything, so a maxItems cap keeps the newest cases rather than an arbitrary middle. Larger slices cost fewer searches on a long backfill and are safe: a slice that trips the ceiling is detected and halved automatically, recursively, down to a single day. Verified live — a single 243-day slice (01.01-31.08.2026, all proceeding types) tripped the ceiling, split into 01.01-02.05 and 03.05-31.08, and returned 2,602 + 2,593 = 5,195 rows from 3 searches where an undetected ceiling would have returned zero. Day-searches are cheap anyway: 120 of them took 22.9 s.

## `proceedingTypes` (type: `array`):

The register own \[Verfahrenskurztext] filter, executed inside the search query — unselected types are never downloaded. Default is the three real corporate insolvency proceedings. KEV is only an APPLICATION for a proceeding: 0 of 366 KEV documents in the 745-document test corpus carried an opening, so it is pure waste while "Only newly opened proceedings" is on. Schuldenregulierungsverfahren (consumer debt settlement) is deliberately not offered — see the README.

## `federalState` (type: `string`):

Restrict to one Austrian federal state using the register own \[BL] field, inside the query — a Vienna-only run never downloads the rest of Austria. Leave empty for all of Austria.

## `courtDistricts` (type: `array`):

Restrict to one or more Landesgericht districts using \[GH]. A district covers the Landesgericht AND every Bezirksgericht under it (measured: \[GH]=638 returned 31 hits for a week where the LGZ Graz alone returned 17). Leave empty for all courts. Combining this with a Bundesland that does not contain the district is rejected at input time, because the register would answer with zero rows and that reads like an empty market.

## `courtCodes` (type: `array`):

Restrict to specific courts by their 3-digit register code using \[Ger] — narrower than a court district. Use this to get the commercial court alone: "007" is HG Wien, which handles Vienna corporate insolvencies, while the Vienna district also contains the Bezirksgerichte. Other common codes: 638 LGZ Graz, 458 LG Linz, 569 LG Salzburg, 818 LG Innsbruck, 929 LG Feldkirch, 729 LG Klagenfurt, 199 LG St. Poelten, 239 LG Wiener Neustadt, 119 LG Korneuburg, 519 LG Wels. Unknown codes are rejected with the valid list.

## `debtorNameQuery` (type: `string`):

Full-text search on the debtor name, executed inside the register query. Plain text is a word match (\[Schuldner] CONTAINS): "Bau" returned 5 hits on a test week. Add \* for a substring match: "*Bau*" returned 14 on the same week. Leave empty for everything.

## `companiesOnly` (type: `boolean`):

Keep only debtors that carry a Schuldner-Firmenbuchnummer, i.e. entities registered in Austria company register. This makes company\_register\_number 100% filled on every delivered row and gives you a hard join key to the Firmenbuch. Turn it OFF to also receive corporate-type proceedings opened against natural persons (sole traders and entrepreneurs, not consumer debt settlement — this actor never requests that). Measured: 388 of 745 corporate-type edicts (52.1%) carry a Firmenbuchnummer.

## `newOpeningsOnly` (type: `boolean`):

Keep only cases whose OPENING edict was published inside your date window — a true new-openings trigger feed. One case is one live document the court keeps editing, so "the document mentions an Eroeffnung" is not the same question. Turn it OFF to also receive the cases whose first edict was NOT an opening: proceedings refused for lack of funds (Kostendeckung), applications, and other first notices. Measured on the default 7-day scope: 41 of 65 candidate edicts survived both gates, 18 were dropped as non-companies and 6 as non-openings.

## `requireAdministratorEmail` (type: `boolean`):

Drop any row where the Masseverwalter / Sanierungsverwalter has no published e-mail address. Rarely needed on the default scope — the e-mail was present on 225 of 226 default rows (99.6%) — but useful when you are feeding an outreach tool that requires one.

## `excludeNoCostCoverage` (type: `boolean`):

Drop edicts carrying a Kostendeckung section — the proceeding was refused or closed because the estate cannot cover the costs. There is no estate to work on and usually no administrator. Mostly redundant while "Only newly opened proceedings" is on (those edicts carry no opening), so this is for wider runs. Measured: 378 of 745 documents carry one.

## `excludeClosedProceedings` (type: `boolean`):

Drop cases that already carry an Aufhebung, Beendigung or Einstellung section — the proceeding is over. Only relevant with "Only newly opened proceedings" off.

## `postalCodePrefixes` (type: `array`):

Keep only debtors whose postal code starts with one of these, e.g. \["10","11"] for the 10th and 11th districts of Vienna, or \["8"] for Styria. Applied to the debtor own address on the edict.

## `companyNameContains` (type: `string`):

Plain case-insensitive substring match on the debtor name, applied after the documents are read. Use "Debtor name search" above instead when you can — that one runs inside the register and does not pay for the pages it excludes.

## `claimsDeadlineFrom` (type: `string`):

Keep only cases whose creditor claims deadline (Anmeldungsfrist) falls on or after this date — the "which deadlines are still open" filter. Rows with no deadline are dropped by it. Only opening edicts carry one.

## `claimsDeadlineTo` (type: `string`):

Keep only cases whose creditor claims deadline falls on or before this date.

## `onlyNew` (type: `boolean`):

Remember every case document already delivered (by its UNID, the register own stable document id) in a NAMED key-value store, and skip it next time. Made for a daily schedule with a 7-day window: the overlap is suppressed instead of re-charged. A case appears once even though the court keeps editing the same document. Skipped rows are never delivered and never charged.

## `seenStoreName` (type: `string`):

Key-value store that holds the delivered UNIDs when the setting above is on. Change it to run several independent monitors (different regions, different filters) from one account without them sharing memory.

## `includeBirthDates` (type: `boolean`):

OFF by default, and it should usually stay off. The register prints natural persons inside company edicts: 83 of 388 company documents (21.4%) carry a managing director or sole trader date of birth, often with a private home address, INSIDE the company own Schuldner field where no row filter can reach it. With this off, debtor\_birth\_date is null and those fragments are redacted out of debtor\_block, sections, notice\_text and full\_text (verified: 0 of 745 documents leak a date of birth). Turn it on only if you have a lawful basis for processing it.

## `includeSections` (type: `boolean`):

Add `sections` — every labelled block of the edict, keyed by the court own German label, so nothing on the page is ever silently dropped. 25 distinct labels were seen across the test corpus, from Masseverwalter and Tagsatzung down to Rekurs and Vermoegenslosigkeit.

## `includePublicationHistory` (type: `boolean`):

Add `publications` — one entry per edict the court has published on this case, with its publication date, decision date and the section labels it carried. A case document grows in place: 121 of the 226 default rows had 1 edict, 90 had 2, 11 had 3 and 4 had 4.

## `includeFullText` (type: `boolean`):

Add `full_text` — every section concatenated as one plain-text blob, for keyword search or an LLM. Off by default because it roughly doubles row size and duplicates `sections`.

## `sortBy` (type: `string`):

Orders the rows you receive. Note this sorts the DELIVERED array: if a cap stopped the crawl early, the sort ranks what was read, and every row then carries search\_complete: false so you can tell.

## `sortOrder` (type: `string`):

Descending (newest first) is the default and also the direction the date window is crawled in, so a maxItems cap keeps the newest rows. That alignment is exact for the two date sorts on registered\_date; other sort fields rank whatever the crawl read.

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

0 = no limit. The crawl STOPS as soon as this many rows have passed the filters, so the cap limits the pages read and the bill, not just the output. When it truncates the read, every row carries search\_complete: false and search\_incomplete\_reasons \["max\_items\_cap"].

## `maxDetailFetches` (type: `integer`):

0 = no limit. A hard ceiling on how many case documents this run may read, whatever the filters do. Every filter here can only be judged on the document itself, so a very narrow filter over a wide window reads many pages for few rows — on the default 7-day scope roughly 3 pages are read per row delivered. Set this when you want a guaranteed worst-case cost. When it stops the run, rows carry search\_complete: false and search\_incomplete\_reasons \["max\_detail\_fetches"].

## `detailConcurrency` (type: `integer`):

Measured through the Apify datacenter proxy: 149/150 first attempt at 6, and 745/745 at 8 in 106 s. Above 8 there is nothing to gain — the register is not the bottleneck.

## `requestTimeoutSecs` (type: `integer`):

Per HTTP request. A search takes 1-4 s and a document about 1 s, so 60 is generous.

## `maxRequestRetries` (type: `integer`):

Each retry rotates the proxy session. The observed failures were transient connection resets that recovered on the first retry.

## `proxyConfiguration` (type: `object`):

The plain Apify datacenter proxy is enough: 5/5 searches returned byte-identical HTTP 200 responses, and 745/745 documents were read through it. The site has no anti-bot challenge and residential IPs would only add proxy-byte cost.

## Actor input object example

```json
{
  "lookbackDays": 7,
  "publishedFrom": "01.08.2026",
  "publishedTo": "07.09.2026",
  "sliceDays": 1,
  "proceedingTypes": [
    "KV",
    "SVOE",
    "SVME"
  ],
  "federalState": "",
  "courtDistricts": [],
  "courtCodes": [],
  "debtorNameQuery": "*bau*",
  "companiesOnly": true,
  "newOpeningsOnly": true,
  "requireAdministratorEmail": false,
  "excludeNoCostCoverage": false,
  "excludeClosedProceedings": false,
  "postalCodePrefixes": [],
  "companyNameContains": "",
  "claimsDeadlineFrom": "2026-10-01",
  "claimsDeadlineTo": "2026-12-31",
  "onlyNew": false,
  "seenStoreName": "edikte-insolvency-at-seen",
  "includeBirthDates": false,
  "includeSections": true,
  "includePublicationHistory": true,
  "includeFullText": false,
  "sortBy": "registered_date",
  "sortOrder": "desc",
  "maxItems": 50,
  "maxDetailFetches": 0,
  "detailConcurrency": 6,
  "requestTimeoutSecs": 60,
  "maxRequestRetries": 3,
  "proxyConfiguration": {
    "useApifyProxy": true
  }
}
```

# Actor output Schema

## `insolvencies` (type: `string`):

Company name, Firmenbuchnummer, court and case number, proceeding type, address, the Masseverwalter's name, e-mail, phone and address, the creditor claims deadline, every scheduled hearing, the case-state flags and the full publication history.

# 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 = {
    "lookbackDays": 7,
    "sliceDays": 1,
    "companiesOnly": true,
    "newOpeningsOnly": true,
    "maxItems": 50,
    "proxyConfiguration": {
        "useApifyProxy": true
    }
};

// Run the Actor and wait for it to finish
const run = await client.actor("scrapersdelight/edikte-insolvency-at-scraper").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 = {
    "lookbackDays": 7,
    "sliceDays": 1,
    "companiesOnly": True,
    "newOpeningsOnly": True,
    "maxItems": 50,
    "proxyConfiguration": { "useApifyProxy": True },
}

# Run the Actor and wait for it to finish
run = client.actor("scrapersdelight/edikte-insolvency-at-scraper").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 '{
  "lookbackDays": 7,
  "sliceDays": 1,
  "companiesOnly": true,
  "newOpeningsOnly": true,
  "maxItems": 50,
  "proxyConfiguration": {
    "useApifyProxy": true
  }
}' |
apify call scrapersdelight/edikte-insolvency-at-scraper --silent --output-dataset

```

## MCP server setup

```json
{
    "mcpServers": {
        "apify": {
            "type": "http",
            "url": "https://mcp.apify.com/?tools=fetch-actor-details,scrapersdelight/edikte-insolvency-at-scraper"
        }
    }
}
```

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/raHuEJXPid00F9JLF/builds/DD2XFLIGkGv3l6mAd/openapi.json