Azure OpenAI Vector Store Search returns 404 - Not Found

Hi @Markus von Staden ,

Thanks for going back and testing that — the GET/POST comparison you ran is exactly what was needed, and it settles the question. A 200 on GET /openai/v1/vector_stores/<VS_ID> next to a 404 on POST /openai/v1/vector_stores/<VS_ID>/search, same ID, same endpoint, same credentials, rules out the vector store, the base URL and your auth. The problem is the route itself.

And to answer what you asked at the very start, which I don't think anyone has given you a straight answer on yet: no, there is nothing you need to enable. This isn't a permissions or preview-flag situation on your side.

What's actually happening

The /vector_stores/{id}/search operation is published in the Azure OpenAI REST reference, but it isn't implemented on the Azure OpenAI data plane. Your request is rejected at the gateway before it ever reaches a service that could look up a vector store — which is why you get the generic "Resource not found" body, and why the result doesn't change no matter which API version you try. Microsoft moderators have reproduced this internally (a reproduction dated 2025-04-09 is on record), and on a related internal ticket for an adjacent vector-store sub-route, engineering noted they found no 404 entries in their own service logs at all — consistent with the call never arriving.

I'd rather be upfront than optimistic: this has been the state since at least April 2025. It was described then as on the roadmap with no committed date, and there's still no published ETA. I'm not going to invent one.

One thing to save you time — the api-version=2024-05-01-preview downgrade that circulates for this symptom was tested by another customer on 2025-06-13 with no change in the error. You've already burned effort on the version axis; don't spend more there.

The way forward — use the file_search tool

file_search is the supported retrieval surface over vector stores on Azure, and it queries your existing store directly. No re-upload, no re-indexing, no new resource.

1. Swap the POST to /search for a Responses API call carrying file_search, bound to the same vector_store_id:

{
  "model": "<your-deployment-name>",
  "input": "<your query text>",
  "tools": [{
    "type": "file_search",
    "vector_store_ids": ["<VS_ID>"],
    "max_num_results": 20,
    "ranking_options": { "ranker": "auto", "score_threshold": 0.0 }
  }]
}

You should get HTTP 200 with a FileSearchToolCallResults block in the payload.

2. Read results from FileSearchToolCallResults. Each match returns file_id, filename, score, text and attributes — the same retrieval data your OpenAI-platform /search integration consumes. So the change stays confined to request construction and response parsing; your retrieval logic doesn't need to move. Sanity-check it by confirming the returned file_id values match documents you uploaded to that store.
3. Tune for parity using max_num_results (1–50), ranking_options.ranker (auto, default-2024-11-15, none) and ranking_options.score_threshold (0–1). Filters and hybrid-search weights are supported too. Be aware file_search applies its own defaults — 800-token chunks with 400-token overlap, text-embedding-3-large at 256 dimensions, max 20 chunks into context — so ranking will approximate, not exactly reproduce, what you see on the OpenAI platform. Quick check that your options are landing: raise score_threshold and confirm the result count drops.

Treat this as a substitute API, not a fix — /search is still unimplemented. If its exact semantics are a hard architectural requirement for you, the honest alternative is managing embeddings yourself in Azure AI Search, PostgreSQL/pgvector or Redis. That gives you full control of the query surface at the cost of real implementation work, and I'm happy to walk through it if that's the better fit for your design.

Two more things worth knowing now rather than discovering one at a time: GET /vector_stores/{id}/files/{file_id}/content returns the same 404, so if your design leans on other vector-store sub-routes, it's worth confirming them up front.

And I'd like to raise a feature-gap request on your behalf with the owning engineering team so your scenario is represented in their prioritisation. If you can send me the apim-request-id from a failed POST, the timestamp, and your region and resource name, I'll take it from there.

Reference Links and Tickets:
https://learn.microsoft.com/en-us/answers/questions/2243926/vector-store-search-in-azure-openai-service-return
https://learn.microsoft.com/en-us/answers/questions/2279687/azure-open-ai-vector-store-search-api-returns-404
https://learn.microsoft.com/en-us/rest/api/microsoft-foundry/azureopenai/vector_stores

Thanks,
Manish.

Hi @Markus von Staden

The important change is that the current Microsoft documentation now lists Vector Store Search under the v1 API:

POST https://<resource>.openai.azure.com/openai/v1/vector_stores/<vector_store_id>/search

The api-version parameter is optional and defaults to v1; preview is also documented.

So if you're testing the older route: /openai/vector_stores/{id}/search?api-version=... try the new /openai/v1/ endpoint instead. There were indeed earlier reports where the legacy/preview search route returned 404 even though other Vector Store operations worked.

According to the current REST reference, there shouldn't be a separate feature you need to enable. If the documented v1 endpoint still returns 404 while GET /openai/v1/vector_stores/{id} succeeds for the same ID, capture the apim-request-id response header and raise an Azure support case, as that would point more toward service-side availability/routing than an invalid vector store.

Reference: Azure OpenAI Vector Stores REST API

Help make this community better for everyone: if this answer resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution.