Webhook-Based Domain Monitoring in 2026: DNS, WHOIS, SSL, Headers, and Ports

The Gap Between a Check and an Operational Alert

DNS records drift, WHOIS expiration dates approach quietly, certificates renew with different issuers, headers disappear during deployments, and public ports show up where no one expected them. Teams often have a script for each problem, but the script is rarely the real workflow. The workflow is what happens after a finding is detected: who gets told, what evidence they receive, whether the alert repeats, and how the system avoids sending five tickets for one underlying change.

This post focuses on webhook-based routing. Ops.Tools publicly verifies webhook support, bulk processing, REST JSON APIs, usage reporting, and checks for DNS, WHOIS, IP, SSL, HTTP headers, ports, and email details. That does not mean every downstream tool is a native integration. If your worker sends a signed JSON payload into a webhook receiver that then posts to Slack, opens a Jira ticket, or forwards to a SIEM, describe it exactly that way. Clear wording keeps the architecture honest and helps security reviewers understand what they are approving.

What to Monitor

Start with assets that can break customer traffic, security posture, or compliance evidence. A practical domain monitoring manifest usually includes production domains, customer-facing subdomains, mail domains, partner domains, vanity domains, redirect domains, and externally reachable services. For each asset, store the expected record values, renewal owner, certificate policy, allowed headers, and approved public ports.

Step-by-Step Webhook Workflow

1. Build the asset manifest. Store each domain, expected checks, severity rules, owner, and escalation path. Keep monitoring intent close to the asset so a finding is actionable.
2. Run checks in batches. Use bulk-friendly scheduling for recurring audits and avoid putting every asset on the same minute boundary. Track request volume so webhook noise and API usage grow predictably.
3. Normalize the result. Convert provider responses into a common finding shape withcheckType, severity, expected, observed, andrawEvidence.
4. Deduplicate before delivery. Use a stable key such asdomain:checkType:policy:observedHash. Re-send only when severity changes, ownership changes, or the finding remains unresolved after an agreed interval.
5. Post to your webhook receiver. Sign payloads, set timeouts, retry transient failures, and preserve the response status from the receiver. A failed webhook delivery should be visible in operations logs.
6. Route by owner and severity. A missing HSTS header might create a backlog item, while a certificate failure on a production API may page immediately. Treat warning, failure, and incident states differently.
7. Close the loop. Store resolution notes, final observed state, and the raw evidence that proved the fix. Monitoring without closure becomes a noisy inbox.

API Examples for Finding Collection

These examples use verified Ops.Tools endpoint names from the local generated SDK and OpenAPI output. The webhook delivery is shown as your own receiver, not as a claim that Ops.Tools has a native integration with a specific incident platform.

cURL: collect DNS, SSL, header, and port evidence

API_KEY="$OPS_TOOLS_API_KEY"
BASE="https://api.ops.tools"
DOMAIN="example.com"

curl -sG "$BASE/v1-dns-lookup" \
  -H "x-api-key: $API_KEY" \
  --data-urlencode "address=$DOMAIN" \
  --data-urlencode "type=TXT"

curl -sG "$BASE/v1-whois-data" \
  -H "x-api-key: $API_KEY" \
  --data-urlencode "domain=$DOMAIN" \
  --data-urlencode "parseWhoisToJson=true"

curl -sG "$BASE/v1-ssl-checker" \
  -H "x-api-key: $API_KEY" \
  --data-urlencode "domain=$DOMAIN"

curl -sG "$BASE/v1-analyze-http" \
  -H "x-api-key: $API_KEY" \
  --data-urlencode "url=https://$DOMAIN"

curl -sG "$BASE/v1-port-scanner" \
  -H "x-api-key: $API_KEY" \
  --data-urlencode "target=$DOMAIN" \
  --data-urlencode "ports=80,443,8443"

TypeScript: send a signed finding to your receiver

import crypto from 'node:crypto';

type Finding = {
  asset: string;
  checkType: 'dns' | 'whois' | 'ip' | 'ssl' | 'headers' | 'ports';
  severity: 'info' | 'warning' | 'critical';
  expected: unknown;
  observed: unknown;
  owner: string;
  evidenceUrl?: string;
  firstSeenAt: string;
  dedupeKey: string;
};

function signPayload(payload: string, secret: string) {
  return crypto.createHmac('sha256', secret).update(payload).digest('hex');
}

async function deliverFinding(finding: Finding) {
  const body = JSON.stringify(finding);
  const signature = signPayload(body, process.env.WEBHOOK_SECRET ?? '');

  const response = await fetch(process.env.DOMAIN_ALERT_WEBHOOK_URL ?? '', {
    method: 'POST',
    headers: {
      'content-type': 'application/json',
      'x-domain-alert-signature': signature,
    },
    body,
  });

  if (!response.ok) {
    throw new Error(`Webhook receiver returned ${response.status}`);
  }
}

TypeScript: create a certificate finding

async function getJson<T>(path: string, params: Record<string, string>) {
  const url = new URL(path, 'https://api.ops.tools');
  for (const [key, value] of Object.entries(params)) url.searchParams.set(key, value);
  const response = await fetch(url, {
    headers: { 'x-api-key': process.env.OPS_TOOLS_API_KEY ?? '' },
  });
  if (!response.ok) throw new Error(`${path} returned ${response.status}`);
  return (await response.json()) as T;
}

