Over a thousand customer domains sat inside a GoDaddy private-label reseller panel, and the estimate to flip the www CNAME on each one by hand came back at three to six months of dull clicking. The panel was making an API call on every save.

We run a SaaS application behind that reseller account. The domains are managed in GoDaddy’s DCC (Domain Control Center) panel, and we were moving the whole platform behind Cloudflare, which meant changing the www CNAME on every one. The plan the docs imply is to log in, find each domain, edit the record, save, and repeat.

Every answer we found said there is no API. developer.godaddy.com exists, but it does not work for WWD private-label reseller accounts. The reseller program is a separate world that the public developer API does not reach. So the official story was no programmatic access, do it in the browser, one domain at a time.

That story is wrong the way these stories usually are. “No API” meant “no documented public API.” The DCC web app is a JavaScript front end with no powers a script lacks. When you edit a DNS record there and click save, the browser fires an HTTP request at a backend. Find that request, replay it with your own auth, and you have the API they said did not exist.

Watch the click

The method is one move: do the manual action once with the network tab open, and read what the page actually sent.

Log into the DCC panel as usual and open one domain’s DNS records. Open Chrome devtools, go to the Network tab, and filter to Fetch/XHR so only API calls show. Then edit one www CNAME by hand, click save, and see what appears.

The request that mattered went to:

domdns.api.secureserver.net

It did not go to godaddy.com or developer.godaddy.com. It went to a separate secureserver.net host that the reseller panel talks to behind the scenes. That host is the DNS API. It has no public documentation because nobody outside GoDaddy’s own front end was meant to call it.

Click that request in devtools and read the method, the headers and the body.

What makes it authenticate

The method was a PATCH. The body was a small JSON payload describing the record being changed, the shape you would design yourself if you were building a DNS editor:

{
  "rtype": "cname",
  "guid": "<record-guid-from-GET>",
  "name": "www",
  "data": "<target-hostname>",
  "ttl": 3600
}

The guid is the internal identifier of the existing record. You get it from the GET call the panel fires when it loads a domain’s record list. The rest is self-explanatory.

Auth is the part everyone assumes is the wall, and it turned out to be a cookie. You are already logged into the DCC panel, so the browser sends your session cookie with every backend request, and the endpoint trusts it. There is no separate OAuth dance, no API key to register, no signed-request scheme. You authenticate once in the browser and that session is good for the API.

The one non-obvious piece was an app key header:

x-app-key: DCC-DomainController

This is the front end identifying itself to the backend. Leave it off and the call is rejected even with a valid cookie. You would never guess it from the outside, which is why you watch a real request instead of building one from a spec. The spec does not exist, so the real request is the spec.

The full recipe to drive the endpoint yourself:

  • PATCH to domdns.api.secureserver.net
  • the session cookie copied out of the logged-in browser session
  • x-app-key: DCC-DomainController
  • the same JSON record body the panel sent

Replay it, then loop it

With one request reproduced outside the browser, you have everything. Replay it as-is against a single domain and confirm it lands: the DNS record changes, the panel reflects it, no error. After that, the bulk version is a for loop. We already had the list of domains, the cookie, the header and the body template, so each iteration swapped the domain and the target.

A proof run across 19 domains went clean on the first attempt. The rest of the reseller portfolio is the same for loop. The step that was supposedly impossible to automate became the least interesting part of the migration.

What it costs

This is an undocumented endpoint. GoDaddy can change the host, the header or the body shape whenever they redeploy their panel, and they owe us no warning. There is no rate-limit contract to rely on, so we do not hammer it. A cookie-based session expires, so a long bulk run can outlive its own auth and has to handle re-authentication. None of that is a reason to skip it. It is a private interface we are borrowing with no stable contract behind it, and for a one-shot bulk migration that is fine. For something that has to run forever, you would want to revisit whether the relationship supports a real reseller API tier.

There is also credential hygiene. You are copying a live session cookie into a script, so treat it like the password it effectively is. Do not commit it, do not log it, and throw it away when the job is done.

When a vendor says there is no API, check what its own web panel sends when you click save. Here that gave us a clean proof run across 19 domains and a loop for the rest, in place of three to six months of manual edits.