Integrations · LiteLLM

One gateway. Every Vidman AI model.

LiteLLM Proxy stands between your developers and the API: they receive one OpenAI-compatible endpoint, you keep the provider credentials and access control server-side.

Get an API keySee the setup
config.yaml OpenAI-compatible
model_list:
  - model_name: deepseek-v4-flash
    litellm_params:
      model: openai/deepseek-v4-flash
      api_base: https://api.vidman.ai/v1
      api_key: os.environ/VIDMAN_API_KEY

  - model_name: kimi-k3
    litellm_params:
      model: openai/kimi-k3
      api_base: https://api.vidman.ai/v1
      api_key: os.environ/VIDMAN_API_KEY

One entry per model. The openai/ provider plus the Vidman AI base URL — no custom provider needed.

The setup

Four steps to a shared gateway.

The proxy runs wherever you host it — a dev box, a container, your infra. Once it is up, developers stop touching provider credentials entirely.

01

Prerequisites

A Vidman AI API key from the platform console, and LiteLLM installed:

pip install "litellm[proxy]"
02

Configure your models

One entry per model you want to expose. Use the openai/ provider prefix with the Vidman AI base URL — any served model id works, including your own fine-tuned checkpoint on a dedicated endpoint.

model_list:
  - model_name: deepseek-v4-flash
    litellm_params:
      model: openai/deepseek-v4-flash
      api_base: https://api.vidman.ai/v1
      api_key: os.environ/VIDMAN_API_KEY

  - model_name: kimi-k3
    litellm_params:
      model: openai/kimi-k3
      api_base: https://api.vidman.ai/v1
      api_key: os.environ/VIDMAN_API_KEY
03

Start the proxy

Export the Vidman AI key where the proxy runs, then start LiteLLM with your config:

export VIDMAN_API_KEY="sk-vidman-..."
litellm --config config.yaml
04

Call a model

Developers authenticate to the proxy with a virtual key — never the Vidman AI key itself:

curl http://localhost:4000/chat/completions \
  -H "Authorization: Bearer $LITELLM_VIRTUAL_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-v4-flash",
    "messages": [{"role": "user", "content": "Say pong in one word."}]
  }'

Key layout

Two keys, two jobs.

The Vidman AI key never reaches a developer machine. Virtual keys do the per-person work, and can be revoked without touching the upstream credential.

Key
Who holds it
Used for
Vidman AI API key (sk-vidman-...)
The LiteLLM server (env or secret store)
Upstream Vidman AI inference
LiteLLM virtual key
Each developer or service
Proxy authentication and spend tracking

A common pattern: one Vidman AI service-account key on the proxy, virtual keys per developer for access control and attribution.

Why a gateway

Credentials in one place. Developers everywhere else.

One endpoint for every model

Developers hit one local endpoint while the proxy maps model names onto the Vidman AI catalog. Change a model behind the gateway and no client code moves.

Per-developer keys, per-developer spend

A single Vidman AI key stays on the server. Every developer receives a virtual key, so usage and cost attribute per person or per service with no credentials shared.

Access control at the gateway

Which models each team may call, rate limits and budgets are all enforced at the gateway — and the same zero-log, zero-retention guarantee covers every request behind it.

Questions teams ask before adding a gateway

What is LiteLLM Proxy?+

A gateway that puts one OpenAI-compatible API in front of one or more model providers. Your developers talk to the proxy; the proxy holds the provider credentials, issues per-developer virtual keys, and tracks spend per key.

Which Vidman AI models can I expose through it?+

Any served model id from the catalog, plus your own fine-tuned checkpoint on a dedicated endpoint — both speak the same OpenAI-compatible API, so both run on the same openai/ provider config.

How are the keys laid out?+

The Vidman AI API key stays only on the LiteLLM server, in its environment or secret store. Developers and services authenticate against the proxy with virtual keys — which is exactly what LiteLLM uses for access control and spend attribution.

Does the gateway change how traffic is billed?+

No. Requests still bill by the million tokens at the catalog rates. LiteLLM layers its own per-virtual-key spend tracking on top, so you can see which team or service drove which cost.

Stand every Vidman AI model behind one endpoint tonight.

Get 50% extra on your first wallet top-up.

Get an API keyAgent integrations

Per-million-token billing · Zero data retention · Your weights stay yours