Domain verification failing due to "unsupported content type"

Same problem here, and I think I’ve found the root cause. It’s a bug in the ChatGPT web client, not anyone’s DNS or registrar.

First, a useful data point for the “is it Cloudflare?” question. Between this thread we now have three different DNS setups all failing the same way: @akmalmzamri on Cloudflare, bartz on wedos com, and me with a domain registered at Namecheap and DNS hosted at WPX. Different registrars, different DNS providers, exact same error. So it isn’t provider specific.

I captured the network traffic (HAR) while clicking “Check” in Settings > Account > Builder profile. Here is what is actually happening.

The button fires a POST to /backend-api/accounts/{account_id}/domains/{domain_id}/check, and the browser sends that request with an empty body (content-length: 0) and no Content-Type header at all. With no Content-Type set, the server treats it as the default application/octet-stream, and a validator that only accepts JSON rejects it. That is the exact “Unsupported content type: ‘application/octet-stream’… only accepts ‘application/json’” message we are all seeing.

The key implication is that this request is rejected at the HTTP layer before the DNS/TXT record is ever checked. The domain name isn’t even in the failing request, because the body is empty. That is why none of the usual fixes work, and it is why changing domains does nothing. I tested a second, unrelated domain and got the identical error. So “review your domain configuration” or “try another domain” cannot resolve this. The request never reaches the stage where the domain matters.

The fix has to come from OpenAI. Either the web client needs to send Content-Type: application/json on this call (with an empty JSON body), or the endpoint needs to accept a POST with no body.

@PaulBellow, thank you for saying you’d pass this along earlier in the thread. Could you escalate it directly to the engineering team this time? Several of us have gone through official support and only received templated replies, and we are now being redirected back here to the forum, so we are going in circles. I have a full HAR capture and a request_id on file from my support ticket that engineering can use to correlate the failing call in their server logs. Happy to share those with whoever picks this up.

This looks like a regression in the client that affects multiple users, and a single deploy fixing that header would resolve it for everyone in this thread.