Domain Reputation Checker API in Node.js

A domain can be old, encrypted and reachable—and still be a bad business decision. A new domain can be perfectly legitimate. That is why a useful domain reputation checker should not return an unexplained green badge.

For technical screening, the better question is: what can we observe, how much confidence does each signal deserve, and what remains unknown?

This guide builds that evidence-first workflow in Node.js. We will audit registration history through RDAP, DNS configuration, TLS health, HTTPS behavior and browser security headers. Then we will turn the response into an application policy that preserves uncertainty instead of treating a 0–100 score as proof of safety.

Important: A technical website trust score is decision support. It is not malware detection, a phishing blocklist, proof of ownership or a guarantee that a site is legitimate.

What a website trust score should measure

“Reputation” can mean email-sender reputation, search authority, customer reviews, IP abuse history or malware intelligence. This API answers a narrower, auditable question: does the domain’s public technical posture look established and well maintained right now?

Category	Points	Evidence
Registration	20	RDAP age, expiry, registrar, status and DNSSEC signal
DNS	20	Public A/AAAA reachability, nameservers and CAA
TLS	25	Certificate trust, hostname coverage, chain, expiry and protocol
HTTPS	15	Secure reachability, HTTP upgrade and final response
Security headers	20	HSTS, CSP, clickjacking protection, nosniff and privacy controls

Every point should be traceable to evidence. If a registration source times out, the system should mark that category unknown and expose a provisional maximum—not invent certainty.

RDAP is the modern registration-data layer

Many developers search for a WHOIS API when they need domain age or expiry. RDAP is the standards-based successor. ICANN describes RDAP as the replacement for WHOIS. RFC 9082 defines uniform HTTP query patterns, while RFC 9083 defines structured JSON responses. Compared with scraping free-form WHOIS text, RDAP gives an integration a more consistent data contract.

That does not mean every registry exposes every field. Privacy policy, registry implementation and upstream availability can leave fields missing or redacted. Your application should model registration data as evidence that may be incomplete.

Age is contextual, not a verdict. A domain registered yesterday deserves more scrutiny in a high-value vendor workflow, but “new” does not mean “malicious.” Likewise, a 15-year-old compromised domain is not automatically safe.

Call the API from Node.js

Current Node.js releases provide a global fetch(). Store your RapidAPI key in an environment variable and copy the exact API host from the marketplace code snippet.

const RAPIDAPI_HOST =
  "domain-intelligence-website-trust-score.p.rapidapi.com";

export async function auditDomain(domain, options = {}) {
  const params = new URLSearchParams({
    domain,
    timeout_ms: String(options.timeoutMs ?? 6000),
    force_refresh: String(options.forceRefresh ?? false),
  });

  const response = await fetch(
    "https://" + RAPIDAPI_HOST + "/audit?" + params,
    {
      headers: {
        "x-rapidapi-host": RAPIDAPI_HOST,
        "x-rapidapi-key": process.env.RAPIDAPI_KEY,
      },
      signal: AbortSignal.timeout(12000),
    },
  );

  const body = await response.json();
  if (!response.ok) {
    throw new Error(body?.error?.message ??
      "Domain audit failed: " + response.status);
  }
  return body;
}

RapidAPI requires both authentication headers. Keep the provider host configurable because marketplace hostnames can differ from product slugs.

Read evidence before the summary

Useful fields include score.value and score.grade for a compact summary; score.provisional and score.maximum_possible before a threshold decision; each check’s status, points and details for auditability; and findings[].code plus severity for stable automation.

{
  "score": {
    "value": 82,
    "grade": "B",
    "trust_level": "good",
    "provisional": false,
    "maximum_possible": 100
  },
  "checks": {
    "registration": { "status": "pass", "points": 20 },
    "dns": { "status": "pass", "points": 18 },
    "tls": { "status": "pass", "points": 25 },
    "https": { "status": "pass", "points": 15 },
    "security_headers": { "status": "warn", "points": 4 }
  }
}

This is an illustrative response shape. Live values depend on the target and what upstream systems reveal. Do not throw away the checks after storing the score: the evidence explains why the number changed and lets you revise policy without re-auditing historical decisions.

Build a policy that preserves uncertainty

