Principle:FlowiseAI Flowise API Key Management
| Attribute | Value |
|---|---|
| Page Name | API_Key_Management |
| Workflow | Chatbot_Deployment |
| Repository | FlowiseAI/Flowise |
| Domain | Authentication, Security, API Access |
| Source | packages/ui/src/api/apikey.js:L5, packages/ui/src/views/apikey/index.jsx |
| Last Updated | 2026-02-12 14:00 GMT |
Overview
Technique for creating and managing API keys that authenticate programmatic access to deployed chatflows.
Description
API keys provide bearer token authentication for chatflow API endpoints. Each key has a display name (for human identification), a key value (the bearer token shown once at creation time), and a secret (stored server-side for validation). Keys are used in the Authorization header for API requests to prediction endpoints.
The API key system enables controlled access to chatflows without sharing user credentials. The lifecycle of an API key includes:
- Creation: A new key is created with a user-specified
keyName. The system generates a randomapiKey(bearer token) andapiSecret. TheapiKeyis displayed once and should be copied immediately. - Assignment: An API key is assigned to a chatflow via the API Code Dialog. The chatflow's
apikeyidfield stores the reference to the assigned key. - Usage: External callers include the API key as a bearer token in the
Authorizationheader when making prediction requests. - Management: Keys can be renamed, regenerated, or deleted. The API key management page lists all keys with their names and creation dates.
The API key management is exposed through two UI components:
APIKeyDialog.jsx(492 lines) handles creating and editing individual keysapikey/index.jsx(544 lines) provides the full key management page with listing, search, and CRUD operations
Usage
Use this principle when creating authentication credentials for programmatic chatflow access. Apply when:
- A chatflow needs to be protected from unauthorized access while still being callable via API
- Different API consumers need separate credentials for tracking and revocation
- Integrating a chatflow into a backend service that needs authenticated access
When Not to Use
- For public chatbots where no authentication is desired (use Public Chatbot Sharing instead)
- For embedded widgets where API key usage is not supported (the embed flow requires "No Authorization" mode)
Theoretical Basis
This technique implements the bearer token authentication pattern. API keys are randomly generated, stored server-side with hashing, and validated on each request. The key-name pair enables users to manage multiple API keys for different integrations.
The security model follows these principles:
- One-time display: The API key value is shown only at creation time. If lost, a new key must be generated. This reduces the window of exposure.
- Named keys: Each key has a human-readable name, enabling operators to identify which integration uses which key and to revoke specific keys without affecting others.
- Per-chatflow assignment: Each chatflow references at most one API key, creating a clear mapping between credentials and resources.
- Separation from user credentials: API keys are distinct from user login credentials, allowing programmatic access without exposing user accounts.
The UI integration with the API Code Dialog means that selecting an API key immediately updates the generated code examples to include the proper Authorization header, reducing the chance of misconfiguration.