async function checkCertificate(domain: string, owner: string) {
  const result = await getJson<{ certificate: { daysRemaining: number; isValid: boolean; issuer: string } }>(
    '/v1-ssl-checker',
    { domain },
  );

  if (result.certificate.isValid && result.certificate.daysRemaining > 21) {
    return;
  }

  await deliverFinding({
    asset: domain,
    checkType: 'ssl',
    severity: result.certificate.isValid ? 'warning' : 'critical',
    expected: { minDaysRemaining: 21, validCertificate: true },
    observed: result.certificate,
    owner,
    firstSeenAt: new Date().toISOString(),
    dedupeKey: `${domain}:ssl:${result.certificate.issuer}:${result.certificate.daysRemaining}`,
  });
}

Webhook Payload Design

A domain monitoring webhook should be boring, stable, and easy to replay. Avoid payloads that only say "domain failed". The receiver needs enough context to route the event without making another API call.

Routing Rules That Keep Alerts Useful

• Route by asset owner first, not by tool owner. The DNS script maintainer is rarely the right responder.
• Send release-blocking checks to CI/CD logs and pull-request status, not only to chat.
• Send certificate failures and unexpected open production ports to on-call when they affect customer traffic.
• Send WHOIS expiration and registrar status changes to domain operations with renewal context.
• Send header policy drift to application owners unless the missing header is part of a security incident.
• Throttle repeated warnings, but never hide a severity increase.

Reliability Safeguards for Webhook Delivery

Webhook workflows fail in ordinary ways: the receiver is down, the secret rotated, a payload gets too large, a downstream ticketing API throttles, or a chat channel no longer exists. Treat delivery as part of the monitoring product, not as a side effect of the checker. Every attempt should have a timestamp, receiver URL identifier, response status, retry count, and final disposition. That lets operators distinguish "the domain is healthy" from "the finding never reached the owner".

Sign payloads with a shared secret and reject unsigned requests at the receiver. Rotate secrets with overlap so old workers and new receivers can coexist briefly. Use short network timeouts, retry only transient status codes, and send failed deliveries to a dead-letter queue or manual review list. A webhook system that retries every failure forever can create a second incident while trying to report the first one.

Idempotency is just as important. The same DNS drift or certificate warning may be seen by multiple scheduled runs. The receiver should treat dedupeKey as the stable identity for an unresolved finding, update the existing record, and preserve the first-seen timestamp. Only create a new event when the asset, policy, observed value, or severity materially changes.

Monitoring Cadence and Bulk Workloads

Not every check needs the same cadence. DNS records that gate a live cutover may need release-time validation. Domain expiration checks may run daily or weekly depending on portfolio risk. SSL certificate checks often become urgent only near renewal thresholds, but they still need enough history to catch unexpected issuer, SAN, or chain changes. Header and port checks can be tied to deployment windows, scheduled exposure reviews, or both.

Bulk processing matters because large domain inventories are rarely uniform. A portfolio can contain production domains, marketing domains, parked domains, customer-managed domains, and legacy assets with no clear owner. Batch by owner or risk tier instead of running one giant anonymous scan. That makes webhook routing simpler and lets teams tune request volume against plan limits, retry behavior, and expected evidence retention.

For CI/CD workflows, avoid posting every warning into the same incident channel. A release gate should report what blocked the deployment, where the raw evidence lives, and which owner can approve an exception. Recurring monitoring should track unresolved state over time. Incident enrichment should attach evidence to an existing case rather than opening a parallel one. Same data, different workflow contract.

Where Competitor Research Points

Current market pages show the same direction: domain monitoring vendors emphasize DNS, WHOIS, SSL, and webhook alerts; IP data vendors emphasize API products and cloud/SIEM-style integrations; security data platforms emphasize enrichment for automation products. That supports a practical content angle: buyers are not only asking "can this API return data?" They are asking whether findings can move into existing operating systems without creating a fragile integration story.

Security Review Notes

A webhook workflow touches two trust boundaries: the API that collects evidence and the receiver that routes findings. Keep the Ops.Tools API key in the checker, not in downstream chat or ticket payloads. Store raw evidence in a controlled location and send references when payloads would expose sensitive context. Avoid posting full WHOIS records, internal owner maps, or customer asset lists to broad channels.

Security reviewers should ask for the manifest owner, API key owner, webhook receiver owner, retention period, secret rotation process, and exception policy. Those details are not decorative. They decide who can change monitoring scope, who can silence alerts, and how the company proves that a finding was handled.

A Simple Starting Scope

Start with one workflow before expanding the monitor. A good first pass is ten production domains, DNS MX and TXT checks, WHOIS expiration context, SSL validity, HTTP security headers, and ports 80 and 443. Route critical failures to the on-call path, warnings to the owning team, and informational changes to a weekly review. Once responders trust the payloads and dedupe behavior, add more domains, extra ports, email-auth detail checks, or tighter release-gate rules.

FAQs

The strongest webhook workflows are explicit about what they do and what they do not do. Use APIs for the evidence, use your automation layer for routing, and keep native integration claims reserved for capabilities that are actually documented.