Your app is live

Give your app AI

Point any OpenAI- or Anthropic-compatible client at the gateway, authenticate with your Dibbla token, and read every call back in the ledger.

The gateway’s whole proposition fits in one sentence: your Dibbla token is the model key. Point a client at the gateway, put your Dibbla token where the provider key would go, and the platform swaps in its own on the way out.

Nobody on your team ever holds an OpenAI or Anthropic key, and every call is attributed to your organisation.

From a deployed app

Your app needs two things: the gateway’s URL, and a Dibbla token to authenticate with. Neither is free — set both as secrets before you write any code:

# a Dibbla API token, minted in the portal under API keys
$printf '%s' "$TOKEN" | dibbla secrets set DIBBLA_API_TOKEN -d my-app
$dibbla secrets set DIBBLA_AI_GATEWAY_URL "$(dibbla ai url)" -d my-app
# dibbla ai url prints https://ai.dibbla.com

The platform does not give your app a token

A deployment receives DIBBLA_ALIAS, DIBBLA_SERVICE_NAME and friends, and a multi-service deploy also receives DIBBLA_AI_GATEWAY_URL. It never receives DIBBLA_API_TOKEN — nothing would be safe about handing every container a credential for the whole organisation. And a single-Dockerfile deploy, which is what your first deploy produces, gets neither of the two variables above. Setting both as secrets works for either shape, which is why it is written that way here.

Two endpoints are exposed, so you keep using whichever SDK you already know:

import os
from openai import OpenAI

client = OpenAI(
  base_url=os.environ["DIBBLA_AI_GATEWAY_URL"] + "/openai/v1",
  api_key=os.environ["DIBBLA_API_TOKEN"],   # your Dibbla token
)
client.chat.completions.create(model="gpt-5-mini", messages=[...])

import os
from anthropic import Anthropic

client = Anthropic(
  base_url=os.environ["DIBBLA_AI_GATEWAY_URL"] + "/anthropic",
  api_key=os.environ["DIBBLA_API_TOKEN"],   # your Dibbla token
)
client.messages.create(model="claude-haiku-4-5", max_tokens=200, messages=[...])

Send the X-Dibbla-App header — your DIBBLA_ALIAS, which a manifest deploy does inject — and the call is recorded against that app. Without it the call still works; it is simply recorded as coming from outside.

From your laptop

The same gateway backs your own tools. dibbla ai env prints the exports for Claude Code, Cursor or opencode:

$dibbla ai url
$eval $(dibbla ai env)
$dibbla ai test

The ledger

Every call lands in a ledger you can read, live.

The AI gateway ledger, listing model calls with app attribution, tokens and latency

Time, user, app, route, model, prompt and completion tokens, latency, status. Calls made by a deployed app carry its alias; calls from a laptop tool show as external. Clicking a row opens the full trace.

The console shows the same data aggregated, which is the view you want when the question is about spend rather than about one request:

The console AI usage view, aggregating model spend for the organisation

Why this is worth the indirection

Provider keys spread. One gets pasted into a laptop, another into a CI variable, and eighteen months later nobody can say which app is spending what — or rotate a key without breaking something unknown. Here there is one credential per person or app, it is already rotatable, and attribution is a property of the system rather than a convention people follow.

← Previous

Rotate secrets and env vars

Query your data