Versioning

The API is Open Responses compatible, and works with OpenAI’s official SDKs and other OpenAI-style clients. Every wire response and stream event is validated against a pinned schema before a change can ship, so the shapes on this surface are the ones your SDK already expects. There is one prefix on the API, /v1, and the rules below say what a client can build against without watching for announcements.

Where this surface and OpenAI’s differ, the difference is listed on Compatibility. A field the API does not implement is accepted and ignored, or refused with a 400 in OpenAI’s own error shape that names it.

What you can rely on

• Unknown request fields never fail a request. No wire type rejects unknown fields. A field is rejected only when it asks for behavior the API cannot honor, and then with a 400 that names it, which is what lets a newer SDK keep working against this surface.
• An unknown value of a known field is a 400 that names it. An item type, a service_tier or a tool type this API does not define is refused, with the field in param and its path, such as input[1], in the message. The message quotes the value when it is a short name rather than free text.
• Extensions are namespaced. Everything beyond the specification carries the helpingio: prefix and never changes an enum, union, or required field of it. See Extensions.

Breaking and compatible changes

Breaking, would require a new prefix	Compatible, may land under /v1
Removing or renaming any field, status value, event type, or error code a client validates against the schema	A new helpingio: field
Changing the meaning of an existing one	A new error code under an existing HTTP status
Narrowing what is accepted	A loosened acceptance rule
	A new endpoint

Changelog

There is no customer-facing changelog for the API yet. Additive changes are announced on the page that owns the topic.