Skip to main content

Providers

Provider support in Sentinel is an operator workflow, not just a list of available routes. A provider becomes usable only when Sentinel has the right credential, configuration, and route path for that provider and lane.

What operators configure​

In the Sentinel console, provider setup usually includes:

  • storing the provider credential using Sentinel-managed secret handling
  • creating an active provider configuration
  • confirming any provider-specific metadata such as base URL or version
  • validating that the route path resolves to the intended provider and model

A configured provider is only useful if it also supports the endpoint or SDK behavior you plan to use.

Provider lanes​

Sentinel organizes provider access through lanes. Each lane is designed for a different compatibility goal.

OpenAI-compatible lane​

Use the OpenAI-compatible lane when you want the broadest client compatibility and the most stable shared integration surface.

This lane is typically the best starting point for:

  • chat
  • responses
  • embeddings
  • images
  • transcriptions
  • speech
  • moderations
  • models

Choose this lane when you want one common integration surface across providers.

Anthropic native lane​

Use the Anthropic native lane when you need official Anthropic SDK behavior or provider-native request and response shapes.

Public native prefix:

/v1/anthropic/*

Choose this lane when Anthropic-specific request semantics or SDK behavior matter to your integration.

Google native lane​

Use the Google native lane when you need Google GenAI SDK behavior or provider-native request and response shapes.

Public native prefix:

/v1/google/*

Choose this lane when Google-specific request semantics or SDK behavior matter to your integration.

Hosted configuration guidance​

For each provider, verify that:

  • the configuration is active
  • the provider credential is stored and resolves correctly
  • any provider-specific base URL or version requirement is set correctly
  • the endpoint you are testing is supported for that provider and lane

The goal is not just to register a provider, but to confirm that the provider is actually routable and usable through Sentinel.

Operational caveats​

  • SDK compatibility should be verified at the SDK surface, not only at the raw HTTP path level
  • create, upload, streaming, and live workflows can behave differently from simple JSON inference calls
  • model sync and admin behavior can require provider-specific metadata such as Anthropic API version values

A provider may appear reachable over HTTP while still not matching the exact behavior expected by its native SDK.

Next steps​

  • Routing to understand how Sentinel selects providers
  • SDKs for provider-specific integration behavior
  • Troubleshooting for common provider configuration errors