Domain Registration Lifecycle - Expiry & RDAP Changes

SOURCE COVERAGE & PRACTICAL LIMITS

Full product guide

Documentation captured from build 1.0.1. Example outputs retain their original sample context; they are not live results.

Domain Registration Lifecycle — Expiry & RDAP Changes

Turn an important .com or .net domain watchlist into clean registration records, expiry windows and evidence of what changed. Use the official registry response to track renewals, registrar changes, nameserver changes and registration status without collecting personal contact details.

Start with example.com. No API key, proxy setup or account login is required. Each row includes its authoritative RDAP URL and observation time. The Actor checks IANA's bootstrap directory before querying the supported registry.

Built for small domain portfolios

This is an official registration watchlist for .com and .net, with up to 20 domains per run. It is not a domain availability search, a WHOIS contact database or a replacement for your registrar's billing and renewal notices. Registry expiration can differ from the date a registrar displays to its customer.

Get a useful first result

1. Enter the domains you care about, such as example.com and example.net.
2. Keep Maximum saved rows at least as large as your domain list.
3. Run the Actor, then open Domain observations for data or Readable run report for a quick coverage check.

You can paste website URLs too: https://www.example.com/about becomes example.com. Other subdomains and TLDs are rejected rather than guessed. Internationalized .com/.net names are normalized to their ASCII registration form; the readable Unicode name remains in the output.

{
  "domains": ["example.com"],
  "maxResults": 1
}

Three ready-to-use recipes

1. One registration record

Use the minimal input above to inspect a single domain. A successful observation includes source evidence and available registration fields, even when some registry values are absent.

2. A repeatable portfolio watchlist

{
  "domains": ["example.com", "example.net"],
  "maxResults": 2,
  "comparePrevious": true,
  "snapshotName": "portfolio-registration"
}

The first complete run establishes a baseline. Later complete runs identify changed or unchanged records and include changedFields plus the previous values. Use the same domain set and baseline label. Domain order does not matter; changing the set creates a separate baseline.

3. Inspect a .net registration independently

{
  "domains": ["example.net"],
  "maxResults": 1,
  "comparePrevious": false
}

This uses the official .net registry route and returns one observation without depending on any prior run. Use it to confirm the second supported TLD before building your own watchlist.

Deliver changes only

{
  "domains": ["example.com", "example.net"],
  "maxResults": 2,
  "onlyChanges": true,
  "snapshotName": "portfolio-registration"
}

This reuses recipe 2's baseline and skips unchanged domains. On the first run of a new baseline it returns all observations. A complete repeat run can correctly save zero rows; SUMMARY.unchangedSkipped explains that result. Scheduling a modest daily or weekly watchlist in Apify can support a renewal-review workflow. This Actor does not enable a schedule or send any messages by itself.

The output contract

comparisonStatus is not_requested, new, changed or unchanged. The comparison includes registration status, registration/expiration/change dates, registrar identities, statuses, nameservers, DNSSEC delegation and the expiry window. The daily countdown and the registry database refresh timestamp are excluded, so ordinary polling does not generate false changes. Crossing a 90-, 30- or 7-day expiry boundary does produce a change.

An abbreviated row shape is shown below. Values are illustrative; inspect your run for current evidence.

{
  "domain": "example.com",
  "rdapStatus": "registered",
  "expiresAt": "2027-08-13T04:00:00.000Z",
  "expiryWindow": "beyond_90_days",
  "comparisonStatus": "not_requested",
  "changedFields": [],
  "sourceUrl": "https://rdap.verisign.com/com/v1/domain/example.com"
}

Nameservers and DNSSEC are reported from the registry record. The Actor does not resolve watched domains, test DNS propagation, validate certificates, or infer that a website is online.

Coverage you can verify

Every run saves a machine-readable SUMMARY and a self-contained RUN_REPORT. Check incomplete, sourceCoverage, failedSources, sourcesNotReached, rowsSaved and historyUpdated before treating a run as a full portfolio check.

• A source refusal, malformed response, time limit, request limit or output failure makes the run incomplete. Valid observations may still be saved, with the partial coverage recorded.
• A maximum-charge or result limit can leave part of the input unreached. The old baseline remains unchanged.
• History advances only when every requested domain has a valid observation and every required output row has been acknowledged. Skipped unchanged records still count toward complete source coverage.
• A registry 404 must contain a valid RDAP error response. HTML error pages, access blocks and rate limits never become not_found records.
• A domain omitted from an incomplete run is never marked deleted or available. A 404 is only evidence that this registry route returned no record at that time; reserved names and other registration rules can still prevent registration.
• A concurrent baseline change detected before saving prevents the overwrite. Avoid simultaneous runs with the same watchlist and label; storage does not provide a transactional cross-run lock.

If all requested registration observations fail, the Actor fails with diagnostic evidence. If some succeed, the run reports partial coverage. A successful Apify run status alone is not proof that every input was checked.

Pricing and practical bounds

The configured price is $0.002 per saved domain observation, plus a $0.00005 Actor Start event per run. A complete 20-domain run saves at most 20 paid rows, or $0.04005 in Actor events including the start. Check the current Store pricing and your platform plan before running; applicable platform charges are separate.

Each validated registry 200 or conforming registry 404 can produce one row. There are no paid error rows, separate change-event rows or hidden contact-enrichment calls. Unchanged records skipped by onlyChanges incur no dataset-item event. The Actor checks the remaining event allowance before its first paid row, and it does not advance history after a charge cap.

Requests are serial and spaced at least one second apart on each origin. The hard bounds are 20 input domains, 25 HTTP requests and a 30–120 second time budget. It stops on a registry rate limit without switching endpoints, proxies or identities. The default time budget is 90 seconds.

Source scope and responsible use

Source discovery uses IANA's RDAP DNS bootstrap directory. This version accepts only the reviewed HTTPS .com and .net routes at Verisign. If IANA changes those routes, it stops rather than contacting an unreviewed host. It does not follow registrar referrals or redirects.

The IANA directory fetch respects its robots policy. Registration queries use the explicitly supported RDAP API, with bounded response sizes and public-address validation. See Verisign's RDAP help and RDAP terms of use. Use a small, legitimate domain watchlist; do not use this tool for high-volume queries or unsolicited marketing.

The output excludes registrant identities, email addresses, phone numbers and postal addresses. Only the registrar's business name and public IANA ID are retained. Source data may be incomplete or delayed, and an expiration timestamp is not a renewal guarantee.

Use in an AI or data workflow

Give this Actor an explicit .com/.net watchlist. Read SUMMARY first, then use the dataset's sourceUrl, observedAt, changedFields and previous fields to explain each conclusion. Treat null as unavailable or ambiguous, not as a negative answer. Do not turn not_found into a purchase or availability recommendation.

Export JSON or CSV from the dataset, or use the Apify API with a saved task. Keep access credentials in your integration's secret settings, not in Actor input. The Actor runs with Limited permissions and requires no external service key.

For input recipes and the wider portfolio, visit Mayd It data tools. Use this Actor's Issues tab for reproducible source failures, including the run URL and input scope without credentials.