Documented v1 Conversations endpoints return 404 / unknown_parameter on every resource and region

Question

Documented v1 Conversations endpoints return 404 / unknown_parameter on every resource and region

Philipp Wanning 0

Hi all,

The v1 reference at

https://learn.microsoft.com/en-us/azure/foundry/openai/latest

lists Conversations as supported, both as a top-level resource (/openai/v1/conversations) and as a conversation parameter on the Create Response request body.

On every resource I have access to, neither works - while plain Responses calls at the same base URL with the same api-key succeed.

What works

Responses without conversation:

POST https://<resource>.openai.azure.com/openai/v1/responses?api-version=preview

Content-Type: application/json

api-key: <key>

{

  "model": "gpt-5.4",

  "input": "Hello"

}

-> 200 OK

What doesn't (1): Creating a conversation

POST https://<resource>.openai.azure.com/openai/v1/conversations

Content-Type: application/json

api-key: <key>

{}

-> 404 Resource not found

Same 404 for these variants:

?api-version=preview
?api-version=2025-04-01-preview
without any api-version (v1 GA style)

What doesn't (2): Using `conversation` on the Responses request

The v1 reference lists conversation as a body parameter for Create Response. When I include it:

POST .../openai/v1/responses?api-version=preview

{

  "model": "gpt-5.4",

  "input": "Hello",

  "conversation": "conv_anything"

}

I get:

{

  "error": {

    "message": "Unknown parameter: 'conversation'.",

    "type": "invalid_request_error",

    "param": null,

    "code": "unknown_parameter"

  }

}

This is not a "conversation does not exist" error - the Responses surface rejects the field at request validation time. So the entire Conversations feature is missing, not just the subresource.

What I have ruled out

I tested the same calls against:

both <resource>.cognitiveservices.azure.com and <resource>.openai.azure.com host styles
model deployments in multiple Azure regions
with and without api-version (preview, 2025-04-01-preview, omitted)

All combinations return the exact same two errors above. So this is not a host/resource-kind issue, not a regional rollout issue, and not an api-version issue. Same api-key, same base URL, Responses works, Conversations does not.

Questions

Is the Conversations feature (both /conversations subresource and the conversation parameter on /responses) actually rolled out anywhere on Azure today? If yes, on what kind of resource and in what region?
If it isn't generally available yet, could the v1 reference page be updated to reflect that? At the moment the documentation states the endpoints and the parameter as supported without any preview/availability note, which directly contradicts the actual API behaviour and makes it impossible to plan around.

Thanks!
Philipp

Karnam Venkata Rajeswari 3,675 Zuverlässigkeitspunkte Externe Microsoft-Mitarbeiter Moderator

2026-04-30T18:45:53.52+00:00
Hallo Philipp Wanning,

Willkommen bei Microsoft Q&A. Vielen Dank, dass Sie uns kontaktiert haben.

Die HTTP-404-Antwort (Ressource nicht gefunden) gibt an, dass der angeforderte Endpunkt auf der aktuellen API-Oberfläche nicht verfügbar ist.

Obwohl die IPv1-API-Referenz Conversations-Endpunkte enthält, sind diese Endpunkte derzeit nicht über Standard-Azure OpenAI-Endpunkte (wie *.openai.azure.com) verfügbar. Daher liefern Anfragen an /openai/v1/conversations konstant 404.

Der Fehler unknown_parameter bestätigt, dass die /responses-API das Konversationsfeld derzeit nicht erkennt.

Dies geschieht, weil die Anfragevalidierung nur Parameter zulässt, die Teil des aktiven Schemas sind. Derzeit wird das Konversationsfeld von der Responses-API auf Standard-Endpunkten nicht unterstützt, was bedeutet, dass konversationsbasierte Zustandsverwaltung nicht nativ durchgeführt wird.

Dies stimmt mit den während der Tests beobachteten Validierungsfehlern überein und weist auf erwartetes Verhalten statt auf ein Implementierungsproblem hin.

Derzeit gibt es keine Azure-Regionen oder Standardressourcentypen, auf die die Conversations-API zugänglich ist.

