Principle:Helicone Helicone Provider Dashboard Integration
| Knowledge Sources | |
|---|---|
| Domains | Dashboard UI, Provider Metadata, Frontend Architecture |
| Last Updated | 2026-02-14 00:00 GMT |
Overview
Provider dashboard integration is the practice of maintaining a static metadata array that describes each LLM provider's display properties, documentation links, and authentication hints so that the frontend can render provider selection, configuration, and onboarding UI without hard-coding provider-specific logic.
Description
An LLM observability dashboard needs to present users with a list of supported providers, each with its logo, name, description, documentation link, API key format hint, and relevance ranking. If this metadata were scattered across individual UI components, adding a new provider would require modifying multiple frontend files and risk inconsistency.
The Provider Dashboard Integration principle centralizes all provider display metadata into a single, declarative data array. Each entry is a plain object conforming to a typed interface, and the frontend UI components consume this array to render provider cards, selection dropdowns, configuration forms, and onboarding wizards. The data is sorted by a relevanceScore field so the most popular providers appear first.
This approach cleanly separates the "what providers exist and how they look" concern from the "how to render them" concern. Adding a new provider to the dashboard is a single-file, data-only change with no UI logic modifications required.
Usage
Use this pattern when:
- Adding a new provider to the dashboard's provider selection UI
- Building or updating provider onboarding flows
- Rendering provider logos, descriptions, or documentation links anywhere in the frontend
- Controlling provider visibility (some providers like Helicone Inference are not publicly visible)
Theoretical Basis
This is an instance of Data-Driven UI: the UI structure and content are determined by a declarative data source rather than imperative code. The component tree iterates over the metadata array and renders each entry uniformly, applying the same layout and styling to every provider.
The relevanceScore field implements a weighted ranking algorithm at the data level. Instead of hard-coding display order in the template, the array can be sorted by this numeric score to present providers in order of popularity or strategic importance.
The optional publiclyVisible and auth fields enable feature flagging at the provider level, allowing certain providers to be hidden from public view or to trigger alternative authentication flows (e.g., service account upload instead of API key input).
Pseudocode:
providerMetadata = [
{ id: "provider-a", name: "...", logo: "...", relevance: 100, ... },
{ id: "provider-b", name: "...", logo: "...", relevance: 90, ... },
...
]
function renderProviderList(metadata):
sorted = metadata.sortBy(relevance, descending)
for each entry in sorted:
if entry.publiclyVisible != false:
renderProviderCard(entry)