Azure OpenAI Responses API documentation mismatch for file inputs and Office document support

Alexander Leeb 0 Reputation points
2026-03-28T23:54:40.2566667+00:00

Hello,

The Azure OpenAI Responses API currently appears to lack practical support for Office document formats such as .docx, .pptx, and .xlsx, and I need a clear answer on whether and when this will actually be supported.

I already understand that purpose="user_data" is not currently supported in Azure OpenAI. That is not my main issue here.

My issue is that the Azure OpenAI Responses documentation points users to OpenAI file input documentation that clearly lists .docx, .pptx, and .xlsx as supported file input formats:

From a developer perspective, this strongly implies that these file types should be usable with Azure OpenAI Responses as well, or at minimum that support is expected to be available on this API surface.

In practice, however, this does not work.

What I am seeing is:

  1. purpose="user_data" is not supported.
  2. Using purpose="assistants" as the workaround still does not make .docx, .pptx, and .xlsx usable in Azure OpenAI Responses.
  3. The API rejects Office file types when used as input to /responses.
{
  "error": {
    "message": "Invalid input: Expected context stuffing file type to be a supported format: .art, .bat, .brf, .c, .cls, .css, .diff, .eml, .es, .h, .hs, .htm, .html, .ics, .ifb, .java, .js, .json, .ksh, .ltx, .mail, .markdown, .md, .mht, .mhtml, .mjs, .nws, .patch, .pdf, .pl, .pm, .pot, .py, .rst, .scala, .sh, .shtml, .srt, .sty, .svg, .svgz, .tex, .text, .txt, .vcf, .vtt, .xml, .yaml, .yml but got .pptx.",
    "type": "invalid_request_error",
    "param": "input",
    "code": null
  }
}

This is the core problem:

Even if I accept the current Azure limitation around user_data, there still seems to be no usable path at all to provide common Office files to Azure OpenAI Responses.

That is a major capability gap.

For real-world enterprise workloads, .docx, .pptx, and .xlsx are not edge cases. They are standard business document formats. Requiring every customer to build a separate preprocessing pipeline just to convert these documents before using the Responses API is not a reasonable substitute for native support.

I am therefore asking for a direct product answer, not just a documentation clarification:

  1. Is there currently any supported way at all to use .docx, .pptx, and .xlsx with Azure OpenAI Responses API?
  2. If the answer is no, can you explicitly confirm that Azure OpenAI Responses currently lacks support for these file types?
  3. Is native support for .docx, .pptx, and .xlsx planned for Azure OpenAI Responses?
  4. If it is planned, what is the expected timeline or roadmap status?
  5. If it is not planned, what is the recommended Azure-native product path for customers who need to use Office documents with modern Azure OpenAI model APIs?

To be clear: the main request here is that this feature be made available. The current state is not sufficient for common enterprise document workflows.

Thank you.

Azure OpenAI in Foundry Models

2 answers

