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

# API reference

> Generated from the same Zod schemas that validate every request.

These pages are generated from `openapi.json`. That document is generated from the Zod schemas
that validate each request at runtime, so the reference cannot drift from the server. Read
[The API contract](/concepts/api-contract).

## Use the playground

The playground sends a real request to the server that you select.

<Steps>
  <Step title="Select the server">
    Production is `https://client-api.lala.ist`.
  </Step>

  <Step title="Paste a Supabase access token">
    Put the raw token in the bearer field. The playground adds the word `Bearer` for you.
    In your own client, send the full header: `Authorization: Bearer <token>`.
  </Step>

  <Step title="Send the request">
    Every call runs against real student data. Use a test account.
  </Step>
</Steps>

<Warning>
  The playground cannot render the response of `POST /api/chat/send`. That response is a
  Server-Sent Events stream. Use `curl -N`, or the client code on
  [Stream a chat answer](/guides/chat-streaming).
</Warning>

## Language

The whole document is English: operation summaries, response descriptions, schema names, field
names, and error strings. Turkish appears only in the content that a student reads, which is the
chat text.

## Schema names

A generated client gets these classes:

| Schema                                                              | Where                            |
| ------------------------------------------------------------------- | -------------------------------- |
| `MeResponse`, `StudentProfile`                                      | `GET /api/me`                    |
| `ProfilePatchBody`, `ProfileResponse`                               | `PATCH /api/profile`             |
| `ChatSendBody`                                                      | `POST /api/chat/send`            |
| `ChatHistoryResponse`, `ChatMessage`                                | `GET /api/chat/history`          |
| `ChatChunkEvent`, `ChatDoneEvent`, `ChatErrorEvent`, `ChatReaction` | the SSE payloads                 |
| `ErrorResponse`                                                     | every `4xx` from a route handler |
| `HealthResponse`                                                    | `GET /health`                    |

The three SSE event models have no endpoint of their own. They are registered so that a generated
client holds the payload classes. Read them together with the framing rules on
[Stream a chat answer](/guides/chat-streaming).