API Keys: UX clarity & env var configuration #31

Closed
opened 2026-03-30 10:33:03 +00:00 by mahmoud · 2 comments
Owner

Problem

The API Keys page shows a generic "Create Key" button with only a name field. This is confusing — it's not clear that these are keys you issue to others to use your broker. Also, there is no way to configure the underlying provider API keys (e.g. OpenRouter, Groq).

Expected Behavior

  • Make it visually clear that this page is for issuing access keys to other users
  • The broker should expect environment variable inputs, e.g.:
    • OPENROUTER_API_KEY
    • GROQ_API_KEY
    • CLAUDE_API_KEY (custom)
  • These should be configurable from a dedicated Providers page (see ), not the API Keys page

Acceptance Criteria

  • Page title/description clarifies purpose (keys you give to others)
  • Provider env var inputs moved to Providers page
  • "Create Key" form only asks for name + optional scoping label
## Problem The API Keys page shows a generic "Create Key" button with only a name field. This is confusing — it's not clear that these are keys *you issue to others* to use your broker. Also, there is no way to configure the underlying provider API keys (e.g. OpenRouter, Groq). ## Expected Behavior - Make it visually clear that this page is for **issuing access keys to other users** - The broker should expect environment variable inputs, e.g.: - `OPENROUTER_API_KEY` - `GROQ_API_KEY` - `CLAUDE_API_KEY` (custom) - These should be configurable from a dedicated **Providers** page (see ), not the API Keys page ## Acceptance Criteria - [x] Page title/description clarifies purpose (keys you give to others) - [x] Provider env var inputs moved to Providers page - [x] "Create Key" form only asks for name + optional scoping label
mahmoud self-assigned this 2026-03-30 12:45:27 +00:00
mahmoud added this to the ACTIVE project 2026-03-30 12:45:30 +00:00
mahmoud added this to the now milestone 2026-03-30 12:45:33 +00:00
Author
Owner

Implementation Spec for Issue #31: API Keys UX Clarity & Provider Configuration

Objective

Refactor the AIBroker admin dashboard so that (1) the existing "API Keys" tab clearly communicates it is for issuing access keys to other users of your broker, and (2) provider API key configuration (OpenRouter, Groq, etc.) is moved to a new dedicated "Providers" tab with env-var-style input fields and runtime update capability.

Requirements

  • API Keys tab title/description must clarify these are access keys you issue to others
  • "Create Key" form should include a name field and an optional scoping/label field
  • A new "Providers" tab must be added for configuring upstream provider API keys
  • Providers tab must show current provider status (configured/not configured, key count) and allow setting/updating keys at runtime
  • Provider key updates should persist and take effect (with restart if needed)
  • All changes must follow existing patterns: Askama templates, Bootstrap 5.3, JSON-RPC via rpc() helper, fragment-based tab panes

Files to Modify/Create

File Action Description
crates/hero_aibroker_ui/templates/index.html Modify Add "Providers" tab; update API Keys tab with clarifying header/description
crates/hero_aibroker_ui/templates/fragments/apikeys_pane.html Create Extract and enhance API Keys tab content with UX copy and label field
crates/hero_aibroker_ui/templates/fragments/providers_pane.html Create New Providers tab with status cards and key management forms
crates/hero_aibroker_ui/src/api/mod.rs Modify Add RPC handlers for providers.list, providers.set_key, providers.remove_key
crates/hero_aibroker/src/config/mod.rs Modify Add methods for runtime provider key updates and status
crates/hero_aibroker_server/openrpc.json Modify Add OpenRPC method definitions for provider endpoints

Implementation Plan

Step 1: Enhance API Keys Tab UX (Template Only)

  • Rename tab from "API Keys" to "Access Keys"
  • Add clarifying header: "Client Access Keys" with subtitle explaining these are keys you issue to others
  • Add optional "Label" field to create form
  • Extract tab content to fragments/apikeys_pane.html

Step 2: Create Providers Tab (Template)

  • Create providers_pane.html with card-based layout showing all known providers
  • Each card shows: provider name, base URL, status badge, masked keys, add/update/remove buttons
  • Add tab navigation entry and tab pane in index.html

