Open-WebUI-Functions: provider pipelines and filters for Open WebUI

What Open-WebUI-Functions extends

Open WebUI is a self-hosted interface for large language models, and it supports custom functions: pipelines that handle requests to a provider, and filters that pre- or post-process messages. Open-WebUI-Functions is a collection of those, written in Python, that connect Open WebUI to external providers and add processing steps. The README lists provider pipelines for Azure AI, Google Gemini and Infomaniak, an n8n integration for automation, plus filters such as a time and token tracker and search tools. The audience is people already running Open WebUI who want to add a specific provider or behavior without writing the integration from scratch. It is not a standalone app; every piece here is meant to be dropped into an existing Open WebUI instance by an administrator, so it presupposes you have that instance running.

Pipelines, filters and integrations

The repository is organized around three kinds of function. Pipelines are provider connectors, grouped in folders for Azure, Google, Infomaniak and n8n, that handle both streaming and non-streaming requests to those services. Filters sit in the request or response path and change what flows through, with the README naming a time and token tracker, a Google search tool and a Vertex AI search tool. Integrations tie Open WebUI to outside systems, with n8n the headline example, so a chat can trigger an automation workflow. The README also calls out secure secret handling, encrypting sensitive values such as API keys rather than leaving them in plain configuration. The structure matters for adoption: you take the one pipeline or filter you need rather than installing a monolith, which suits a system where each function is a self-contained unit of code.

Installing a function through the admin panel

Installation is not a package install; it happens inside Open WebUI. The prerequisites are a running Open WebUI instance, admin access, and any provider service a given pipeline depends on, such as an Azure AI resource. You open Admin Settings, go to the Functions tab, add a new function, and paste the function code from this repository into the editor, then set any required environment variables such as API keys. For working on the repository itself rather than just using a function, it declares its toolchain with pixi, so a source checkout is set up with:

pixi install

That distinction matters: end users copy a single function into the admin panel, while contributors use the pixi environment to develop and lint. Either way, you need administrator rights in Open WebUI, since only an admin can add functions.

Where the collection stops

The limitations follow from what this is. It is a collection of functions, not a supported product, so each pipeline is only as current as its last update against a provider's API, and a provider change can break a specific connector without affecting the rest. It depends entirely on Open WebUI, so it does nothing on its own, and it depends on admin access, which rules it out for users on a managed instance they do not control. Some pipelines require paid external services, Azure AI being the clear example, so the functions are free but the providers they reach may not be. And because installation is copy-paste into an admin editor, you are running third-party code inside your instance, which is a reason to read a function before you paste it, especially where it handles keys.

Using a curated collection versus writing your own function

The alternative is to write the pipeline or filter yourself against Open WebUI's function interface, or to use Open WebUI's built-in connection to an OpenAI-compatible endpoint. Rolling your own gives you exactly what you want and nothing you do not, at the cost of learning the interface and maintaining the code as the provider changes. A built-in OpenAI-compatible connection is the simplest path when your provider already speaks that protocol, but it does not cover services with their own APIs and quirks, which is where Azure AI, Gemini, Infomaniak and n8n integrations earn their place. Open-WebUI-Functions sits in the middle: you get a vetted starting point for a specific provider, with secret handling and streaming already worked out, in exchange for trusting and maintaining code you did not write. For a provider it already covers, that is usually the faster route.

Apache-2.0 and maintenance

The collection is under Apache-2.0, a permissive license with a patent grant, so you can use, adapt and redistribute the functions in commercial settings with attribution. The last push was on 2026-08-19, and the project uses a versioning workflow with automated badges and releases; one release even flags that parts of its notes were generated by AI and may contain mistakes, telling you to verify against the actual commits, which is a candid disclosure to make. Because each function targets a moving provider API, treat maintenance as per-function rather than project-wide: a pipeline is reliable to the extent its provider integration has been kept current. Before adopting one, check when its file last changed and read it, since you will be pasting it into an instance where it can see your keys and traffic.

Editorial conclusion

Adopt Open-WebUI-Functions if you run your own Open WebUI instance with admin access and need a ready pipeline or filter for Azure AI, Google Gemini, Infomaniak or n8n rather than writing one. Do not expect it to do anything without Open WebUI, and do not use it on a managed instance where you lack admin rights. Install by pasting the specific function into the admin Functions tab and setting its environment variables, and read the function first, since it runs inside your instance and can see your keys.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. owndev/Open-WebUI-Functions on GitHub
3. Project website
4. README
5. Releases