apiKey became mandatory in v6.36.0

[Menduist]

Confirm this is a Node library issue and not an underlying OpenAI API issue

• This is an issue with the Node library

Describe the bug

Since this commit:
359afb9

An empty apiKey ("") doesn't work anymore:

     42|     const client = new OpenAI({
       |                    ^
Error: Error: Missing credentials. Please pass an `apiKey`, `workloadIdentity`, `adminAPIKey`, or set the `OPENAI_API_KEY` or `OPENAI_ADMIN_KEY` environment variable.
     43|         apiKey: "",

To Reproduce

Create an OpenAI client with an empty apiKey

Code snippets

OS

any

Node version

any

Library version

=6.36

[23starchild]

Yes. This is an issue with the Node library, not the underlying OpenAI API.
The behavior described concerns client-side credential validation in the Node SDK:
The regression was introduced after a specific SDK commit (359afb9).
The error is thrown during new OpenAI({...}) client initialization, before any request is sent to the API.
The API itself never receives the request, so it cannot be responsible for the behavior.
The issue is specific to Node library version 6.36.
The bug report is clear: in previous versions an empty string (apiKey: "") was accepted, but starting with the referenced commit the SDK now rejects it with a "Missing credentials" error.

[23starchild]

This code is generally well-structured. Looking specifically at the bug you mentioned—where an empty API key ("") stopped working after commit 359afb9—the likely culprit is how the Authorization header is now always added.
The problematic section
headers: {
...props.options?.headers,
...(isAzure(client) && !props.__resolvedApiKey
? {}
: { Authorization: Bearer ${client.apiKey} }),
},
If:
client.apiKey === ""
then the header becomes:
Authorization: Bearer
(or effectively Authorization: Bearer )
instead of omitting the header entirely.
Previously, an empty string may have been treated as "no API key" and allowed the connection to rely on other authentication mechanisms or environment configuration.
Another issue
Earlier in the constructor:
client ??= new OpenAI();
The OpenAI constructor now validates credentials. If you call:
new OpenAI({
apiKey: "",
});
the constructor itself throws:
Missing credentials.
before this WebSocket code even runs. That matches the error you described.
A safer implementation
Instead of always emitting an Authorization header, guard against empty strings:
const headers = {
...props.options?.headers,
};

if (
!isAzure(client) ||
props.__resolvedApiKey
) {
if (client.apiKey) {
headers.Authorization = Bearer ${client.apiKey};
}
}
or more compactly:
...(client.apiKey
? { Authorization: Bearer ${client.apiKey} }
: {})
The real regression
From your earlier report, the regression is probably not in OpenAIRealtimeWS itself.
The failure occurs earlier:
const client = new OpenAI({
apiKey: "",
});
Older SDK versions accepted an empty string, while newer versions treat "" the same as undefined or null and immediately throw:
Missing credentials.
So the regression is likely in the OpenAI constructor's credential validation, not in this WebSocket class.
The WebSocket code does have a secondary issue (sending Authorization: Bearer when the key is empty), but that only matters if the constructor allows the empty string in the first place.

[morgan-coded]

What setup needs the literal empty string — a keyless local server or proxy behind a custom baseURL, or something else? Asking because the fix shape depends on it. Since 359afb9 the constructor just requires a truthy credential (the client.ts check is !apiKey), so any placeholder like apiKey: "none" still passes and sends a throwaway bearer header, which keyless endpoints typically ignore. If your endpoint actively rejects requests carrying an Authorization header, that's a stronger case worth stating here explicitly.

[Menduist]

Can confirm that in my current setup, an invalid API key is ignored by my backend (vllm), though it would be more resilient for openai-node to continue supporting having no api key