Die aktuelle Dokumentation verweist auf Conversations als Teil der umfassenderen v1-API-Oberfläche. Allerdings werden Azure AI Foundry-Funktionen in verschiedenen Umgebungen und Lebenszyklusphasen veröffentlicht, und nicht alle dokumentierten Funktionen sind gleichzeitig in jedem Endpunkt verfügbar.

Daher können einige Features in Referenzmaterial erscheinen, bevor sie über Standard-öffentliche Endpunkte zugänglich sind, was die beobachtete Diskrepanz zwischen Dokumentation und Laufzeitverhalten erklärt.

Bis native Conversations-Unterstützung verfügbar wird, wird empfohlen, den Konversationszustand auf Anwendungsebene mit der unterstützten /responses-API zu verwalten.

Derzeit lautet das vorgeschlagene Implementierungsmuster:

Speichere den Konversationsverlauf extern (zum Beispiel Datenbank oder Cache)

Fügen Sie jeder Anfrage relevante vorherige Nachrichten hinzu

Senden Sie den angesammelten Kontext mit dem Feld input

Die folgenden Quellen könnten hilfreich sein, bitte schauen Sie sie sich an

Azure OpenAI in Microsoft Foundry Models v1 REST API-Referenz - Microsoft Foundry | Microsoft Learn

Use the Azure OpenAI Responses API - Microsoft Foundry | Microsoft Learn

Azure OpenAI in Microsoft Foundry Models REST API-Referenz - Microsoft Foundry | Microsoft Learn

Danke
Philipp Wanning 0 Zuverlässigkeitspunkte

2026-05-01T07:20:34.24+00:00
Thanks for the clear confirmation that the feature is genuinely unavailable across all standard endpoints and regions.

We'd like to push back on the framing of this as "expected behaviour", because that understates the actual problem.

Our organization chose Azure OpenAI for a production B2B project — over going directly with OpenAI — in significant part based on the v1 surface as documented, which includes Conversations. That was an architectural decision at the company level, made before implementation work began. Discovering that Conversations is not actually reachable on any Azure endpoint or region therefore isn't a developer-side debugging issue; it directly affects a technology choice the organization committed to.

From the perspective of anyone reading the v1 reference:

The /conversations endpoints are listed as supported operations.

The conversation parameter is listed as a body field on Create Response.

There is no preview banner, no availability notice, no regional gating note, no "coming soon" marker, no link to a rollout timeline.

The team spent non-trivial time debugging what we assumed was a configuration issue on our side, because the documentation explicitly stated the feature should work. That's a real cost — and on a public reference, it almost certainly affects other organizations evaluating or building on Azure OpenAI in the same way.

Documentation that lists capabilities the API does not implement, without any indication of that gap, is not a minor inconvenience — it is actively misleading. "Foundry features ship in different lifecycle stages" is fair, but the documentation is exactly where that lifecycle stage needs to be visible. Otherwise a reader has no way to distinguish "supported today" from "spec'd but not deployed anywhere on Azure".

The gap is also not new. The Conversations API has been available on OpenAI's own API since August 2025 — roughly nine months. Its absence on Azure is surprising on its own; the absence of any availability marker in the Azure documentation, after that long, is harder to justify.

Concrete asks:

Timeline. When will the Conversations endpoints and the conversation parameter on Create Response become reachable on standard Azure endpoints, in which regions, and on which resource kinds? Even a rough quarter would help our planning. Given OpenAI shipped this nine months ago, we'd expect Microsoft to at least have an internal target.

Documentation. Add a clear, prominent availability notice to the Conversations section of the v1 reference and to the conversation parameter on Create Response. If the feature is not available on any Azure region or endpoint today, that belongs at the top of the section.

General notice. Add a top-of-page note on the v1 reference clarifying that not every documented capability is currently reachable on standard Azure endpoints.

Channel. If there is a public roadmap, "What's new" entry, or any other place where the Conversations rollout will be announced, please share the link.

