The GoDaddy reseller Catch-22: the account with the domains has no API, the API account has no domains

To automate DNS for 1,166 customer domains, I needed one thing: a GoDaddy API key. I spent the evening getting one, and the punchline is that the reseller account holding all 1,166 domains has no API, while the reseller account that is API-enabled holds exactly two customers. The API exists. The domains exist. They just don’t live in the same place, and nothing in the dashboard tells you that until you’ve logged into four different accounts to find out.

This is the kind of thing you can’t reason your way around. You have to go account by account, and the only honest way to map it is to actually sign in to each one and look. So that’s what I did.

The setup: why I needed the key at all

I was migrating a legacy Windows/IIS sports SaaS behind Cloudflare for SaaS, custom hostnames and all. The whole migration hinges on flipping each customer’s www CNAME to point at a fallback origin, and doing that by hand across 1,166 domains is not a plan, it’s a punishment. The migration needed to be scriptable. Scriptable meant API. GoDaddy publishes one at developer.godaddy.com, so on paper this was a solved problem.

On paper.

The account maze

GoDaddy’s world is not one account, it’s a federation, and a reseller setup multiplies that. Untangling it one login at a time, here is what was actually there:

• My personal account, a plain retail GoDaddy shopper holding a test domain I use for sandboxing.
• A second personal account under my 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).

Four accounts. Two of them personal noise. The two that matter are the resellers, and that’s where the trap is.

The realm split that eats your evening

Here is the thing nobody tells you, and the single fact that would have saved hours if I’d known it going in.

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

How do you prove they’re separate and not just two faces of the same login? You take the reseller credentials and try them on GoDaddy’s normal retail sign-in. They get rejected with a plain “incorrect username or password,” even though those exact credentials log straight into the secureserver private-label storefront. The retail portal, which is where developer.godaddy.com and its API keys live, does not recognize these accounts at all.

So the reseller that owns every customer domain cannot even see the page where you’d generate an API key. The door to the API is in a building these credentials can’t enter.

The modern-portal twist that nearly minted me a useless key

Then the newer reseller portal threw a curveball. Logging in at reseller.godaddy.com/select-reseller, I saw two resellers I could switch between:

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

There it was. An API Reseller, sitting right there, API access live. The obvious move was to mint a key and start scripting. I almost did.

The gut-check that stopped me: how much activity does this reseller actually have? The answer was roughly ten or eleven dollars a year. One or two domain renewals. That number does not match an account holding over a thousand domains, so before generating anything, I opened the customer list to see what it could actually reach.

It has exactly two customers: the accounts for the platform’s own domain. None of the bulk domains live here. Meanwhile, the customer-facing reseller account holds 1,166 domains (customer sports league sites, and 1,163 more like them).

So the final shape:

• The Pro Reseller (UseYourOwnTeamName private label): 1,166 domains, no API.
• The API Reseller: 2 customers, API enabled.

The account with the domains has no API. The account with the API has no domains. An API key minted against the API Reseller would have authenticated perfectly and then returned nothing I cared about, because it can only see two domains, neither of which I needed to touch. “This reseller has API access” was completely true and completely useless.

What the vendor actually offered

I emailed the GoDaddy rep. The only path back was to migrate all 1,166 domains off the no-API Pro Reseller and onto the API Reseller. That is a mass migration of every customer domain into a different account purely to make a key work, with all the registrar-transfer risk that implies, against domains I don’t own and customers who didn’t ask for it. Declined. The cure was worse than the disease.

The workaround I landed on later sidestepped the whole reseller-API question. 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 yours to call, but it operates in the same secureserver.net realm where the domains actually live, which is the entire point. The public API I went looking for and the data I needed were never in the same realm. The internal one was.

The lesson

Before you build automation against a vendor because “they have an API,” verify that the API and the data live in the same account and the same authentication realm. Those are two separate claims, and a reseller program can make the first one true while quietly breaking the second.

Private-label reseller programs like Wild West Domains are a parallel universe to the retail product. Separate realm (secureserver.net vs godaddy.com), separate sign-in that rejects the other’s credentials, separate API surface. “This reseller is API-enabled” tells you a capability exists somewhere in the tree. It tells you nothing about whether that capability can reach the records you actually need to change.

The concrete tell I’d watch for next time: when a vendor’s accounts span more than one login portal, do the cheapest possible reachability test before you build anything. Open the customer or domain list inside the account you’re about to automate and confirm the records you actually need to change are in it. If the account that has the API holds two customers and a thousand-domain count lives somewhere else, stop. The thirty seconds it takes to read that customer list is cheaper than minting a key, wiring up a client, and discovering at scale that it authenticates against an empty house.

Before minting a key, open the customer list in the API-enabled account. A list of two customers, alongside 1,166 domains in the customer reseller, means the key reaches only the smaller account.

Related

The two reseller accounts never disagreed about whether GoDaddy had an API. They disagreed about which 1,166 domains it could see. Read the customer list before you mint the key, and the rest of the automation writes itself.

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 1,166 customer domains required a working API key, and the search across a reseller account structure surfaced that the reseller account holding all 1,166 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 1,166 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.