> ## Documentation Index
> Fetch the complete documentation index at: https://docs.glot.com/llms.txt
> Use this file to discover all available pages before exploring further.

# API and streaming

> The two halves of Glot: a REST API you call to set a call up, and a realtime session you stream audio through

Glot has two parts, and a single translated conversation uses both. The **API** sets the
call up and accounts for it. **Streaming** is where the translation actually happens.

<CardGroup cols={2}>
  <Card title="The API" icon="code">
    HTTPS requests with your API key. Provision rooms, issue join credentials, and read
    back what a call cost. Carries no audio.
  </Card>

  <Card title="Streaming" icon="microphone-lines">
    A live WebRTC session. Your microphone goes up, translated audio and a live transcript
    come back. Carries no configuration.
  </Card>
</CardGroup>

## The API — set a call up, then account for it

Use it for everything around a conversation:

* **Create a room** — a live translation session, and the record it will be billed under.
* **Mint a join token** for each participant, in the languages they speak. Tokens are
  short-lived, so this is a call you make per participant, per session.
* **Close a room** when the call is over, rather than waiting for it to end on its own.
* **Read usage** — rooms, per-participant connected minutes, and what each one cost.
* **Manage API keys and prepaid credit**, and list the languages Glot translates between.

Every request is authenticated with an API key as a bearer token:

```bash title="cURL" theme={null}
curl https://api.staging.glot.com/v1/supported-languages \
  -H "Authorization: Bearer $GLOT_API_KEY"
```

Keep your API key on your server. What reaches a browser or a phone is the join token the
API mints for it, never the key itself.

## Streaming — where the translation happens

A participant joins a room with their token, and from there audio is carried over WebRTC
rather than over the API. During the session:

* Your microphone audio streams up to the translator.
* Translated audio comes back as **one track per language**, so a client plays the
  language it joined in.
* A **live transcript** arrives as text frames — each utterance first as it is being
  produced, then again as confirmed text with the speech it came from.

The translator joins the room on its own once the room holds two languages, and leaves
when fewer than two remain. There is nothing to dispatch and nothing to configure
mid-call: how the audio arrives is decided when the room and its first token are created.

<CardGroup cols={2}>
  <Card title="Stream your first session" icon="rocket" href="/translation_and_streaming">
    The whole flow end to end — rooms, tokens, audio, and rendering the transcript.
  </Card>

  <Card title="Browse the API" icon="terminal" href="/api-reference/rooms/create-a-translation-room">
    Every endpoint, with its parameters and responses.
  </Card>
</CardGroup>