Azure OpenAI Responses API: image file_id fails with “Error while downloading file” in Foundry private BYO-storage setup

Kristoffer Marboe 0 Reputation points
2026-11-06T14:05:39.2566667+00:00

I’m investigating an image-input failure when calling the gpt-6-luna deployment through a Microsoft Foundry project endpoint.

The image uploads successfully through the project-scoped Files API with purpose="assistants". However, referencing the returned ID in a Responses request fails with HTTP 400:


{

  "error": {

    "message": "Error while downloading file.",

    "type": "invalid_request_error",

    "param": "url",

    "code": "invalid_value"

  }

}

Environment

  • Foundry Standard setup with customer-managed Storage, Cosmos DB, and Azure AI Search.
  • Agent network injection into a customer VNet.
  • Storage public network access disabled; approved blob private endpoint.
  • Foundry and Search public access enabled with IP restrictions.
  • All required service endpoints resolve to private IPs through the VNet’s configured DNS server when tested from our machine.
  • Project managed identity has Storage Account Contributor, Storage Blob Data Contributor, and a conditional Storage Blob Data Owner assignment.
  • Microsoft Entra ID authentication.

Reproduction

Using the same project-scoped OpenAI client for upload and inference:


with open("image.png", "rb") as image:

    uploaded = client.files.create(

        file=image,

        purpose="assistants",

    )

response = client.responses.create(

    model="gpt-6-luna",

    store=False,

    input=[{

        "role": "user",

        "content": [

            {"type": "input_text", "text": "Describe this image."},

            {"type": "input_image", "file_id": uploaded.id},

        ],

    }],

)

The endpoint is:


https://<account>.services.ai.azure.com/api/projects/<project>/openai/v1/

No agent reference, tools, or existing conversation is involved.

Checks Already Completed

  • Files API upload succeeds for the 73,298-byte PNG.
  • File metadata retrieval and content download succeeded for an earlier equivalent upload; downloaded bytes have a valid PNG signature.
  • The same image submitted as inline base64 through input_image.image_url succeeds.
  • The file-ID failure reproduces in both our C# application and a standalone Python script.
  • Adding Storage Account Contributor did not resolve the issue.
  • Blob diagnostics show a successful read by Foundry’s file service using the project identity. We have not established whether the failing image-processing request reaches storage.

Latest Failure

  • File ID: assistant-TZ4wjudCTFRRPqB2iUVxrB
  • Started: 2026-11-06T13:57:02.106338Z
  • Failed: 2026-11-06T13:57:04.098939Z
  • APIM request ID: 1b0f5909-0ce6-43b8-b257-8c8c99c5801b
  • x-request-id: 84dbd505-a850-4e10-9045-94146e5eda1f
  • Error-body request ID: 64f75b44d388608de93bd3b44310c093

Questions

The Responses API documentation explicitly documents image input using uploaded file IDs, but its examples use the Azure OpenAI resource endpoint.

  1. Is input_image.file_id supported for files uploaded through a Foundry project-scoped Files API with private BYO storage?
  2. Does image processing retrieve these files through a different identity or network path from the Files API download operation?
  3. Are additional configuration requirements or known limitations applicable to this setup?
  4. Which diagnostics can reveal the underlying download failure beyond the generic HTTP 400 error?
Microsoft Foundry
Microsoft Foundry

A unified Azure platform for creating and managing AI models, agents, and applications with built‑in enterprise security, monitoring, and governance

0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Vasileios Dionysopoulos 821 Reputation points
    2026-11-07T15:24:11.68+00:00

    I don't know of documentation that confirms or rules out input_image.file_id with project-scoped files on private BYO storage. Your evidence, though, points to a specific split, and you can confirm it from your side in about 30 minutes.

    What your symptoms suggest

    • The Files API path works: upload succeeds, metadata and content download succeed, and blob logs show a read by Foundry's file service with the project identity.
    • The inference path fails with param: "url" and "Error while downloading file". That suggests the model service resolves the file ID to a blob URL and downloads it itself, which is a different caller from the file service.
    • Inline base64 works, so the model, the deployment and the image are fine.

    In other words, it looks like the Files API reaches your storage through the Foundry network-injected/trusted path, while the image fetch for inference comes from a caller that your storage firewall (public access disabled) or RBAC doesn't allow. That's my inference from the symptoms, not a documented behavior.

    1. Diagnose it: did the failing request reach storage?

    With diagnostic settings enabled on the storage account (blob → StorageRead to Log Analytics):

    StorageBlobLogs
| where TimeGenerated between (datetime(2026-11-06T13:56:50Z) .. datetime(2026-11-06T13:57:10Z))
| project TimeGenerated, OperationName, StatusCode, StatusText,
          CallerIpAddress, AuthenticationType, RequesterObjectId, Uri
| order by TimeGenerated asc
    What you see Meaning
    403 AuthorizationFailure from a non-VNet IP The network firewall blocks the inference service. Go to test 2.
    403 AuthorizationPermissionMismatch Wrong identity. Check RequesterObjectId: it's probably the Foundry account's managed identity, not the project's. Grant that principal Storage Blob Data Reader.
    No entry at all The request never reached your account. It's either a DNS/network path issue or the service reads from a different store. This is a support-case item.

    2. Isolate the network path (temporary test)

    On the storage account, temporarily switch from Disabled to Enabled from selected networks with no public IPs, and add:

    • Exceptions: Allow Azure services on the trusted services list to access this storage account
    • Resource instances: Microsoft.CognitiveServices/accounts → your Foundry account

    These don't open the account to the internet. If file_id starts working, the inference fetch needs the trusted-service path. Keep that configuration, or revert and stay on base64.

    3. Isolate BYO storage

    Run the same upload + responses.create against the resource endpoint (https://<account>.openai.azure.com/openai/v1/), as in the Responses documentation example. Files uploaded there go to service-managed storage. If it works there and fails on the project endpoint, the limitation is specific to project files on BYO storage.

    Answers to your four questions, briefly

    1. Supported? Not documented either way for project-scoped BYO storage. Test 3 tells you whether it's a limitation.
    2. Different identity/path? Your logs plus the param: url error suggest yes. The KQL above shows which identity and IP actually call.
    3. Extra configuration? Most likely the trusted-services/resource-instance rule, and Blob Data Reader for the Foundry account identity.
    4. Diagnostics? StorageBlobLogs as above. If nothing shows up, open a support case with the APIM request ID, x-request-id, file ID and timestamps you already have. Those are exactly what the product team needs.

    Workaround meanwhile: inline base64 through input_image.image_url (which you've confirmed works), keeping images under the request size limits.

    References: Responses API – file input · Azure Storage trusted services and resource instance rules · Monitor Azure Blob Storage – StorageBlobLogs

    Was 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.