Providers

Providers represent the LLM backends that power Glow. Each provider encapsulates an external AI service — such as OpenAI or Anthropic — along with its API endpoints, authentication keys, and configuration values. Models connect to providers to gain access to these backends.

What is a Provider?

A provider in Glow is the infrastructure layer between your platform and an external LLM service. It stores:

• Endpoints — the base URL for API calls (e.g., https://api.openai.com/v1)
• Keys — encrypted API credentials for authenticating with the service
• Values — configuration parameters specific to the provider
• Departments — organizational scoping for access control

Providers are shared resources. A single “OpenAI” provider can serve multiple models (gpt-4o, gpt-4o-mini, o1), each configured with its own temperature, quality, and modality settings.

How it Connects

Provider  -->  Model (model has provider_id)
   |               |
   |               +--> Agent (via agent_models_junction)
   |
   +-- endpoints, keys, values (encrypted config)

• Models reference providers through provider_ids. Each model’s search result includes provider_id and provider_name.
• The model_usage_count and model_ids fields on the provider list response show how many models depend on each provider.
• Providers do not connect directly to agents, tools, rubrics, or evals. They are always accessed through models.

Create a provider

Via the CLI

Calls below use $GLOW_INSTANCE_URL + $GLOW_TOKEN — see Authentication to export them once.

glow providers create --body '{
  "providers": [{
    "name": "OpenAI Production",
    "description": "Production OpenAI API for TA training simulations"
  }]
}'

Via the API

curl -X POST $GLOW_INSTANCE_URL/provider/create \
  -H "Authorization: Bearer $GLOW_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "providers": [{
      "name": "Anthropic Production",
      "description": "Anthropic Claude API for office hour simulations"
    }]
  }'

Each entry returns the new provider_id, a generated draft_id, and the initial version.

Endpoints

Provider endpoints define where API calls are routed. Each provider can have multiple endpoints configured through endpoint_ids. Endpoints are managed as resources within the provider’s configuration sections.

When you retrieve a provider with GET, the response includes an endpoints section containing the current endpoint resource and all available endpoint options.

API key management

Provider keys hold encrypted credentials. Keys are never returned in plaintext from list or search operations. To decrypt a key, use the dedicated decrypt endpoint — every decrypt request is audited with the requesting user’s identity.

curl -X POST $GLOW_INSTANCE_URL/provider/decrypt \
  -H "Authorization: Bearer $GLOW_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "provider_id": "PROVIDER_UUID",
    "key_id": "KEY_UUID"
  }'

The response returns the decrypted key value, the key name, and the actor_name of the requesting user.

The draft cycle

Providers support a draft workflow for staging configuration changes. This is useful when rotating API keys or switching endpoints without disrupting running simulations.

# Create or update a provider draft
glow providers draft --body '{
  "name": "OpenAI Production",
  "description": "Updated endpoint for v2 API",
  "endpoint_ids": ["NEW_ENDPOINT_UUID"],
  "key_ids": ["NEW_KEY_UUID"]
}'
 
# List your drafts
glow providers list

The draft endpoint uses PATCH semantics. Include input_draft_id and expected_version for updates to existing drafts. The response includes draft_id, new_version, and a form_state object reflecting the server-authoritative state of all fields.

Search & filter

glow providers search --body '{"search": "openai"}'
 
glow providers search --body '{
  "filter_department_ids": ["CS_DEPT_UUID"],
  "page_size": 25
}'

Bulk operations

Bulk delete and update follow the canonical all-matching shape — explicit IDs, or all: true with flat filter fields plus optional excluded_ids and a patch body. The persona surface is the prove-out; providers adopt the same shape.

Delete by explicit IDs:

curl -X POST $GLOW_INSTANCE_URL/provider/delete \
  -H "Authorization: Bearer $GLOW_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"provider_ids": ["UUID_1", "UUID_2"]}'

Each item in the results array indicates whether that specific deletion succeeded, along with a message.

Delete all matching a filter (with exclusions):

glow providers delete --body '{
  "all": true,
  "filter_department_ids": ["dept-retired"],
  "excluded_ids": ["provider-keep-this-one"]
}'

Duplicate a provider:

curl -X POST $GLOW_INSTANCE_URL/provider/duplicate \
  -H "Authorization: Bearer $GLOW_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"provider_id": "PROVIDER_UUID"}'

The response returns a new provider_id for the duplicated provider.

Common Operations

Related

• Providers API Reference — full endpoint and type documentation
• Providers CLI Reference — all CLI commands
• Models Guide — configure models that use these providers