Why the API-Enabled Reseller Account Was Useless for DNS Automation

To automate DNS for more than a thousand customer domains, we needed one GoDaddy API key. We spent the evening getting one. The reseller account holding every one of those domains has no API, and the API-enabled reseller account holds exactly two customers. The API exists and the domains exist, but they live in different places. Nothing in the dashboard says so until you’ve logged into four different accounts.

You can’t reason your way around this. The only way to map it is to sign in to each account and look, so that’s what we did.

Why we needed the key

We were migrating a legacy Windows/IIS SaaS platform behind Cloudflare for SaaS, custom hostnames and all. The migration hinges on flipping each customer’s www CNAME to point at a fallback origin. Doing that by hand across more than a thousand domains is not a plan, so it had to be scriptable, and scriptable meant API. GoDaddy publishes one at developer.godaddy.com, so on paper this was solved.

On paper.

Four logins

A reseller setup multiplies accounts. Going one login at a time, this is what was there:

• A personal account, a plain retail shopper holding a test domain we use for sandboxing.
• A second personal account under a collaborator, holding a handful of unrelated crypto and finance domains.
• The core infrastructure reseller, holding the brand and infra domains, 104 of them, all under the “UseYourOwnTeamName” private label.
• The customer reseller, the real target, where the actual customer domains live (also under UseYourOwnTeamName).

Two of those are personal noise. The two resellers are where it gets interesting.

Two realms

The two reseller accounts are not GoDaddy retail accounts. They are Wild West Domains private-label reseller accounts, and they live only in the secureserver.net realm. That is a separate authentication universe from godaddy.com retail.

We took the reseller credentials and tried them on GoDaddy’s normal retail sign-in. They were rejected with a plain “incorrect username or password,” even though those exact credentials log straight into the secureserver private-label storefront. The retail portal is where developer.godaddy.com and its API keys live, and it does not recognize these accounts at all.

So the reseller that owns every customer domain can’t even reach the page where you generate an API key.

The key we almost minted

Then the newer reseller portal offered a way in. Logging in at reseller.godaddy.com/select-reseller, we could switch between two resellers:

• The Pro Reseller (UseYourOwnTeamName private label): no API.
• The API Reseller: program id matching our brand, already API-enabled.

An API Reseller, with access live. The obvious move was to mint a key and start scripting, and we almost did.

What stopped us was the activity level. This reseller was doing roughly ten or eleven dollars a year, which is one or two domain renewals. That doesn’t match an account holding over a thousand domains. Before generating anything, we opened the customer list to see what a key could reach.

It has exactly two customers, the accounts for the platform’s own domain. None of the bulk domains live here. The customer-facing reseller account holds over a thousand domains, customer sites and many more like them.

So the final shape was:

• The Pro Reseller (UseYourOwnTeamName private label): over a thousand domains, no API.
• The API Reseller: 2 customers, API enabled.

A key minted against the API Reseller would have authenticated perfectly and then returned nothing we cared about. It sees two domains, and neither needed touching. “This reseller has API access” was completely true and completely useless to us.

What the vendor offered

We emailed the GoDaddy rep. The only path back was to migrate all of those domains off the no-API Pro Reseller and onto the API Reseller. That would mean a mass move of every customer domain into a different account purely to make a key work, with all the registrar-transfer risk that implies, on domains we don’t own, for customers who didn’t ask for it. We declined.

The workaround we landed on later skipped the reseller-API question entirely. GoDaddy’s DCC (Domain Control Center) has an internal DNS API: a cookie-authenticated PATCH to domdns.api.secureserver.net, issued from inside a logged-in DCC session. It’s not the public REST API and it’s not officially ours to call. But it operates in the same secureserver.net realm where the domains actually live. The public API we went looking for and the data we needed were never in the same realm, and the internal one was.

Check the list before the key

“They have an API” and “the API can see my records” are two separate claims. A reseller program can make the first true while breaking the second. Private-label programs like Wild West Domains run parallel to the retail product, with a separate realm (secureserver.net vs godaddy.com), a separate sign-in that rejects the other’s credentials, and a separate API surface. “This reseller is API-enabled” tells you a capability exists somewhere in the tree. It says nothing about whether that capability reaches the records you need to change.

When a vendor’s accounts span more than one login portal, run the cheapest reachability test before building anything. Open the customer or domain list inside the account you’re about to automate and confirm the records are in it. If the account with the API holds two customers and the thousand-domain count lives somewhere else, stop. Reading that list takes about thirty seconds. Minting a key, wiring up a client and finding out at scale that it authenticates against an empty house costs a lot more.

dxdev LESSON · paste into your AI coding agent
LESSON: 'This account has API access' and 'this account has your data' are two separate claims a vendor can make true independently
SOURCE: dxdev.com/blog/godaddy-reseller-catch-22-api-and-domains-in-different-accounts
WHAT HAPPENED: Automating DNS changes across more than a thousand customer domains required a working API key, and the search across a reseller account structure surfaced that the reseller account holding every one of those domains had no API access at all, while a separate reseller account with live API access held exactly two unrelated customers, neither of which was among the domains that needed changing. The two reseller accounts turned out to live in a completely separate authentication realm from standard retail accounts, one that rejects retail login credentials outright and where the retail portal hosting API-key generation doesn't recognize the reseller accounts existing at all, so the account holding the needed data structurally couldn't reach the page that would grant API access to it. Migrating all of those domains into the API-enabled account was offered by the vendor as the only official fix and was declined as disproportionate risk for a key to work; the actual workaround used an internal, cookie-authenticated endpoint operating in the same realm where the domains actually lived, sidestepping the public API question entirely. Before minting any key, the recovered practice was to open the customer or domain list inside the specific account about to be automated and confirm the records that actually need changing are present in it, since a two-customer account and a thousand-domain account can both legitimately claim "API-enabled" while only one of them can reach the data.
THE RULE: Before building automation against a vendor because "they have an API," verify the API access and the actual data you need to touch live in the same account and the same authentication realm; those are two separate, independently-true claims, and a reseller or federated account structure can satisfy one while quietly failing the other. Open the target account's own data list and confirm the specific records are present before minting any credential.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any automation built against a vendor's API without first confirming, by opening the specific account's own data or customer list, that the records needing changes actually live in the API-enabled account.
  2. Any multi-account or reseller vendor relationship where credentials from one account are assumed to work across a related account, without confirming both accounts share the same authentication realm.
  3. Any API integration plan that doesn't check for a lower-level or internal endpoint operating in the correct realm as a fallback, when the public, documented API cannot reach the account holding the actual data.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.