Images, audio and video

None of these endpoints routes. Nothing Inferbase measures ranks image models against each other, or speech models, or video models, so there is no evidence to choose on. The routing policy decides instead: name a model, or send auto and take the first model of that type the key can reach.

What auto reaches depends on the policy's pool. A policy that names a pool makes that pool the whole list, in the order you arranged, and a request naming a model outside it is refused with 403. A policy on the default catalog pool restricts nothing, and auto takes the first model of that type in catalog order.

Where these models run

In practice these four endpoints serve on your own credential: a provider key or a cloud account you have connected. Connect a key under Connections, add the model to your routing policy's pool, and it serves.

An Inferbase route can serve them too, but only when that route carries a rate in the unit its vendor bills in. No route does today, so naming a model Inferbase serves on its own routes returns 503 with the fix in the message.

The reason is pricing rather than capability. Image, audio and video vendors bill per image, per megapixel, per character, per minute or per video, never per token, and a per-token rate computes nothing against a request that spends no tokens. Serving one without a rate in the right unit would mean charging you nothing for generation that costs us money. On your own credential the vendor bills you directly, so there is nothing for us to compute and nothing to get wrong.

Refusals

Four refusals are specific to choosing the model. All four arrive before the provider is called, so nothing is billed.

Rate limits, the key's spend cap and the project's budget apply here as they do on chat, so 429 and 402 are also possible.

What the usage row records

Chat, embeddings and rerank are metered in tokens. These are not, so the usage row records its own units and leaves the token counts at zero. Logs shows those units in place of a token count.

A row records every unit the request makes knowable, not only one. Hosts disagree about which unit they charge in, and one that charges per image today may charge per megapixel tomorrow, so the row is written to stay readable either way.

A transcription only states its duration when you ask for verbose_json. Without one the row records nothing for that request rather than estimating seconds from the file size. The duration is recorded exactly as the provider stated it, unrounded.

Every row for these endpoints costs zero, because your own credential paid the provider.

Image generation

Request

These are the whole list. A field outside it is a 422, including a parameter the provider itself accepts, because a silently dropped field would make the response a different request from the one you sent.

Example

curl https://api.inferbase.ai/api/v1/inference/images/generations \
  -H "Authorization: Bearer inf_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "auto",
    "prompt": "a slate rooftop in the rain, seen from above",
    "n": 1
  }'

Response

The OpenAI shape: data carries one entry per image with a url or a b64_json, plus revised_prompt when the provider rewrote your prompt before generating. The response also names the model that served and adds served_by.

Speech

The response body is the audio itself, so the disclosure other endpoints put in a served_by object rides in headers here: X-Inferbase-Model and X-Inferbase-Vendor. The media type is whatever the provider returned.

This endpoint does not support idempotency replay, because a replayed body would have to be stored as audio.

Request

Example

curl https://api.inferbase.ai/api/v1/inference/audio/speech \
  -H "Authorization: Bearer inf_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{"model": "auto", "input": "The rooftop is wet.", "voice": "alloy"}' \
  --output speech.mp3

Transcription

Multipart, as every OpenAI SDK sends it. Send file and the fields below as form fields.

Example

curl https://api.inferbase.ai/api/v1/inference/audio/transcriptions \
  -H "Authorization: Bearer inf_your_api_key" \
  -F file=@meeting.m4a \
  -F model=auto \
  -F response_format=verbose_json

Response

text is the transcript. Ask for verbose_json and the provider's extra fields ride through untouched, including duration and segments. Ask for anything else and you get the plain shape, even where Inferbase asked the provider for more in order to meter the request. The response shape follows what you asked for, never what we asked the provider for, so it does not change with the credential that served it.

The response also names the model that served.

Speech and transcription share one model type

Both directions are filed under the catalog model_type of audio, so a pool can hold a text-to-speech model and a transcriber at the same time.

Each endpoint drops the models whose stated output contradicts it, so a transcriber the catalog knows produces text is never what auto picks on /audio/speech. A model whose output the catalog does not state stays eligible for both, because excluding it would hide a model that does work on the strength of missing data. Name the model rather than sending auto when a pool holds both directions and one of them is uncatalogued.

Video

Video generation is asynchronous at every provider, so this is three endpoints rather than one: start a job, poll it, download the result.

Example

# Start the job.
curl https://api.inferbase.ai/api/v1/inference/videos \
  -H "Authorization: Bearer inf_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{"model": "auto", "prompt": "rain on a slate rooftop", "seconds": 8}'

# Poll it, using the id the create call returned.
curl https://api.inferbase.ai/api/v1/inference/videos/video_9f2c... \
  -H "Authorization: Bearer inf_your_api_key"

# Download it once status is completed.
curl https://api.inferbase.ai/api/v1/inference/videos/video_9f2c.../content \
  -H "Authorization: Bearer inf_your_api_key" \
  --output clip.mp4

The job

status is one of queued, in_progress, completed or failed. Each provider's own status words are mapped onto those four. A word no provider has been mapped from reads as in_progress, so an unknown state means keep polling rather than a failure. progress is a percentage where the provider reports one, and error carries the provider's message on a failure.

The id is Inferbase's, not the provider's. Store it, because it is what both reads take.

The job stays tied to the credential that started it. Every poll and every download resolves that credential again, so disconnecting the key or cloud account leaves the job unreadable and both reads return 503. A job belonging to another project reads as 404. There is no endpoint that lists jobs, so keep the ids you started.

A poll that cannot reach the provider returns 502 and leaves the job alone. It does not mark it failed, because the generation is very likely still running.

The usage row for a video is written by the poll that first sees the job finished or failed, not by the call that started it. A job nobody polls to a terminal state records no usage.

Downloading before the job finishes returns 409 naming the state, not 404. The video is fetched from the provider on demand through the credential that made it; Inferbase never stores it.

Last updated September 10, 2026.