Client Infrastructure Audit API Playbook for MSPs

Why Client Audits Break Down

A client asks for a domain and infrastructure review. The first audit goes fine: someone checks DNS records, looks up registration data, opens a certificate scanner, copies a few IP details, and drops screenshots into a slide deck. The second audit takes longer because the client added subdomains. By the fifth client, the team is comparing screenshots by hand and arguing over which findings are real risks.

That model does not scale for MSPs. The commercial problem is margin. Every manual lookup burns delivery time, and every inconsistent report makes renewals harder. The operational problem is evidence quality. Clients need to know which domains are expiring, which records drifted, which certificates are weak or near renewal, and which IPs belong to expected networks. A repeatable API workflow gives the delivery team a consistent audit package and gives the account team a clearer reason to sell ongoing monitoring.

What to Audit for Every Client

Keep the scope tight. The first version of a client audit should answer four questions: does the domain resolve the way the client expects, is the registration healthy, do the resolved IP addresses match known ownership and geography, and are public certificates valid with enough renewal runway?

Ops.Tools also has live pages for adjacent checks such as HTTP header analysis and port scanning. Treat those as optional audit modules only when they are in scope for the client contract.

A Repeatable Workflow for Billable Audits

The core workflow is simple: collect the asset list, run baseline checks, classify exceptions, and ship a report. The difference between a profitable audit and a one-off scramble is that each step produces structured data you can reuse next month.

1. Collect scope. Ask the client for production domains, critical subdomains, web endpoints, and known IP addresses. Do not scan beyond the agreed list.
2. Run the baseline. Query DNS, WHOIS, IP, and SSL endpoints, then store raw JSON and a small normalized summary by client and asset.
3. Classify exceptions. Compare results against policy: renewal thresholds, approved registrars, expected nameservers, expected hosting networks, and required DNS records.
4. Deliver evidence. Give the client a short report with severity, owner, recommendation, and API-backed evidence. Keep raw output available for technical follow-up.

Technical Implementation

The repo's generated OpenAPI client verifies the app API paths used below. The public API requires an API key; store it in your secrets manager and pass it in headers. The exact authentication header depends on your account setup, so keep it consistent with the API documentation and dashboard-generated key format.

cURL: run the four core checks

API="https://ops.tools/api"
KEY="$OPS_TOOLS_API_KEY"
DOMAIN="example.com"

curl -s "$API/v1-dns-lookup?address=$DOMAIN&type=A" \
  -H "Authorization: Bearer $KEY"

curl -s "$API/v1-whois-data?domain=$DOMAIN&parseWhoisToJson=true" \
  -H "Authorization: Bearer $KEY"

curl -s "$API/v1-ssl-checker?domain=$DOMAIN" \
  -H "Authorization: Bearer $KEY"

curl -s "$API/v1-get-ip-details?ip=93.184.216.34" \
  -H "Authorization: Bearer $KEY"

TypeScript: build an exception report

type Severity = 'ok' | 'notice' | 'high';

interface ClientAsset {
  clientId: string;
  domain: string;
  expectedAsn?: number;
}

interface Finding {
  domain: string;
  check: string;
  severity: Severity;
  message: string;
}

const API = 'https://ops.tools/api';
const headers = { Authorization: `Bearer ${process.env.OPS_TOOLS_API_KEY}` };

async function getJson<T>(path: string): Promise<T> {
  const res = await fetch(`${API}${path}`, { headers });
  if (!res.ok) throw new Error(`Audit request failed: ${res.status}`);
  return res.json() as Promise<T>;
}

async function auditClientAsset(asset: ClientAsset): Promise<Finding[]> {
  const findings: Finding[] = [];

  const dns = await getJson<{ records?: string[] }>(
    `/v1-dns-lookup?address=${asset.domain}&type=A`,
  );
  const firstIp = dns.records?.[0];
  if (!firstIp) {
    findings.push({ domain: asset.domain, check: 'DNS', severity: 'high', message: 'No A record returned.' });
    return findings;
  }

  const whois = await getJson<{ whoisJson?: { expirationDate?: string; registrar?: string } }>(
    `/v1-whois-data?domain=${asset.domain}&parseWhoisToJson=true`,
  );
  const expiration = whois.whoisJson?.expirationDate;
  if (expiration) {
    const days = Math.ceil((Date.parse(expiration) - Date.now()) / 86_400_000);
    if (days < 45) {
      findings.push({
        domain: asset.domain,
        check: 'WHOIS',
        severity: days < 15 ? 'high' : 'notice',
        message: `Domain expires in ${days} days.`,
      });
    }
  }

  const ip = await getJson<{ asn?: number; organization?: string }>(`/v1-get-ip-details?ip=${firstIp}`);
  if (asset.expectedAsn && ip.asn !== asset.expectedAsn) {
    findings.push({
      domain: asset.domain,
      check: 'IP',
      severity: 'notice',
      message: `Resolved IP is announced by ASN ${ip.asn ?? 'unknown'} instead of expected ASN ${asset.expectedAsn}.`,
    });
  }

  const ssl = await getJson<{ certificate?: { isValid?: boolean; daysRemaining?: number; issuer?: string } }>(
    `/v1-ssl-checker?domain=${asset.domain}`,
  );
  if (!ssl.certificate?.isValid || (ssl.certificate.daysRemaining ?? 0) < 30) {
    findings.push({
      domain: asset.domain,
      check: 'SSL',
      severity: ssl.certificate?.isValid ? 'notice' : 'high',
      message: `Certificate needs review. Days remaining: ${ssl.certificate?.daysRemaining ?? 'unknown'}.`,
    });
  }

  return findings.length ? findings : [{ domain: asset.domain, check: 'all', severity: 'ok', message: 'No exceptions.' }];
}

