FR
Copied
Modules

Closed check

Check whether each point of interest is still operating, has shut down, or is uncertain — based on real abandonment signals on its website.

Purpose

The dead_check module inspects the website attached to each point of interest (POI) and decides whether the underlying business looks alive, dead, or uncertain. It correlates several abandonment signals on the same domain: expiring registration, redirection to an unrelated property (resale or rebranding), parking pages disguised as real sites, and stale or invalid TLS certificates. Directory listings (Doctolib, Pages Jaunes, Yelp, etc.) are recognised as such rather than blindly flagged as a personal site.

Inputs

A list of POIs, each carrying at least a website. Items without a site_web are filtered out at submit time.

Field Type Required Description
items array of POI objects yes 1 to 10 000 entries. Entries without a site_web are dropped before execution.
source_job_id string no Identifier of the upstream list-producing job (typically a scrap). Used for lineage in the UI and the pipeline.

No other tuning parameters: the module runs in a single mode.

Outputs

Each input POI is augmented with the closed-check verdict for its website. The original POI columns are kept and the following is appended:

Column Type Description
site_alive "open" | "closed" | "uncertain" Final verdict. open means the site behaves like an active business presence, closed means converging signals of abandonment, uncertain means signals were too thin to decide.

The progress unit during execution is sites; the result unit is also sites.

Lifecycle

Standard job states — see Jobs lifecycle. Partial counters stream over SSE so early verdicts can be consumed without waiting for the final export.

Pipeline

Pipelinable; typically inserted right after the list-producing step, before any expensive enrichment.

Slot Value
needs site_web
produces site_alive
Category verify
Typical upstream scrap
Typical downstream emails, techstack, ads_intelligence, filter

A common pattern is scrap then dead_check then filter (keep site_alive = "open") then any enrichment module — avoiding outreach spend on shuttered businesses.

Endpoints

Create a job:

POST /api/jobs/dead-check
Content-Type: application/json

{
  "items": [
    { "site_web": "https://example.com", "nom": "Example Co" }
  ],
  "source_job_id": "…"
}

Response: a JobPublic object with id, status, and the standard job metadata. Poll GET /api/jobs/{id} or subscribe to the SSE stream for progress; download the final CSV from the job detail page once status = "done".

For the full job API surface (list, detail, cancel, export, events), see Jobs API. For per-account quotas, see Limits.

Errors

HTTP detail Cause
400 Aucun établissement avec site web No input item carries a site_web field.
400 Quota dépassé : … Estimated cost exceeds the per-job equivalent-France quota.
401 / 403 — Missing or inactive session.

Errors raised after the job has been created surface on the job detail page and via the SSE error event; the job ends in status = "error" and partial results, if any, remain downloadable.

What's next