Step 3: Add Provider RPC Handlers (Backend)

  • Add ProviderStatus struct and status methods to Config
  • Wrap Config in Arc<RwLock<Config>> for runtime mutability
  • Add providers.list, providers.set_key, providers.remove_key RPC handlers

Step 4: Hot-Reload Providers on Key Change (Backend)

  • Add rebuild_providers() function
  • Update AppState to use shared provider map
  • Note: May be deferred — simpler approach: show "restart required" message after key changes

Step 5: Update OpenRPC Specification

  • Add providers.list, providers.set_key, providers.remove_key method definitions
  • Add ProviderStatus schema

Acceptance Criteria

  • API Keys tab renamed to "Access Keys" with clear description
  • Create Key form includes name + optional label field
  • New "Providers" tab exists in admin dashboard
  • Providers tab shows all known providers with config status
  • Provider keys can be set/updated via UI
  • OpenRPC spec includes new providers.* methods
  • Existing functionality not broken

Notes

  • Step 4 complexity: Hot-reloading providers is invasive since services take ownership of provider map at construction. Pragmatic first pass: update config + show "restart required" message.
  • Security: providers.list must always return masked keys. providers.set_key is behind admin auth.
  • Template pattern: All tab fragments include their own <script> blocks — new fragments follow this pattern.
  • Provider list: The four known providers (OpenAI, OpenRouter, Groq, SambaNova) are hardcoded — Providers tab shows all four regardless of configuration.
## Implementation Spec for Issue #31: API Keys UX Clarity & Provider Configuration ### Objective Refactor the AIBroker admin dashboard so that (1) the existing "API Keys" tab clearly communicates it is for issuing access keys to other users of your broker, and (2) provider API key configuration (OpenRouter, Groq, etc.) is moved to a new dedicated "Providers" tab with env-var-style input fields and runtime update capability. ### Requirements - API Keys tab title/description must clarify these are access keys you issue to others - "Create Key" form should include a name field and an optional scoping/label field - A new "Providers" tab must be added for configuring upstream provider API keys - Providers tab must show current provider status (configured/not configured, key count) and allow setting/updating keys at runtime - Provider key updates should persist and take effect (with restart if needed) - All changes must follow existing patterns: Askama templates, Bootstrap 5.3, JSON-RPC via `rpc()` helper, fragment-based tab panes ### Files to Modify/Create | File | Action | Description | |------|--------|-------------| | `crates/hero_aibroker_ui/templates/index.html` | Modify | Add "Providers" tab; update API Keys tab with clarifying header/description | | `crates/hero_aibroker_ui/templates/fragments/apikeys_pane.html` | Create | Extract and enhance API Keys tab content with UX copy and label field | | `crates/hero_aibroker_ui/templates/fragments/providers_pane.html` | Create | New Providers tab with status cards and key management forms | | `crates/hero_aibroker_ui/src/api/mod.rs` | Modify | Add RPC handlers for `providers.list`, `providers.set_key`, `providers.remove_key` | | `crates/hero_aibroker/src/config/mod.rs` | Modify | Add methods for runtime provider key updates and status | | `crates/hero_aibroker_server/openrpc.json` | Modify | Add OpenRPC method definitions for provider endpoints | ### Implementation Plan #### Step 1: Enhance API Keys Tab UX (Template Only) - Rename tab from "API Keys" to "Access Keys" - Add clarifying header: "Client Access Keys" with subtitle explaining these are keys you issue to others - Add optional "Label" field to create form - Extract tab content to `fragments/apikeys_pane.html` #### Step 2: Create Providers Tab (Template) - Create `providers_pane.html` with card-based layout showing all known providers - Each card shows: provider name, base URL, status badge, masked keys, add/update/remove buttons - Add tab navigation entry and tab pane in `index.html` #### Step 3: Add Provider RPC Handlers (Backend) - Add `ProviderStatus` struct and status methods to Config - Wrap Config in `Arc<RwLock<Config>>` for runtime mutability - Add `providers.list`, `providers.set_key`, `providers.remove_key` RPC handlers #### Step 4: Hot-Reload Providers on Key Change (Backend) - Add `rebuild_providers()` function - Update AppState to use shared provider map - **Note:** May be deferred — simpler approach: show "restart required" message after key changes #### Step 5: Update OpenRPC Specification - Add `providers.list`, `providers.set_key`, `providers.remove_key` method definitions - Add `ProviderStatus` schema ### Acceptance Criteria - [ ] API Keys tab renamed to "Access Keys" with clear description - [ ] Create Key form includes name + optional label field - [ ] New "Providers" tab exists in admin dashboard - [ ] Providers tab shows all known providers with config status - [ ] Provider keys can be set/updated via UI - [ ] OpenRPC spec includes new `providers.*` methods - [ ] Existing functionality not broken ### Notes - **Step 4 complexity:** Hot-reloading providers is invasive since services take ownership of provider map at construction. Pragmatic first pass: update config + show "restart required" message. - **Security:** `providers.list` must always return masked keys. `providers.set_key` is behind admin auth. - **Template pattern:** All tab fragments include their own `<script>` blocks — new fragments follow this pattern. - **Provider list:** The four known providers (OpenAI, OpenRouter, Groq, SambaNova) are hardcoded — Providers tab shows all four regardless of configuration.
Author
Owner

