mirror of
https://github.com/open-webui/open-webui.git
synced 2026-05-06 19:08:59 -05:00
[GH-ISSUE #8719] Add /api/v1/embeddings endpoint for 100% OpenAI compatibility
#30755
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/open-webui#30755
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @hdnh2006 on GitHub (Jan 21, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/8719
Feature Request
Hello! I want to use OpenWebUI through the API Key provided by the interface.
I use LiteLLM for 100% OpenAI compatibility and for my use case, I need the users can call an embeddings model registered in LiteLLM. However the endpoint
/api/embeddingsdoesn't exist in/api/v1/:It would be wonderful if you can add it so anyone can use OpenWebUI as a 100% OpenAI compatible API.
Would that be possible?
Is your feature request related to a problem? Please describe.
No, I just want that OpenWebUI can be used as API also.
Describe the solution you'd like
Create
/api/v1/embeddingsthat call the/openai/embeddingsendpoint.Describe alternatives you've considered
This endpoint should call the endpoint
/openai/embeddings. That's it:Additional context
In past versions (
0.4.*) I was able to call/openai/embeddingsendpoint using my API key, but now that's not allowed anymore@jjamgmv commented on GitHub (Jan 27, 2025):
I have the same issue to use continue dev
@Aleksahek commented on GitHub (Jan 28, 2025):
I have this is it: "404 Client Error: Not Found for url: http://localhost:11434/api/embed"
@hdnh2006 commented on GitHub (Jan 29, 2025):
That's Ollama, bro. That's another thing.
@Mavyre commented on GitHub (Feb 8, 2025):
Great idea. That would allow to use Open Webui as an embedding provider for users, whatever Ollama or Openai is used behind it. That would be a real improvement!
@drupol commented on GitHub (Feb 8, 2025):
I also support this initiative.
@tjbck commented on GitHub (Feb 13, 2025):
PR Welcome!
@hdnh2006 commented on GitHub (Feb 14, 2025):
Ok @tjbck, the problem here is that you say you are going to deprecate the route
openai/{path:path}. As it's shown hereis there any chance to revert this deprecation? So we can create the
/api/v1/embeddingsendpoint that calls the/openai/embeddings.@hdnh2006 commented on GitHub (Feb 14, 2025):
No worries @tjbck I have opened a PR, I hope this helps to everyone!
PR: https://github.com/open-webui/open-webui/pull/10018
@hdnh2006 commented on GitHub (Feb 17, 2025):
Due to the PR is closed, I would like to ask you if you can be more specific about what exactly you expect @tjbck .
I would like to have this feature if possible, but I don't understand your comment about it:
This does not implement
/embeddingsendpoint as it should. Please refer to how other endpoints are implemented.Originally posted by @tjbck in https://github.com/open-webui/open-webui/issues/10018#issuecomment-2660359753
@tjbck commented on GitHub (Feb 17, 2025):
@hdnh2006 Your implementation was for OpenAI only, if you take a look at the
/chat/completionendpoint, you'll see we have a compatibility layer that allows users to access models from other providers including Ollama./embeddingsendpoint should be no exception. Hope that helps!Additionally, you should follow FastAPI conventions and adhere to other conventions used throughout the codebase. However, that's a discussion for another time—I can provide a more detailed code review when needed.
@jayteaftw commented on GitHub (Feb 27, 2025):
Hey @tjbck I just wanted to follow up as I have added more functionality to the embedding API to allow for prefixing queries and documents before sending them to an embedding API. This will allow for using instructions based embedding models. If you can review https://github.com/open-webui/open-webui/pull/8594 and let me know if anything needs to be changed or modified I would greatly appreciate it :)
@segtio commented on GitHub (Mar 24, 2025):
+1
@AndiMajore commented on GitHub (Apr 16, 2025):
Supporting this request big time! We are using Ollama internally since many months hosting many different LLMs and using OpenWebUI as a chatting but also authentication layer. For now there was always either a dedicated library for Ollama available, that allowed the used of the /ollama/ endpoint or some workarounds. But now I am reaching the limits with e.g. neo4j, as there no Ollama connector in the form of "apoc.ml.ollama.embedding" exists. For now I had to resort to using ollama without the authentication layer of OpenWebUI, as Ollama provides the /v1 endpoint which allows me to go for "apoc.ml.openai.embedding". Bringing back the authentication layer aka proxying the requests through OpenWebUI would be amazing, so I really hope this /ollama/v1 proxy will still happen!
@hdnh2006 commented on GitHub (Apr 17, 2025):
I will work on this @AndiMajore, my first PR dilikes @tjbck, I hope the next will be suitable.
@pranitl commented on GitHub (May 12, 2025):
@hdnh2006 @AndiMajore , how far along are you guys on this? I was going to submit a similar PR.
@hdnh2006 commented on GitHub (May 13, 2025):
My PR was rejected and I have not had time to dedicate to this. If there's anything you consider I can help you with, please let me know.
@pranitl commented on GitHub (May 15, 2025):
Created this one, hopefully can be merged, link
@gaby commented on GitHub (May 15, 2025):
@pranitl Looking at your PR, how are file uploads managed?
I have Qdrant setup for embedding in OWUI, my OpenAI backend is vLLM which supports
(/v1/embeddings)as documented here https://docs.vllm.ai/en/latest/serving/openai_compatible_server.html#supported-apisTrying to see if your PR makes this work out of the box
@pranitl commented on GitHub (May 15, 2025):
@gaby File uploads for RAG KBs should still use the existing RAG-specific embedding engine and model configuration via the logic for this is primarily within backend/open_webui/routers/retrieval.py and related retrieval modules and the new /openai/v1/embeddings and /ollama/v1/embeddings endpoints are separate general purpose APIs. The goal is to just put any text using hte models specified in the api calls to be resolved by the various backends (OpenAI or Ollama) through OpenWebUI's general model configuration for chat/API access. Theres no automatic link where file uploads will start using these new v1 API endpoints for their embedding needs because the RAG pipeline is distinct.
@hdnh2006 commented on GitHub (Jun 4, 2025):
A new PR that solves this has been opened.
Please check
@Ithanil commented on GitHub (Jun 4, 2025):
@hdnh2006 Thanks for your great effort, hope this one goes through!
@hdnh2006 commented on GitHub (Jun 5, 2025):
Thanks, @Ithanil and all the OpenWebUI developers. I hope this contribution can help everyone make OpenWebUI not only the best interface for AI interaction, but also an administration panel for any AI application. We need to make it more OpenAI-compatible, let's keep working hard 💪
@Ithanil commented on GitHub (Jun 5, 2025):
@hdnh2006 Yes, it's incredible useful that Open WebUI can also serve as an easily manageable API-endpoint for end users.