Skip to content
FeaturesError referenceBlogDocsChangelog

Route Error (400 ): { "error": { "message": "No eligible ChatGPT workspaces found.", "type": "invalid_request_error", "param": null, "code": "chatgpt_account_missing" } }

Nothing is wrong with the request you sent. The type says invalid_request_error and that is what sends people off in the wrong direction — checking parameters, reinstalling the tool, regenerating credentials. param is null, which is the server saying it cannot point at a field, because no field is at fault. The condition being reported is about the account the request was made on behalf of: the identity you signed in with resolves to a set of workspaces, and none of them is entitled to this product.

That also rules out the neighbouring classes. A rejected credential is a 401, a region restriction is a 403, a budget or pacing problem is a 429, and a platform fault is a 5xx. This is a 400 because the server understood you perfectly and the answer is still no.

The field that carries the meaning

Two fields in this body do real work, and they are not the two you would read first.

code is chatgpt_account_missing. That is the discriminator — the string you would branch on in a handler, and the string worth searching. The type is a broad category shared with genuinely malformed requests, so it separates nothing. The docs make the same point about billing failures, where the narrow code is what identifies the condition while the broader type stays generic. The habit transfers: read code, treat type as a bucket.

param is null. On a real malformed-request 400 this names the offending field. Its absence is the structural proof that your payload is not the subject. If you take one diagnostic step from this page, it is to stop editing the request.

Sign-in with ChatGPT and an API key are different doors

This error only exists on one of the two ways to authenticate, and knowing which one you are on explains almost everything about it.

Signing in with a ChatGPT account attaches your usage to that account and to a workspace under it. The eligibility check runs against that workspace: does it exist, does it have an entitlement for this product, is there a seat assigned to you, is its subscription in good standing. An API key is a different route entirely, with its own separately-billed access and its own rules. The key point is that a key does not override a workspace decision — it is a different product relationship, not a way around this one. If you already have API access through your organization and your tooling supports that path, using it is a legitimate choice; it is not a fix for the workspace state, which stays exactly as it was.

What it is not is something you can adjust locally. There is no client setting that makes a workspace eligible, and anyone telling you to edit a config value to get past an entitlement check is describing a way to waste your evening.

The decision was made at sign-in, and you are still holding it

This is the part that turns a five-minute problem into a two-day one.

When you complete a browser sign-in, the account that was already signed into that browser is usually the one that gets used — and on a machine where you have a personal account and a work account, that is frequently not the one you intended. The tool then stores the resulting credential and keeps using it.

The consequence: changing accounts or workspaces in your browser afterwards changes nothing, because your tool is not looking at your browser. It is holding a credential that already encodes the failed decision. People switch accounts, re-run the command, see the identical error, and conclude the switch did not take effect. It did — it just was not consulted.

Whenever you change anything about the account side, sign out of the tool and sign in again, deliberately choosing the account in the browser rather than accepting whichever session is open. If you have a second browser profile, doing the sign-in there removes the ambiguity entirely.

Is retrying useful?

No. The eligibility check is a lookup against account state that your retry does not touch.

There is no server asking you to wait, no retry-after to honor, and no documented base delay to copy. The same identity produces the same answer, and an automated loop around it just makes the failure harder to read in your logs.

There is one honest caveat, and it is about when the state changes rather than whether retrying works. If an administrator grants you a seat or enables the product while you are sitting there, the underlying condition will change without you doing anything — but the credential you are holding was issued under the old state. Re-run the sign-in, not the command. Treating this as a retry is exactly how people conclude that the admin’s change “didn’t work” ten minutes after it did.

Telling the causes apart

You are signed in with the wrong account. The observable: sign out, sign in again, and read back which account the tool reports. If it names a personal address when you expected a work one — or the reverse — you have found it, and nothing else on this page applies.

The right account, but a workspace with no entitlement. The observable: another person on the same workspace gets the same error. That is a workspace property, not a per-user one, and it needs someone with administrative rights on that workspace.

The right workspace, but no seat for you. The observable: a colleague on the same workspace works fine and you do not. Seat assignment is per-member, and a member can be in a workspace without holding a seat for a given product.

It used to work and stopped. The observable is the change, not the error. Seats get reclaimed during a reshuffle, subscriptions lapse on a failed payment, and a workspace can be migrated or renamed. Ask what changed on the billing or admin side in the window where it broke.

You have no workspace at all beyond a personal account. Then there is nothing to be eligible, and the answer is about which plans and workspace types carry this entitlement — a question whose answer changes and which you should read from the product’s own documentation and account settings rather than from any page that fixes it in print.

Who to ask, and what to ask for

Write the request so it can be actioned without a conversation. The person who can change this is an owner or administrator of the ChatGPT workspace — in a company, usually whoever manages the subscription, not your engineering manager and not OpenAI support in the first instance.

Give them four things: the account address you are signing in with, the workspace you expect to use, the product you are trying to enable, and the verbatim error including chatgpt_account_missing. That last string is what lets an administrator distinguish “this person needs a seat” from “our workspace does not have this enabled”, which are different actions in different places.

If you are the administrator, the questions in order are: does the workspace have the product enabled, is there an unassigned seat, is the subscription current, and is this user a member of the workspace you think they are in.

Do not paste credentials, tokens, or callback URLs into the ticket. The error body alone is enough, and it contains nothing sensitive.

How to confirm it’s fixed

Two observations, in order, and the first one is the one people skip.

Sign out of the tool and sign in again, and confirm it reports the account and workspace you expect. Not “no error” — the right names. A successful sign-in under the wrong identity reproduces this failure immediately and looks like the fix did not work.

Then run the command that was failing, from a freshly started process. If an administrator made a change, do the sign-out and sign-in after their change rather than before it; a credential issued under the old state will keep reporting the old state for as long as you hold it.