Test Results

  • Total: 21
  • Passed: 21
  • Failed: 0
  • Pre-existing SDK compile error in hero_aibroker_examples (unrelated to this change)
  • cargo check passes cleanly for all modified crates

Implementation Summary

Files Created

  • crates/hero_aibroker_ui/templates/fragments/apikeys_pane.html - New fragment for Access Keys tab with clarifying UX copy, label field, and info alert
  • crates/hero_aibroker_ui/templates/fragments/providers_pane.html - New Providers tab with card-based provider status, key management forms

Files Modified

  • crates/hero_aibroker_ui/templates/index.html - Renamed "API Keys" to "Access Keys", added "Providers" tab, extracted inline JS to fragments
  • crates/hero_aibroker/src/config/mod.rs - Added ProviderStatus struct, provider_status(), add_provider_key(), remove_provider_key() methods
  • crates/hero_aibroker_ui/src/api/mod.rs - Wrapped Config in Arc<RwLock<Config>>, added providers.list, providers.set_key, providers.remove_key RPC handlers
  • crates/hero_aibroker_server/openrpc.json - Added 3 new provider method definitions and ProviderStatus schema

Notes

  • Provider key changes are persisted in-memory and require a server restart to take effect on routing (matching the existing Models pattern)
  • All provider keys are masked in API responses for security
## Test Results - **Total:** 21 - **Passed:** 21 - **Failed:** 0 - Pre-existing SDK compile error in `hero_aibroker_examples` (unrelated to this change) - `cargo check` passes cleanly for all modified crates ## Implementation Summary ### Files Created - `crates/hero_aibroker_ui/templates/fragments/apikeys_pane.html` - New fragment for Access Keys tab with clarifying UX copy, label field, and info alert - `crates/hero_aibroker_ui/templates/fragments/providers_pane.html` - New Providers tab with card-based provider status, key management forms ### Files Modified - `crates/hero_aibroker_ui/templates/index.html` - Renamed "API Keys" to "Access Keys", added "Providers" tab, extracted inline JS to fragments - `crates/hero_aibroker/src/config/mod.rs` - Added `ProviderStatus` struct, `provider_status()`, `add_provider_key()`, `remove_provider_key()` methods - `crates/hero_aibroker_ui/src/api/mod.rs` - Wrapped Config in `Arc<RwLock<Config>>`, added `providers.list`, `providers.set_key`, `providers.remove_key` RPC handlers - `crates/hero_aibroker_server/openrpc.json` - Added 3 new provider method definitions and `ProviderStatus` schema ### Notes - Provider key changes are persisted in-memory and require a server restart to take effect on routing (matching the existing Models pattern) - All provider keys are masked in API responses for security
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
lhumina_code/hero_aibroker#31
No description provided.