export function decideDomain(audit, context = {}) {
  if (!audit?.success) {
    return { decision: "review", reason: "audit did not complete" };
  }

  const score = audit.score?.value;
  const severe = (audit.findings ?? []).filter((finding) =>
    ["critical", "high"].includes(finding.severity),
  );

  if (audit.score?.provisional) {
    return { decision: "review",
      reason: "one or more evidence sources were unavailable" };
  }

  if (severe.length || Number(score) < (context.blockBelow ?? 40)) {
    return { decision: "block",
      reason: severe[0]?.code ?? "technical score below policy" };
  }

  if (Number(score) >= (context.allowAt ?? 75)) {
    return { decision: "allow",
      reason: "technical posture meets policy" };
  }

  return { decision: "review",
    reason: "manual or additional checks required" };
}

These thresholds are examples, not universal risk rules. Vendor onboarding, a public link preview and a high-value payout flow have different costs when a decision is wrong. Even an allow result should mean only “the technical posture met this policy”—never “the organization is genuine.”

What each signal can—and cannot—prove

Registration history

Registration age, status and expiry can reveal operational maturity or neglect. They cannot prove ownership or intent.

DNS resilience

Public addresses and nameservers show reachability and delegation. DNS can still be misconfigured temporarily, and records can change quickly.

TLS certificate health

A trusted, unexpired certificate proves that a client can authenticate the presented hostname under the web PKI. It does not prove that the business behind the site is trustworthy. Free certificates are normal.

HTTPS behavior

HTTP-to-HTTPS upgrades reduce accidental plaintext access. A successful status code confirms current reachability, not secure application logic.

Browser security headers

HSTS, CSP and X-Content-Type-Options reduce specific browser risks. OWASP notes that configuration matters: an overly broad CSP offers little protection, while a long HSTS policy can create availability problems if certificates are mismanaged.

Fail safely during network problems

RDAP, DNS, TLS and HTTP are independent network operations. Use a total request deadline; treat 429 and transient 5xx responses as retryable; preserve a provisional or review state when evidence is missing; use exponential backoff; and log request IDs and finding codes without logging API keys.

The API caches an audit for five minutes. Use force_refresh=true when fresh evidence is materially more important than lower latency—not on every call by default.

Production use cases

Vendor onboarding: identify an expiring certificate, a recently registered domain or missing HTTPS before approval; combine it with business and ownership checks.
Fraud-rule enrichment: add domain age and technical posture as model features, not the sole reason to deny a person or business.
Security dashboards: show exactly which controls pass, fail or remain unknown.
Lead qualification: use technical maturity as enrichment, not as buying intent.
Domain monitoring: alert on meaningful changes such as expiring TLS or newly missing HSTS.

Test before connecting the score to a decision

Use domains you control: an established HTTPS site, one without an HTTP-to-HTTPS redirect, a test certificate failure, malformed input, a private-network hostname, a simulated RDAP timeout and a mixed bulk request. Assert your policy contract—allow, review, block and the reason—not an exact external score that can change.

Try the Domain Intelligence API

The Domain Intelligence & Website Trust Score API on RapidAPI returns an explainable score, per-check evidence, stable finding codes and prioritized remediation. The Basic plan includes 50 requests per month.

Start with domains you control. Compare the response with your actual DNS, certificate and headers, then tune the application policy around the cost of a wrong decision.

Frequently asked questions

Is a website trust score proof that a site is safe?

No. It summarizes observable technical posture. It does not inspect malware, phishing content, ownership, business legitimacy or future behavior.

Is RDAP the same as WHOIS?

Both expose registration data, but RDAP uses standardized HTTP queries and structured JSON. Published fields still vary by registry and access policy.

Does an old domain have a better reputation?

Age can be one stability signal, but it is not proof. Old domains can be compromised, sold or repurposed; new domains can belong to legitimate launches.

Can I audit several domains in one request?

Yes. The bulk endpoint accepts one to five domains and reports failures per item.

Sources and further reading

Disclosure: StadiaSoft publishes the RapidAPI product discussed in this guide. This article documents its boundaries as well as its capabilities.

Domain Reputation Checker API in Node.js: Build an Explainable Website Trust Score