How to Monitor API Subdomains for Agency Clients: SSL, CNAME, and Expiry Patterns

Most agency monitoring setups watch the primary client domain. When www.clientdomain.com goes down or its SSL certificate expires, an alert fires.

What most setups miss: the API subdomains.

The majority of modern web and mobile applications do not load everything from the primary domain. They fetch data from api.clientdomain.com, authenticate against auth.clientdomain.com, handle webhooks on hooks.clientdomain.com, and deliver assets from cdn.clientdomain.com. Each of these subdomains has its own SSL certificate. Each certificate was provisioned at a different time, on different infrastructure, and expires on a completely independent schedule.

An agency that monitors only www.clientdomain.com is watching approximately half of the SSL surface it is responsible for.

Why API Subdomains Need Separate SSL Monitoring

They Are Provisioned Independently from the Primary Domain

The SSL certificate on api.clientdomain.com is provisioned by whatever platform or tool hosts the API — a Render web service, a Heroku app, a Railway project, a Fly.io application, or a VPS. That certificate was provisioned when the API was deployed and has a validity period (typically 90 days for Let's Encrypt, up to 1–2 years for commercial certificates) that starts from its provisioning date.

The SSL certificate on www.clientdomain.com was provisioned by Netlify, Cloudflare Pages, or wherever the primary site is hosted. These are entirely separate certificates from different certificate authorities with different expiry dates.

Monitoring only one does not inform you about the other.

Their Expiry Symptoms Are Harder to Identify

When www.clientdomain.com SSL expires, every visitor sees a browser SSL error on every page load. The failure is immediate, universal, and generates support tickets within minutes.

When api.clientdomain.com SSL expires, users experience application failures that do not obviously point to SSL: data stops loading, forms fail to submit, search returns no results, the user dashboard shows loading spinners that never resolve. In mobile apps, users see a "check your connection" message. The failure requires investigation to trace to an API SSL expiry — it is not self-diagnosing the way a browser SSL error page is.

API subdomain SSL expiry can remain undetected for days on low-traffic client applications, or manifest as intermittent failures that users attribute to slow servers rather than certificate expiry.

CNAME Integrity Matters More for API Subdomains

API subdomains typically use CNAME delegation to a platform hostname (api.clientdomain.com → some-app.onrender.com, or → some-app.fly.dev). That CNAME is what enables the platform's Let's Encrypt renewal mechanism — the certificate renews successfully only while the CNAME correctly points at the platform.

When a client migrates DNS providers, switches hosting platforms, or consolidates subdomains during a relaunch, the API subdomain CNAME may be updated, removed, or changed. The existing certificate continues to serve until its 90-day validity expires — but the renewal will fail. The failure is invisible until 90 days later when the certificate expires and the API stops responding.

CNAME integrity monitoring on API subdomains detects the mismatch immediately when the CNAME changes — not 90 days later when the certificate expires.

Finding All the API Subdomains to Monitor

Before adding API subdomains to monitoring, agencies need an inventory of what subdomains actually exist for each client. Common approaches:

Check DNS Zone Records

If the agency has access to the client's DNS zone, it is the fastest way to enumerate subdomains. Filter for CNAME records — these are typically the subdomains that point at external platforms and require monitoring. A records pointing at server IPs are worth noting but less likely to be overlooked.

Check the Client's Hosting Platform Dashboards

Most hosting platforms list the custom domains and subdomains configured for each application. Checking the Render dashboard, Heroku app settings, Railway project settings, or Fly.io application configuration reveals which subdomains are actively routing to each platform. These are the highest-priority subdomains to add to SSL monitoring.

Review the Application's Source Code or API Documentation

API endpoint configuration is often stored in environment variables or application configuration files. For agencies that maintain client codebases, the base URLs referenced in the frontend application point directly to which API subdomains the application actually calls. Mobile app configuration files often include all API endpoints in a constants or configuration file.

Check Third-Party Integration Configurations

Third-party services that call webhooks (payment processors, CRMs, form services) are configured with the client's webhook endpoint URL. These webhook endpoints are often on subdomains (hooks.clientdomain.com, notify.clientdomain.com) that are not part of the primary website and may not appear in standard DNS enumeration if they were added recently.

Common API Subdomain Patterns by Platform

Render

Render web services use custom domains that CNAME to `[service-name].onrender.com`. API subdomains on Render follow the pattern api.clientdomain.com → [service-name].onrender.com. Render manages Let's Encrypt certificates automatically — renewal requires the CNAME to remain pointing at the Render hostname.

Failure pattern: client moves DNS to a new provider and omits the api.clientdomain.com CNAME. Render renewal fails at the next 90-day cycle. API SSL expires 90 days later.

Railway

Railway applications use custom domains that CNAME to Railway's infrastructure. API subdomains on Railway follow a similar pattern. Railway manages SSL automatically through Let's Encrypt renewal.

Failure pattern: Railway project is deleted or archived but the DNS CNAME for the API subdomain remains in client DNS. The subdomain becomes a dangling CNAME pointing at decommissioned Railway infrastructure.

Heroku

Heroku custom domains use CNAME delegation to `[heroku-app-name].herokudns.com`. API subdomains on Heroku are added in the Heroku app settings. Heroku manages Automated Certificate Management (ACM) for SSL.

Failure pattern: Heroku app is downgraded from a paid dyno to the free tier (or eco dyno) and SSL provisioning changes. Or: the app is migrated to another platform but the old Heroku CNAME stays in client DNS as a dangling record.

Fly.io

Fly.io applications use custom domains that CNAME to Fly.io infrastructure. Fly.io manages Let's Encrypt certificates for custom domains. The certificate renewal depends on the CNAME remaining pointed at Fly.io.

Failure pattern: Fly application is deleted but the DNS CNAME for the API subdomain remains. Dangling CNAME causes intermittent resolution failures.

VPS / Self-Hosted APIs

Self-hosted API servers use either Let's Encrypt (via Certbot) or commercial certificates managed manually. Let's Encrypt certificates require a working renewal cron job and accessible ACME challenge response. Commercial certificates require manual renewal by whoever provisioned the original certificate.

Failure pattern: Certbot renewal cron job fails silently when the server is upgraded or the web server configuration changes. Commercial certificate is renewed but not deployed to the correct server path. No automatic renewal mechanism exists — the certificate simply expires on its original date.

Adding API Subdomains to Merlonix

Adding API subdomains to Merlonix requires no additional DNS access beyond the initial ownership verification:

Verify ownership once on the apex domain (clientdomain.com) via a DNS TXT record. This takes one DNS entry and confirms the apex domain.
Add each subdomain — api.clientdomain.com, auth.clientdomain.com, hooks.clientdomain.com — as separate monitored assets. No additional DNS records are needed for subdomains under a verified apex domain.
Monitoring begins immediately — SSL expiry, CNAME target integrity, and DNS resolution are checked on every monitoring interval. Alerts fire 30 days before SSL expiry or immediately when a CNAME target changes.

The full workflow for a client with three API subdomains takes under five minutes, including the initial apex domain verification.

What to Do When You Find API Subdomain SSL Is Already Expiring Soon

Within 30 Days: Verify and Renew

If the certificate expires within 30 days:

Confirm the CNAME is correctly pointing at the hosting platform. If it is correct, the platform should renew automatically within days.
If the CNAME is wrong or missing, the platform cannot renew. Fix the DNS record first, then confirm renewal runs.
For self-hosted APIs: run Certbot renewal manually or verify the renewal cron job is executing.

Expired: Platform-Specific Recovery

Render, Railway, Fly.io: Remove and re-add the custom domain in the platform dashboard. This triggers a new Let's Encrypt provisioning cycle.
Heroku ACM: Run `heroku certs:auto:refresh` or remove and re-enable Automated Certificate Management.
Self-hosted Certbot: Run `sudo certbot renew --force-renewal` and restart the web server.

Dangling CNAME: Remove or Point at Active Infrastructure

If the API subdomain's CNAME points at decommissioned infrastructure — an old Heroku app, a deleted Railway project, a removed Render service — the subdomain is not serving anything useful. Either remove the CNAME record from DNS (if the API subdomain is no longer needed) or update the CNAME to point at the current platform where the API is deployed.

Checklist: API Subdomain SSL Monitoring for a New Client

List all subdomains in the client's DNS zone with CNAME records
Cross-reference with the client's hosting platform dashboards — are all CNAMEs routing to active services?
Check the application source code for API base URL configuration — are there endpoints not visible in DNS?
Check third-party integration configurations for webhook URLs on client subdomains
Add all active API subdomains to SSL monitoring
Verify each CNAME target matches the expected platform hostname
Confirm 30-day expiry alerts are active for each subdomain
Document any legacy CNAMEs pointing at platforms the client previously used