OpenAI use of `type:` instead of `event:` in Server-Sent Event (SSE) framing as per the official WHATWG HTML Living Standard

[Scalable-Software-Solution-Architect]

Summary

While inspecting streamed responses from the OpenAI Responses API (using stream=true), I noticed that the Server-Sent Event (SSE) frames include a non-standard field name:

type: response.output_text.delta
data: {
  "type": "response.output_text.delta",
  ...
}

According to the WHATWG HTML Living Standard, the valid field names in a text/event-stream response are:

event:, data:, id:, and retry:
Any other field names must be ignored by compliant clients.

— HTML Standard §9.2 Server-sent events

Therefore, the type: field in the SSE framing is technically non-standard.

---

Expected (per SSE spec)

A compliant SSE stream that names an event type should use:

event: response.output_text.delta
data: { "type": "response.output_text.delta", ... }

This would allow spec-compliant clients (for example, the browser’s EventSource API) to listen for the event via:

source.addEventListener("response.output_text.delta", e => console.log(e.data));

---

Observed (OpenAI Responses API)

Instead of using the standard event: field, the stream uses:

type: response.output_text.delta
data: { "type": "response.output_text.delta", ... }

This framing works fine for custom clients or SDKs that parse the stream manually (e.g., using resp_stream_sse() in R or similar in Python/JS).
However, it’s non-compliant with the official SSE specification, meaning a spec-compliant EventSource client will ignore the type: field and treat all messages as default message events.

---

Questions / Clarification requested

1. Is this divergence from the SSE standard intentional?
2. Is there any internal or design reason OpenAI chose type: over event: in the framing?
3. Would OpenAI consider aligning with the WHATWG standard by:

• adopting event: for framing, or
• documenting that the current type: field is non-standard but intentionally supported only by OpenAI SDKs?

---

References

• WHATWG HTML Living Standard – Server-sent events:
  https://html.spec.whatwg.org/multipage/server-sent-events.html#server-sent-events

• MDN: Using Server-Sent Events:
  https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events

• OpenAI Responses API (example stream):
  Documentation link: https://platform.openai.com/docs/api-reference/responses

---

Why this matters

Adhering to the standard would make the Responses API compatible with native SSE clients (like browser EventSource and generic SSE libraries) without custom handling, improving transparency and interoperability for the community.