Principle:Helicone Helicone Provider Definition
| Knowledge Sources | |
|---|---|
| Domains | LLM Gateway, Provider Abstraction, Software Architecture |
| Last Updated | 2026-02-14 00:00 GMT |
Overview
A provider definition is an abstract contract that specifies how an LLM gateway communicates with a particular inference service, encapsulating URL construction, authentication, and request body formatting behind a uniform interface.
Description
When an LLM gateway needs to proxy requests to many different inference providers (OpenAI, Anthropic, Google, AWS Bedrock, etc.), each provider has its own API base URL, authentication scheme, request body format, and error response structure. Without a common abstraction, the gateway routing logic would need provider-specific branching at every decision point, creating an unmaintainable codebase.
The Provider Definition principle addresses this by defining an abstract base class that every provider must extend. This base class declares the minimal set of abstract properties (display name, base URL, authentication type, documentation links) and abstract methods (URL building, authentication header injection, request body transformation, error message extraction) that the gateway needs to route a request end-to-end.
The key architectural insight is that all provider interactions reduce to the same set of operations: construct the target URL from an endpoint configuration and request parameters, produce authentication headers from credentials and context, transform the unified request body into the provider-specific format, and parse error responses into a standard structure. By formalizing these operations as abstract methods, the gateway can treat all providers identically at the routing layer.
Usage
Use this pattern when:
- Adding a new LLM provider to the gateway
- The new provider requires custom URL construction, authentication headers, or body transformation
- You need the gateway to treat the new provider identically to all existing providers at the routing layer
Theoretical Basis
The Provider Definition follows the Template Method and Strategy design patterns. The abstract base class defines the skeleton algorithm for proxying a request (build URL, authenticate, build body, handle errors), while concrete subclasses supply the provider-specific steps.
This is a form of polymorphic dispatch: the gateway holds a reference typed as the base class and calls methods on it, and the runtime resolves these to the correct provider-specific implementation. The result is that adding a new provider requires only creating a new subclass -- no changes to the gateway routing code.
Pseudocode of the gateway proxying algorithm:
function proxyRequest(provider, endpoint, authContext, requestBody):
url = provider.buildUrl(endpoint, requestParams)
headers = provider.authenticate(authContext, endpoint)
body = provider.buildRequestBody(endpoint, requestBodyContext)
response = httpClient.post(url, headers, body)
if response.isError:
error = provider.buildErrorMessage(response)
return formatError(error)
return response
Each step in the algorithm is delegated to the provider instance, which may be any concrete subclass. The gateway itself is closed to modification when new providers are added (Open/Closed Principle).