We understand you are not personally responsible for the documentation or rollout timing. Could you forward this to the documentation owners and the product team, or point us to the channel where we can raise it directly?
Karnam Venkata Rajeswari 3,675 Zuverlässigkeitspunkte Externe Microsoft-Mitarbeiter Moderator

2026-05-01T19:01:37.8333333+00:00
Hello Philipp Wanning,

Thank you for the detailed and thoughtful feedback—this is genuinely helpful in understanding both the technical behavior and the broader impact on architectural decisions.

From the current behavior observed across standard Azure OpenAI endpoints, the /openai/v1/conversations endpoint and the conversation parameter are not exposed through this API surface at this time. The responses observed during testing (such as HTTP 404 and schema validation errors like unknown_parameter) are consistent with this current availability boundary rather than with a configuration or usage issue.

To provide additional context, there is an important distinction in how these capabilities are represented across the platform:

The concept of conversations does exist within the broader Azure AI Foundry ecosystem, particularly in agent-based runtimes where conversations, agents, and responses work together to maintain interaction state.

However, in standard Azure OpenAI endpoints, this capability is not currently exposed as a standalone /conversations endpoint or as a conversation request parameter.

Instead, multi-turn and context-aware interactions are supported through the Responses API, where continuity is achieved by passing prior messages or chaining responses explicitly.

This difference in API surfaces can lead to the experience described, where functionality appears in the overall API reference but is not directly reachable from a specific endpoint.

For current implementations requiring multi-turn conversational behavior, the supported approach remains:

Persist interaction history externally (for example, in a database or cache)

Include relevant prior turns in each request sent to the Responses API

Use response chaining or structured inputs to maintain context across interactions

The feedback shared here has been noted carefully and will be communicated through the appropriate channels

Thank you
Philipp Wanning 0 Zuverlässigkeitspunkte

2026-05-05T10:43:00.5333333+00:00

Thanks for the reply, but this largely restates the previous answer and doesn't address any of the concrete questions: no timeline, no commitment on the documentation, no link to a roadmap or announcement channel. "Noted carefully and communicated through the appropriate channels" is, with respect, not an answer.

What continues to concern us is the implicit position that a public v1 API reference listing endpoints and parameters that are not reachable on any Azure endpoint is acceptable, as long as the runtime returns 404 and unknown_parameter. That stance treats misleading documentation as a feature of the lifecycle rather than as something that needs fixing — and that's hard to reconcile with what "reference documentation" is supposed to mean for organizations making architectural decisions on its basis.

We'll watch the v1 reference for an availability notice. Until that lands, or a timeline is shared, the actual issue is unresolved.

1 Antwort

Ihre Antwort

Philipp Wanning 0 Zuverlässigkeitspunkte

2026-05-05T10:43:00.5333333+00:00

Thanks for the reply, but this largely restates the previous answer and doesn't address any of the concrete questions: no timeline, no commitment on the documentation, no link to a roadmap or announcement channel. "Noted carefully and communicated through the appropriate channels" is, with respect, not an answer.

What continues to concern us is the implicit position that a public v1 API reference listing endpoints and parameters that are not reachable on any Azure endpoint is acceptable, as long as the runtime returns 404 and unknown_parameter. That stance treats misleading documentation as a feature of the lifecycle rather than as something that needs fixing — and that's hard to reconcile with what "reference documentation" is supposed to mean for organizations making architectural decisions on its basis.

We'll watch the v1 reference for an availability notice. Until that lands, or a timeline is shared, the actual issue is unresolved.

Answer 1

Manas Mohanty 17,185 Externe Microsoft-Mitarbeiter Moderator

Hallo Philipp Wanning

Ich kann das Szenario auch auf meiner Seite reproduzieren und prüfe dies derzeit gemeinsam mit der Produktgruppe für die nächsten Schritte.

Vielen Dank für Ihre Beiträge im Forum.

0 Kommentare

Freigeben über

Documented v1 Conversations endpoints return 404 / unknown_parameter on every resource and region

What works

What doesn't (1): Creating a conversation

What doesn't (2): Using conversation on the Responses request

What I have ruled out

Questions

1 Antwort

Ihre Antwort

What doesn't (2): Using `conversation` on the Responses request