Protect the /vector/upsert endpoint with Authorization option

[bbaaxx]

Currently, the /vector/upsert endpoint is open and there is no option to protect it with the API Key.
It would probably be a good idea to either protect it by default or add a switch like the one used on the "Embed in website or use as API" view.

[Jaredude]

Currently, the /vector/upsert endpoint is open and there is no option to protect it with the API Key. It would probably be a good idea to either protect it by default or add a switch like the one used on the "Embed in website or use as API" view.

It sounds like you have the vector loading in the same flow as your chat. If the vector load is part of the chat flow, you can still protect the entire flow with an apiKey, but you won't be able to share or embed the flow.

Your vector upsert should be in a separate flow from your chat flow. In that flow, you'd perform whatever upsert is necessary to a permanent vector db and protect that flow with an apiKey. Something along these lines (text splitter, document, embeddings, permanent vector storage):

Then you'd have a separate flow with just the necessary pieces for querying your permanent storage. Something along these lines (Embeddings, permanent vector storage, model, conversation retrieval QA):

You'd protect the upsert flow via an apiKey, and that will protect your upsert from public calls and still allow you to share and embed your chat.

[bbaaxx]

Thanks for sharing this! It's definitely got me thinking, especially about the potential to overload the /prediction endpoint with what I now call "utility flows". That's a compelling approach.

[HenryHengZJ]

Like @Jaredude you can either separate out into different chatflow.

Or if you are using the same flow, but with the new vector/upsert API:

Although the UI doesn't have the API Key like the prediction API:

Both are still able to use as Authorization: "Bearer your-api-key"

[bbaaxx]

Ohh nice, it was unclear to me from the UI only, but thanks for the clarification.