[Bug]: Some Error responses result in undefined array keys

[Radiergummi]

Description

I just encountered a situation where we accidentally used a mismatching project ID and API key, then tried to execute calls locally. This caused errors where "output" or "data" could not be found in the response, which makes sense, given the actual body:

{
  "error": {
    "message": "OpenAI-Project header should match project for API key",
    "type": "invalid_request_error",
    "code": "mismatched_project",
    "param": null
  },
  "status": 401
}

The client should probably detect these cases and throw an error.

Steps To Reproduce

1. Use a mismatching API key and unrelated project ID in the settings
2. Try to perform any API call

OpenAI PHP Client Version

v0.18.0

PHP Version

8.5.1

Notes

No response

[iBotPeaches]

I added an assertion for this error and all seems alright. Is there a chance this Content-Type is not JSON or something odd? We do have some handling around Content-Type which would be only thing I can think of, since this simple test case is passing as-is.

#736

[Radiergummi]

I dumped the entire HTTP communication for this snippet here:

> $response = OpenAI::responses()->create([
  'model' => 'gpt-5',
  'input' => 'Hello!',
]);

…and found the following:

POST /v1/responses HTTP/1.1
Host: api.openai.com
Authorization: Bearer sk-proj-[redacted]
OpenAI-Organization: org-[redacted]
OpenAI-Project: proj_[redacted]
Content-Type: application/json

{ "model": "gpt-5", "input": "Hello!" }

HTTP/1.1 401 Unauthorized
Date: Sun, 18 Jan 2026 10:51:59 GMT
Content-Type: text/plain
Content-Length: 199
Connection: keep-alive
x-openai-ide-error-code: mismatched_project
x-openai-authorization-error: 401
x-error-json: ewogICJlcnJvciI6IHsKICAgICJtZXNzYWdlIjogIk9wZW5BSS1Qcm9qZWN0IGhlYWRlciBzaG91bGQgbWF0Y2ggcHJvamVjdCBmb3IgQVBJIGtleSIsCiAgICAidHlwZSI6ICJpbnZhbGlkX3JlcXVlc3RfZXJyb3IiLAogICAgImNvZGUiOiAibWlzbWF0Y2hlZF9wcm9qZWN0IiwKICAgICJwYXJhbSI6IG51bGwKICB9LAogICJzdGF0dXMiOiA0MDEKfQ==
x-request-id: req_9ba07291728b4b39a600481202700fd0
x-datadog-trace-id: 2157488385384752225
x-datadog-parent-id: 9820968212915070212
x-datadog-sampling-priority: 0
x-openai-internal-caller: unknown_through_ide
x-envoy-upstream-service-time: 195
x-openai-proxy-wasm: v0.1
cf-cache-status: DYNAMIC
Set-Cookie: __cf_bm=[redacted]; path=/; expires=Sun, 18-Jan-26 11:21:59 GMT; domain=.api.openai.com; HttpOnly; Secure; SameSite=None
Set-Cookie: _cfuvid=[redacted]; path=/; domain=.api.openai.com; HttpOnly; Secure; SameSite=None
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
X-Content-Type-Options: nosniff
Server: cloudflare
CF-RAY: 9bfd8a50b8c130e8-FRA
alt-svc: h3=':443'; ma=86400

{
  "error": {
    "message": "OpenAI-Project header should match project for API key",
    "type": "invalid_request_error",
    "code": "mismatched_project",
    "param": null
  },
  "status": 401
}

Note the text/plain content type, which indeed seems to be an OpenAI API bug to me? However, looking at the other headers, there's an x-error-json header with the error payload encoded as base64. If that is returned consistently, it may be a safer way to get error details?

[iBotPeaches]

thanks! I don't want to trust a custom header due to the other models that pipe through this logic as "OpenAI complaint". The big flaw I think was trusting content-type over anything which bailed out early and caused these issues.

Now in #736 I've reworked this with a slight hack. We will attempt to parse everything as JSON, if it fails and Content-Type is plain we will bail out and not throw an exception.