Buyer Framework: One Platform or Point Tools?

Competitor pages show two strong patterns in this market. HackerTarget packages recon and scanner access for security practitioners. WhoisXML API splits a wide catalog into separate WHOIS, DNS, reverse, brand, and bulk APIs. IPinfo goes deep on IP data, with pricing and docs built around geolocation, ASN, privacy, and related datasets. ViewDNS highlights domain and linkage discovery for cybersecurity workflows. None of that is bad; it just means the MSP should decide whether depth or delivery speed matters more for the client package.

Packaging the Client Report

Keep the report short enough for the client sponsor and detailed enough for the technical owner. Use a one-page executive summary, then an exceptions table. Each finding should include the asset, check type, current value, expected value, risk, recommended action, and the date the API evidence was collected.

For security and compliance teams, add an evidence appendix. DNS record validation supports configuration control. WHOIS expiration tracking supports domain portfolio governance. IP and ASN context helps with incident investigation and vendor validation. SSL certificate checks support certificate lifecycle management. None of these claims require invented benchmarks; they are practical controls that clients can understand.

Turn the Audit into a Productized Offer

The strongest commercial angle for an MSP is not "we can run some lookups." It is a packaged service with a clear scope, a repeatable delivery model, and a renewal path. Start with a fixed onboarding audit for new clients. Then offer quarterly or monthly checks for clients that have many domains, multiple business units, recent acquisitions, strict vendor-management requirements, or frequent DNS and certificate changes.

Price the service around outcomes, not raw API calls. A small client may only need a yearly domain and certificate hygiene review. A software company with multiple product domains may need monthly evidence packs, post-change checks, and expiration tracking. A security-conscious client may want brand-adjacent domain discovery, suspicious registrar changes, or IP ownership review after incidents. The API cost matters, but the larger margin lever is analyst time. Automation turns the analyst's job from gathering data to explaining exceptions.

The ops.tools pricing page verifies both pay-as-you-go credits and monthly plans, and it lists webhook notifications and bulk validation on the Growth plan. Because the site uses conflicting entry-price messaging in different places, avoid promising a specific "starting at" number in your own client proposal unless you quote the current pricing page at the time of sale. Use pricing tiers internally to estimate delivery margin, then quote clients for the managed outcome: onboarding audit, recurring monitoring, exception review, and remediation support.

Scope by Client Type

Different clients need different findings. A SaaS client usually cares about uptime, release safety, and certificate lifecycle checks. An ecommerce client cares about checkout domains, email authentication records, CDN targets, and payment-provider subdomains. A law firm or healthcare provider may care less about deployment speed and more about proving that public domains, certificates, and registrars are under control. The API workflow can stay the same while the report language changes.

Security and Incident Response Use Cases

Client audits often uncover security work that was not obvious during onboarding. A domain may resolve to a hosting provider the client no longer uses. A TXT record may reveal an old service that should be removed. A certificate may be valid but issued for a hostname the client thought was retired. WHOIS data may show a registrar or expiration date that does not match internal ownership records. IP context can help analysts decide whether a suspicious endpoint belongs to the client, a SaaS vendor, a CDN, or an unknown host.

Be careful with the language in the report. DNS, WHOIS, IP, and SSL evidence can support an investigation, but it does not prove intent by itself. Write findings as operational facts: "This host resolved to an unexpected ASN during the audit" or "This domain expires inside the policy threshold." That tone is more useful to security teams than inflated threat claims, and it keeps the MSP out of the habit of overselling what a single data point can prove.

FAQ

What should an MSP include in a client infrastructure audit?

Include DNS records, WHOIS registration and expiration data, IP geolocation and ASN context, SSL certificate validity, and a clear list of exceptions against the client's approved baseline.

Can an infrastructure audit be automated with APIs?

Yes. The practical pattern is scheduled API checks, normalized storage, policy comparison, and exception-based reporting. Use webhooks or your own automation layer for alerts when the client buys ongoing monitoring.

Should MSPs use one domain data provider or several point tools?

Use one provider when it covers the required evidence and makes reporting simpler. Add point tools only when a client needs specialized depth, such as a dedicated passive DNS dataset, that is outside the agreed baseline.

For related implementation patterns, read the domain portfolio automation guide and the domain data API evaluation guide.