# Website Liveness Check ✅ Live, Parked, Redirected or Dead (`pvalyou/website-liveness-check`) Actor

One verdict per domain with the evidence: live, stale, placeholder, redirected, parked, expired or dead, a 0 to 100 score and the reason. Plus registration (registrar, age, expiry), email provider and SPF/DMARC, certificate, hosting, tech, socials and archive history. Bulk, no key, $0.001 a domain.

- **URL**: https://apify.com/pvalyou/website-liveness-check.md
- **Developed by:** [Pvalyou](https://apify.com/pvalyou) (community)
- **Categories:** Lead generation, Developer tools, Business
- **Stats:** 2 total users, 1 monthly users, 100.0% runs succeeded, 0 bookmarks
- **User rating**: No ratings yet

## Pricing

from $1.00 / 1,000 domain checks

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

## 🌐 Website Liveness Check: one verdict per domain, with the evidence

**Give a list of domains and get, for each one, whether the company's website is live, stale, a placeholder, redirected elsewhere, parked, expired or dead, with a 0 to 100 score and the exact reason.** $0.001 a domain, for lead lists and CRM hygiene, investors watching a portfolio, research teams and agencies. It is the whois alternative and domain status checker that answers in bulk: a verdict per domain instead of a registration record you still have to interpret.

Around the verdict comes what the check saw on the way. Where the domain lands and how many hops it took, whether it has mail and who runs it, the registrar and the registration dates, the certificate and the hosting. Then the tech on the page, the structured organization data and social profile links the site publishes, its links to pricing, about, careers and contact pages, and, when the landing page says so, the sentence announcing an acquisition or a rebrand. Try it now with the prefilled input: a live site, a same-name migration, a parking host and a URL.

Deterministic rules over public sources: DNS, one homepage fetch, one TLS handshake, the registry's own RDAP server, `robots.txt`, and archive.org for history. No browser, no proxies, no login, no AI model. Every verdict carries its reason and the raw facts, so you can disagree with it.

**What you get**

- ✅ **A verdict you can act on.** `LIVE`, `LIVE_STALE`, `PLACEHOLDER`, `REDIRECTED_AWAY`, `PARKED`, `EXPIRED`, `DEAD_UNREACHABLE` or `DEAD_DNS`, a score, and a one-line reason such as "redirects to parking host (sedo.com)" or "migrated to notion.com (same name)".
- ✅ **Mail facts for list cleaning.** MX present, the email provider (Google Workspace, Microsoft 365, Proofpoint, Zoho and 40 more), SPF present, DMARC policy.
- ✅ **Registration facts from the registry.** Registrar, creation date and domain age, expiry date and days to expiry, status codes, name servers, DNSSEC. Straight from RDAP, no WHOIS parsing, no registrant contact data.
- ✅ **A page profile without a browser.** Title, description, language, favicon, hosting or CDN, CMS and framework and analytics and marketing tools (about 70 fingerprints), the site's JSON-LD organization record (name, logo, founding date, address, official profiles) and its LinkedIn, X, Facebook, Instagram, GitHub, YouTube and Crunchbase links.
- ✅ **Change alerts on a schedule.** Monitor mode keeps the previous run's verdicts and flags every domain whose state, redirect, certificate or mail changed, plus registrations expiring within 30 days.
- ✅ **Archive history.** First capture, last capture, years online, and the last time the site actually returned a page. A site that loads today but last worked years ago is a zombie, and this is how you see it.
- ✅ **Priced per domain.** $0.001 per domain checked, $0.003 per domain with an archive record. Cleaning a list of 5,000 leads costs $5.

### 👥 Who uses website liveness checks?

- 📧 **Lead lists and CRM hygiene.** Drop the dead, parked and redirected domains and the ones without mail before a campaign. One run over the list, filter on the verdict and `has_mx`.
- 💸 **Investors and portfolio teams.** Which company went dark, got parked, or now redirects to an acquirer, with the acquisition notice quoted from the page. Run the portfolio weekly in monitor mode.
- 📊 **Research and data teams.** Domain age, first archive capture, years online and last-worked date as firmographic fields, in bulk, from the registry and the archive rather than a data broker.
- 🏷️ **Domain investors and brand teams.** Parked, expired, expiring within 30 days, registrar, status codes, name servers.
- 🧑‍💻 **Agencies and developers.** Hosting, CMS, analytics tags, certificate state, which AI crawlers `robots.txt` blocks, the sitemap URL.
- 🤖 **AI agents and pipelines.** Structured JSON per domain, callable from the Apify API, the MCP server and the Python and JavaScript clients. Events only, so it is eligible for agentic payment.

### ⬇️ Input: a mode and a list of domains

```json
{
  "mode": "check",
  "domains": ["stripe.com", "notion.so", "sedo.com", "https://www.checkpoint.com/"]
}
```

| Field | What it does |
|---|---|
| `mode` | `check` (verdict and evidence per domain), `history` (the archive.org record per domain), `monitor` (check mode with a `changes` list per domain since the previous run). |
| `domains` | One per line: a domain, a website URL or an email address (the domain part is used). Each entry may also be an object with `domain`, an optional `name` (the company's name, checked against the page) and its own `mode`, so one run can mix checks and history. Up to 10,000 per run. |
| `registration` | Registrar, dates, status codes, name servers and DNSSEC from RDAP (default on). Off saves one request per domain. |
| `profile` | Email provider and SPF/DMARC, hosting, tech, meta, organization record and social links (default on). |
| `links` | The homepage's links to pricing, about, team, contact, careers, docs, blog, press, terms and privacy pages (default on). |
| `only_states` | Keep only rows with these verdicts, for example `PARKED` and `DEAD_DNS`. Every domain is still checked and charged. |
| `changes_only` | Monitor mode: push only the domains that changed (and every domain on the first run). |

An empty entry, a string that is not a domain, an IP address, or a reserved name like `example.com` is rejected before any paid step, as an uncharged error item, and the run still ends normally.

### ⬆️ Output: one dataset item per domain

Every item carries `type`, the `query` it came from, and `charged`.

| `type` | Charged | Contents |
|---|---|---|
| `domain` | once (`domain_check`), whatever the verdict | the verdict and the evidence |
| `history` | once (`domain_history`), when the archive knows the domain | first and last capture, years online, last time it worked |
| `error` | never | an `error` code and a message |

Every `error` item is free, and its code says which stage refused it:

| Where it comes from | Codes |
|---|---|
| Your input, before any call | `invalid_input` (not a domain, a URL or an email address, an IP address, a reserved name, or an entry that is neither a string nor an object with `domain`), `empty_query`, `unknown_mode` |
| The domain check service | `could_not_observe` items, whose `error` carries the service's own reason (our resolver failed its canary check, the per-domain deadline passed, the fetch was refused), plus `rate_limited`, `unauthorized`, `upstream_error`, `api_error` |
| The connection | `timeout` (no answer within 290 seconds for a chunk of 25 domains), `unreachable` |

A `could_not_observe` item is the third state: not live, not dead, not observed. It is never counted as a verdict and never charged.

The flat columns of a `domain` item, from the prefilled input:

| domain | state | score | reason | final\_domain | email\_provider | registrar | domain\_created | cert\_issuer | hosting\_hint |
|---|---|---|---|---|---|---|---|---|---|
| stripe.com | LIVE | 100 | up with real content | | Google Workspace | SafeNames Ltd. | 1995-09-08 | DigiCert Inc | |
| notion.so | LIVE | 85 | migrated to notion.com (same name) | notion.com | | *(unavailable: .so has no RDAP)* | | Google Trust Services | Cloudflare |
| sedo.com | PARKED | 10 | redirects to parking host (sedo.com) | | Google Workspace | World4You Internet Services | 1998-09-09 | Sectigo Limited | Cloudflare |
| checkpoint.com | LIVE | 100 | up with real content | | Microsoft 365 | Domain The Net Technologies Ltd. | 1994-03-29 | GlobalSign nv-sa | Amazon CloudFront |

Under the flat columns sit the nested objects. The checkpoint.com item, trimmed:

```json
{
  "type": "domain", "query": "https://www.checkpoint.com/", "domain": "checkpoint.com", "charged": true,
  "verdict": {"state": "LIVE", "score": 100, "reason": "up with real content"},
  "reachability": {"reachable": true, "http_status": 200, "final_url": "https://www.checkpoint.com/",
    "redirected_off_domain": false, "redirect_chain": [{"url": "https://checkpoint.com/", "status": 301}, {"url": "https://www.checkpoint.com/", "status": 200}],
    "response_ms": 611, "server": "nginx", "bot_challenge": false, "javascript_shell": false},
  "dns": {"resolves": true, "a_records": ["13.33.153.38", "13.33.153.102"], "nameservers": ["dns1.p01.nsone.net", "dns2.p01.nsone.net"],
    "has_mx": true, "mx_hosts": ["checkpoint-com.mail.protection.outlook.com"], "email_provider": "Microsoft 365", "spf_present": true, "dmarc_policy": "reject"},
  "registration": {"available": true, "registrar": "Domain The Net Technologies Ltd.", "created": "1994-03-29", "expires": "2027-03-30",
    "domain_age_days": 11851, "days_to_expiry": 203, "status": ["client delete prohibited", "client transfer prohibited"], "dnssec": true},
  "certificate": {"issuer": "GlobalSign nv-sa", "issued_days_ago": 83, "expires": "2027-01-02", "expired": false, "valid_for_host": true},
  "page": {"title": "Check Point Software: Leader in Cyber Security Solutions", "language": "en-us", "content_length": 6213, "company_name_on_page": null,
    "description": "Check Point Software Technologies Ltd. is a leading provider of cyber security solutions...", "favicon_url": "https://www.checkpoint.com/wp-content/uploads/favicon.ico"},
  "organization": {"name": "Check Point Software Technologies Ltd.", "legal_name": "Check Point Software Technologies Ltd.", "founding_date": "1993",
    "address": "5 Shlomo Kaplan Street, Tel Aviv, 6789212, IL", "logo": "https://www.checkpoint.com/wp-content/uploads/check-point-logo-600x450-1.png"},
  "social": {"linkedin": "https://www.linkedin.com/company/check-point-software-technologies", "x": "https://x.com/checkpointsw",
    "youtube": "https://www.youtube.com/user/CPGlobal", "instagram": "https://www.instagram.com/checkpointsoftware"},
  "tech": {"cms": ["WordPress"], "framework": ["jQuery", "Bootstrap"], "analytics": ["Google Tag Manager"], "marketing": ["Drift"], "other": ["OneTrust", "X-Powered-By: WP Engine"]},
  "hosting": {"cdn_or_host": "Amazon CloudFront", "server": "nginx", "dns_host": "NS1"},
  "robots": {"fetched": true, "allows_us": true, "ai_crawlers_blocked": [], "sitemap_urls": ["https://www.checkpoint.com/sitemap.xml"]},
  "links": {"about_url": "https://www.checkpoint.com/about-us/", "careers_url": "https://careers.checkpoint.com/", "contact_url": "https://www.checkpoint.com/contact-us/", "...": "17 named slots"},
  "transition_notice": null
}
```

A `history` item for the same domain:

```json
{"type": "history", "domain": "checkpoint.com", "charged": true, "match_status": "found",
 "first_capture": "1996-12-03", "last_capture": "2026-09-02", "monthly_captures": 308,
 "last_ok_capture": "2026-06-01", "years_online": 29.7, "last_worked_years_ago": 0.3}
```

### 🚦 The verdicts

The rules run top to bottom. The first match wins, and the reason names the rule.

| State | Score | Meaning |
|---|---|---|
| `DEAD_DNS` | 0 | the name does not resolve. When the registry confirms it, the reason adds "and is not registered". |
| `EXPIRED` | 5 | the registration date has passed. |
| `PARKED` | 10 | a parking name server, a redirect to a domain marketplace, or for-sale text on the page. |
| `DEAD_UNREACHABLE` | 5 to 10 | resolves but nothing answers, or the homepage is a 404. |
| `REDIRECTED_AWAY` | 50 | lands on a different-name domain. The destination is recorded, the cause is not guessed. Look at `transition_notice`. |
| `PLACEHOLDER` | 40 | answers with a "coming soon" page or almost no text. |
| `LIVE_STALE` | 60 | real content, but an old certificate and no change since the previous observation (monitor mode). |
| `LIVE` | 70 to 100 | real content and upkeep. 70 when the server blocks bots or shows a challenge page and we assume it is alive, 85 for a same-name migration or a JavaScript shell, 100 with a fresh certificate. |

### 🔁 Monitor mode

Run the same list on a schedule with `mode: monitor`. The Actor keeps the previous run's verdicts in a key-value store of its own and each `domain` item carries `changed`, `changes`, `previous_state` and `previous_seen_at`. The first run marks every item `first_run: true`. Set `changes_only` to push only what changed.

Six things are reported as a change:

| Change | What it says |
|---|---|
| `state: LIVE -> PARKED` | the verdict moved, in either direction |
| `redirect: none -> acquirer.com` | the domain now lands somewhere else, or stopped doing so |
| `certificate expired` | the certificate was valid on the previous run and is expired now |
| `mail records gone` | the domain had MX records on the previous run and has none now |
| `stopped answering` | the site answered on the previous run and does not now |
| `homepage title changed` | the title changed while the verdict stayed the same, which is how a quiet rebrand or a takeover page shows up |

On top of those, a registration expiring within 30 days is added to `changes` as `registration expires in N days`.

**Run monitor mode from a saved task.** The baseline lives in a named key-value store, `domain-check-monitor-<task id>`, in your own account. A run started without a task has no task id, so it uses `domain-check-monitor-default`, and two schedules started that way share one store and report each other's changes. Save the input as a task, schedule the task, and each list keeps its own baseline.

### 💰 Pricing

| Event | Price | When |
|---|---|---|
| `domain_check` | $0.001 | once per domain observed, whatever the verdict. The check is the work. |
| `domain_history` | $0.003 | once per domain the archive knows. A domain with no archive costs nothing. |
| Actor start | $0.00005 | once per run |
| rejected input, a domain we could not observe, a rate limit, an upstream failure | $0 | never |

Worked examples, event charges only. The Actor start adds $0.00005 a run, which does not move any figure here: a list of 5,000 leads, $5. A 200-company portfolio watched weekly, $0.20 a week. One domain with its history, $0.004. 50,000 domains with history, $200.

### ⚠️ Limits, stated plainly

- Homepage only. No crawling, no JavaScript rendering, no login, no CAPTCHA solving. A site that blocks bots is reported as `LIVE` with a score of 70 and the reason says so. A `robots.txt` that disallows us is honoured: the page is not read and the verdict says "assumed live, page not read".
- Registration facts come only from TLDs whose registry runs RDAP. `.il` and `.so` come back `unavailable` with the reason, and so do a few others.
- Archive history depends on archive.org having captured the site. New or small sites may have none, and that costs nothing.
- A verdict is an observation at check time. `LIVE_STALE` needs a second observation (monitor mode) or the history's `last_worked_years_ago`.
- Up to 10,000 domains per run, 25 checked per call to the service, 20 in flight, 25 seconds per domain. A domain that does not complete inside that is `could_not_observe`, uncharged.
- When our own resolver fails its canary check, every domain in that call is `could_not_observe` rather than dead. Absence of observation is not a finding.

### 🔎 How the check works

1. The input is read as a domain, a website URL or an email address, and reduced to the domain. An IP address, a reserved name and anything that is not a domain is rejected before any paid step.
2. DNS is resolved: A records, name servers, MX and the email provider behind them, SPF and DMARC.
3. The homepage is fetched once, following redirects, and the redirect chain, the final URL, the status, the response time, the title and the page text are recorded. `robots.txt` is read first and honoured.
4. The TLS certificate is read from the handshake, and the registry's own RDAP server is asked for registrar, dates, status codes, name servers and DNSSEC. Registrant contact fields are never read.
5. The verdict rules run top to bottom over those facts and the first match wins, so the `reason` on every row names the rule that fired. In history mode archive.org's public API supplies first capture, last capture, years online and the last time the site actually returned a page.
6. Nothing is estimated and no language model is involved. A domain the check could not observe is `could_not_observe`, never a verdict, and never charged.

### 🔐 Data, licences and privacy

- **Public sources only.** DNS, one homepage fetch with an honest user agent, one TLS handshake, the registry's own RDAP server and archive.org's public API. No browser, no proxies, no login, no CAPTCHA solving, and `robots.txt` is honoured.
- **RDAP, not WHOIS scraping.** Registration facts come from the registries' public RDAP successor to WHOIS, and registrant contact fields are never read, so no personal data comes back with them.
- **Pass-through.** Every domain is observed at the moment of the run and passed through to your run's dataset, under your account's retention settings. Operational logs keep the query, timing and the billing outcome, which is what running and billing the service needs.
- **Your baseline stays yours.** Monitor mode keeps the previous run's verdicts in a named key-value store in your own Apify account, one per saved task, and nothing else.
- **Not personal data.** The check reads a company's public homepage and a registry's public record. It does not read personal pages, mailboxes or registrant contacts.

### ⏱️ How long does a run take?

Check and monitor entries go to the service 25 at a time, history entries 3 at a time because archive.org answers in 12 to 17 seconds per domain. Each call has a 290 second wall-clock deadline in the Actor, and the calls run one after another, so a bulk domain check of 5,000 leads is 200 calls and finishes in well under an hour. A single domain answers in a few seconds.

### 🔌 Website liveness API, clients and integrations

Run the Actor from the Apify Console, from the [Apify API](https://docs.apify.com/api/v2), from the Python or JavaScript client, from the Apify MCP server, or from Make, Zapier and n8n through the Apify integrations. Save the input as a task, schedule the task, and set a webhook on run completion to pull only the changed domains into your own system.

```python
from apify_client import ApifyClient

client = ApifyClient("<YOUR_API_TOKEN>")
run = client.actor("pvalyou/website-liveness-check").call(run_input={
    "mode": "check",
    "domains": ["stripe.com", "notion.so", "sedo.com",
                {"domain": "checkpoint.com", "name": "Check Point"}],
    "links": False,
})
for item in client.dataset(run["defaultDatasetId"]).iterate_items():
    print(item["type"], item.get("domain"), item.get("state"), item.get("score"),
          item.get("reason"), item.get("has_mx"), item.get("charged"))
```

### 🔗 Works well with

The same input, a company domain, opens our other Actors: [Company Enrichment API](https://apify.com/pvalyou/company-record) for firmographics, classification and funding, [Job Postings](https://apify.com/pvalyou/job-postings) for the open roles from the company's own job board, [Patent Lookup](https://apify.com/pvalyou/patent-lookup) for its patents by applicant, [Company Registry Lookup](https://apify.com/pvalyou/company-registry-lookup) for its registry record, and [LinkedIn Person Enrichment](https://apify.com/pvalyou/linkedin-person-enrichment) for its people. Together they turn a list of domains into a company profile without a data broker.

### ❓ FAQ

#### Is this legal?

Yes. The check reads what a browser reads on a public homepage, once, with an honest user agent, and honours `robots.txt`. Registration facts come from RDAP, the registries' public successor to WHOIS, and registrant contact fields are never read. Archive history comes from archive.org's public API at its published pace. There is no login, no bypass and no personal data.

#### Is this a WHOIS lookup?

It is the part of a WHOIS lookup you can act on, plus the page itself. Registrar, creation date, domain age, expiry date, days to expiry, status codes, name servers and DNSSEC come from RDAP, the registries' own successor to WHOIS. As a whois alternative it adds the verdict: the domain resolves, answers, and is a real site rather than a parked page.

#### How do I clean a lead list in bulk?

Run the list in check mode, then drop every row whose `state` is `DEAD_DNS`, `DEAD_UNREACHABLE`, `EXPIRED` or `PARKED`, and every row with `has_mx: false` if you are about to email it. `only_states` does the filtering for you. Dead domain finding, parked domain detection and email domain validation are the same run.

#### Why is a domain that obviously works marked `PLACEHOLDER`?

Its homepage sends almost no text and no sign of a JavaScript application. Give the company's `name` in the entry: `company_name_on_page` then tells you whether the page is about that company at all.

#### Why does a live site have no registration facts?

Its TLD has no RDAP server. The answer says `unavailable` with `no_rdap_for_tld` rather than guessing.

#### Can it tell me why a domain redirects to another company?

It records the destination and, when the landing page announces an acquisition, merger or rebrand, quotes that sentence in `transition_notice`. It does not infer a cause the page does not state.

#### Does it read JavaScript-rendered pages?

No. It recognises the application shell and marks the site `LIVE` (score 85). Tech hints, links and the organization record still come from the HTML the server sends.

#### Can I use it from code?

Yes: the Apify API, the Python and JavaScript clients, and the MCP server. Each entry may be an object with `domain`, `name` and `mode`. See the snippet above.

### 💬 Support and feedback

Found a domain with a verdict you disagree with, an email provider or a technology we did not recognise, or a TLD whose registration facts you need? Open an issue on this Actor's page with the domain and what you expected. The reason and the raw facts are on every row, so a report with the row attached is the fastest way to a fix.

### 📝 Changelog

- **0.1** First public release: check, history and monitor modes, eight verdicts with a 0 to 100 score, registration facts from RDAP, email provider and SPF/DMARC, certificate, hosting, technology fingerprints, organization record and social links, archive history, two priced events.

# Actor input Schema

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

Check: one verdict per domain with the evidence (registration, email, certificate, hosting, tech, social links). History: the archive.org record per domain (first seen, last seen, years online, last time it worked). Monitor: check mode on a schedule, every item says what changed since the previous run.

## `domains` (type: `array`):

One per line: a domain (acme.com), a website URL or an email address (the domain part is used). For programmatic use each entry may also be an object with 'domain', an optional 'name' (the company's name, checked against the page) and its own 'mode'.

## `registration` (type: `boolean`):

Registrar, creation and expiry dates, domain age, status codes, name servers and DNSSEC from the registry's RDAP server. Off saves one request per domain.

## `profile` (type: `boolean`):

Email provider and SPF/DMARC, hosting hint, tech hints, meta description and language, structured organization data, social profile links. All read from the same homepage fetch.

## `links` (type: `boolean`):

The homepage's links to pricing, about, team, contact, careers, docs, blog, press, terms and privacy pages, mapped to named fields.

## `only_states` (type: `array`):

Return rows only for the chosen verdicts (for example PARKED and DEAD\_DNS to list the dead ones). Every domain is still checked and charged.

## `changes_only` (type: `boolean`):

In monitor mode, push only the domains whose verdict, redirect, certificate or registration changed since the previous run (and every domain on the first run).

## Actor input object example

```json
{
  "mode": "check",
  "domains": [
    "stripe.com",
    "notion.so",
    "sedo.com",
    "https://www.checkpoint.com/"
  ],
  "registration": true,
  "profile": true,
  "links": true,
  "changes_only": false
}
```

# Actor output Schema

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

Every item of the run with every field it carries: domain rows, history rows and error items.

## `domains` (type: `string`):

Every item of the run, shown as the check columns: domain, verdict, score, reason, redirect, email, registrar, dates, hosting, charged. A view picks the columns and never drops rows, so history rows and error rows are in this table too, with the check columns they do not carry left blank.

## `history` (type: `string`):

Every item of the run, shown as the history columns: first and last capture, months captured, last working capture, years online, how long ago it last worked, charged. A view picks the columns and never drops rows, so check rows and error rows are in this table too, with the history columns they do not carry left blank.

# 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 = {
    "domains": [
        "stripe.com",
        "notion.so",
        "sedo.com",
        "https://www.checkpoint.com/"
    ]
};

// Run the Actor and wait for it to finish
const run = await client.actor("pvalyou/website-liveness-check").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 = { "domains": [
        "stripe.com",
        "notion.so",
        "sedo.com",
        "https://www.checkpoint.com/",
    ] }

# Run the Actor and wait for it to finish
run = client.actor("pvalyou/website-liveness-check").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 '{
  "domains": [
    "stripe.com",
    "notion.so",
    "sedo.com",
    "https://www.checkpoint.com/"
  ]
}' |
apify call pvalyou/website-liveness-check --silent --output-dataset

```

## MCP server setup

```json
{
    "mcpServers": {
        "apify": {
            "type": "http",
            "url": "https://mcp.apify.com/?tools=fetch-actor-details,pvalyou/website-liveness-check"
        }
    }
}

```

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/zqQoYbhRxwnPc7Ih8/builds/K0iG2HrYvTS17qSIT/openapi.json