Sort by: Most helpful
  1. Anshika Varshney 15,535 Reputation points Microsoft External Staff Moderator
    2026-04-01T17:53:22.2766667+00:00

    Hi Alexander Leeb,

    This confusion is understandable and many people have run into the same thing when using the Azure OpenAI Responses API. What you are seeing is mainly due to documentation pointing to OpenAI guidance that does not fully apply to Azure yet. It is not a configuration or service issue.

    Here is how things work today and what to keep in mind.

    First, understand the difference between Azure OpenAI and OpenAI public docs. Some Azure documentation links to OpenAI documentation for file inputs, which lists Office files like docx, pptx, and xlsx as supported. That support currently applies to OpenAI public endpoints, not Azure OpenAI Responses. In Azure OpenAI, the Responses API has a more limited and clearly defined list of supported file types, and Office documents are not included.

    Second, follow the actual behavior of the Responses API. When you pass Office files to the Responses API on Azure, the request fails because those file types are not accepted for context stuffing. The error message you see lists the exact supported formats, and this runtime behavior is the source of truth today. The documentation link to OpenAI file inputs creates the mismatch, not the API itself.

    Third, purpose settings do not change file support. Using purpose set to assistants instead of user data does not unlock Office document support in Azure OpenAI Responses. That workaround only affects how files are classified, not which formats the API accepts. At the moment, there is no supported way to send docx, pptx, or xlsx files directly to the Azure Responses API.

    Fourth, what is supported today. For Azure OpenAI Responses, text based formats such as txt, md, json, html, pdf, and similar plain or semi structured formats are supported. If your data starts as Office documents, it needs to be converted to a supported text or PDF format before being sent to the Responses API. This is expected behavior today and not a bug.

    You can verify the current API behavior and supported patterns in the Azure OpenAI Responses documentation. https://learn.microsoft.com/azure/ai-services/openai/how-to/responses

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

    Right now, Azure OpenAI Responses does not offer native Office document support, even though linked OpenAI docs may suggest otherwise. The documentation is in transition and mixes guidance from different platforms. If you rely on Office files, a preprocessing step to extract or convert content is required before calling the Responses API.

    In short, the mismatch is in the documentation links, not in the service behavior. Treat the Azure OpenAI Responses reference and actual API errors as the authoritative guide.

    Hope this helps clear things up. Do let me know if you have any further queries.

    Thankyou!

    Was this answer helpful?

    1 person found this answer helpful.

  2. AI answer

    2026-03-28T23:55:07.6766667+00:00
    1. There is currently no supported way to use .docx, .pptx, or .xlsx files directly as inputs to the Azure OpenAI Responses API. The Responses API file-input support, as documented, is limited to formats listed in the error message returned by the service (for example .txt, .md, .html, .pdf, .json, .xml, etc.). Models with vision capabilities additionally support PDF input, either as Base64-encoded data or as file IDs, but Office formats are not included in the supported list for context stuffing.
    2. Azure OpenAI Responses currently lacks support for .docx, .pptx, and .xlsx as file input types. The error returned by the service explicitly enumerates the supported formats and rejects .pptx (and by implication .docx/.xlsx) as invalid input:

      "Expected context stuffing file type to be a supported format: ... .pdf, ... .txt, ... .xml, .yaml, .yml but got .pptx."

      In addition, the Responses API documentation only calls out PDF as a supported rich document type for file input:
      • “Models with vision capabilities support PDF input. PDF files can be provided either as Base64-encoded data or as file IDs.”
      • “Only models that support both text and image inputs can accept PDF files as input.”
      There is no corresponding statement that .docx, .pptx, or .xlsx are supported for Responses file input.
    3. The documentation mismatch is real: Azure OpenAI Responses does not currently inherit the full file-type list from the OpenAI “file inputs” guide. The Azure Responses docs:
      • Explicitly describe PDF support and known limitations (for example, “PDF as an input file is now supported, but setting file upload purpose to user_data is not currently supported” and “A purpose of user_data is currently not supported. As a temporary workaround you will need to set purpose to assistants."),
      • Do not list .docx, .pptx, or .xlsx as supported file types for Responses.
      Separately, Azure OpenAI “On your data (classic)” and Assistants Code Interpreter support Office formats as data or tool inputs, but that capability does not extend to Responses context stuffing:
      • On your data (classic) supports .docx, .pptx, .pdf, etc. as indexable data sources.
      • Assistants Code Interpreter supports .docx, .pptx, .xlsx, and many other file types when used with the Assistants/file-upload APIs.
      These are different surfaces from the Responses API and cannot be assumed to have identical file-type support.
    4. No roadmap or timeline for native .docx/.pptx/.xlsx support in Responses is provided in the available documentation. The Responses documentation calls out specific “coming soon” and “known issue” items (for example, web search tool not supported, image upload limitations, PDF support and background-mode streaming performance), but does not mention Office document formats as planned additions. There is no published ETA or roadmap statement in the provided material. Without an explicit statement in the docs, no commitment or timeline for native Office file support in Responses can be derived from the current content.
    5. Recommended Azure-native paths today for Office documents with modern Azure OpenAI models: Based on the available documentation, there are two Azure-native approaches that support Office formats, but they use different APIs than Responses:
      1. Azure OpenAI On Your Data (classic)
      • Supports .docx, .pptx, and .pdf as data formats for indexing:
        • “Azure OpenAI On Your Data supports the following file types: .txt, .md, .html, .docx, .pptx, .pdf.”
      • Intended for retrieval-augmented scenarios where Office documents are ingested into a search/index layer and then queried via chat.
      • Requires using the On Your Data (classic) integration path rather than Responses context stuffing.
      1. Azure OpenAI Assistants with Code Interpreter
      • Code Interpreter supports a broad set of file types including .docx, .pptx, .xlsx:
        • The supported file types table lists .docx, .pptx, .xlsx among many others.
      • Files are uploaded via the Assistants/file upload API with purpose set appropriately (for example assistants), and then used by an Assistant with Code Interpreter.
      • This is a different interaction model from Responses, but it is the Azure-native way to work with Office documents directly in conjunction with model reasoning and code execution.
      For scenarios that specifically require the Responses API today, the only supported path for Office documents is to preprocess them into a supported format (for example, extract text to .txt/.md or convert to .pdf where appropriate) before sending them as file inputs or inline content. This aligns with the broader guidance for data preparation in other Azure OpenAI surfaces, where conversion from unsupported formats is recommended as long as it avoids data loss and noise.

    Summary of direct answers:

    1. There is no supported way today to pass .docx, .pptx, or .xlsx directly as file inputs to the Azure OpenAI Responses API.
    2. Azure OpenAI Responses currently lacks support for these Office file types; the service explicitly rejects them and only documents PDF as a rich document input.
    3. No published plan, ETA, or roadmap statement for native Office file support in Responses is present in the available documentation.
    4. For Azure-native solutions with Office documents and modern models, the documented paths are:
      • Azure OpenAI On Your Data (classic) for indexed retrieval over .docx/.pptx/.pdf.
      • Azure OpenAI Assistants with Code Interpreter, which supports .docx, .pptx, .xlsx as tool/file inputs.
      • For Responses specifically, convert Office files to a supported format (for example .txt, .md, or .pdf) before use.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

    1 person found this answer helpful.

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.