Usage attribution

Your dashboard meters usage per account and per API key. If you run Appelon behind your own product, that is rarely the breakdown you need: you want to know which of your users spent what, or what one agent run cost across the forty requests it made.

Send two optional fields with any request and Appelon records them on each usage row, so you can group and filter by them in the dashboard.

Both are optional and work on every endpoint.

Example

response = client.chat.completions.create(
    model="gemma",
    messages=[{"role": "user", "content": "Vat dit dossier samen"}],
    user="user_12345",
    extra_body={"session_id": "consult_8842"},
)

user is a standard OpenAI field, so most SDKs take it directly. session_id is an Appelon extension; OpenAI-compatible SDKs pass unknown fields through something like extra_body (Python) or by sending the raw JSON body yourself.

With plain HTTP both are just fields on the body:

curl https://router.appelon.ai/v1/chat/completions \
  -H "Authorization: Bearer $APPELON_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemma",
    "messages": [{"role": "user", "content": "Hallo"}],
    "user": "user_12345",
    "session_id": "consult_8842"
  }'

On the multipart endpoints (/v1/audio/transcriptions, /v1/audio/diarize) send them as form fields alongside the file:

curl https://router.appelon.ai/v1/audio/diarize \
  -H "Authorization: Bearer $APPELON_API_KEY" \
  -F file=@consult.wav \
  -F model=whisperx \
  -F user=user_12345 \
  -F session_id=consult_8842

Choosing identifiers

Use a stable internal id, not something that changes per request. user_12345, customer_abc, or a hashed account id all work; a fresh random string per call does not, because nothing groups.

Prefer internal ids over personal data. An email address or a name works technically, but it means personal data lands in our usage log, which is yours to justify under your own processing agreement. A pseudonymous id you can resolve on your side keeps that out of the picture.

Where it shows up

The requests page in your dashboard gains a Gebruiker column and a filter row once your account starts sending these fields. Filtering by a user narrows the table, the totals and the usage chart together, so the number you read is the usage for that user in that period.

Notes

• Both fields are optional. Requests without them are recorded as before.
• Values longer than 128 characters are rejected with a 400, rather than silently shortened: a truncated identifier would merge two of your users into one line.
• A value that is not a string is rejected the same way.
• session_id is consumed by Appelon and removed before the request reaches the model. user is passed through to the model server, which ignores it.
• These fields are for attribution only. They do not change routing, and they do not apply per-user rate limits or quotas.