m8ty_client_chat
Package overview
m8ty_client_chat solves this by connecting the app to server-managed, streaming AI chat. Customers receive conversational help while the server retains responsibility for prompts, authorized tools, and response generation.
The m8ty_client_chat package connects Flutter applications to the m8ty AI Chat endpoint. The client sends the user-visible conversation history; the m8ty server owns the system prompt, LLM configuration, MCP tool discovery, tool execution, and final response generation.
Before you start
Check the API documentation for the generated classes and models. The package source is available in the m8ty_client_chat GitLab project.
Add the package to the application and import the client:
Client setup
The default base URL is https://api.m8ty.eu/api/v1. Configure the user's OAuth token before every request:
Use basePathOverride for non-production environments:
Do not put access tokens, cookies, raw tool payloads, or hidden instructions in message content or logs.
API surface
AiChatApi
Method | Description |
|---|---|
| Sends chronological conversation history to |
The generated streamAiChat() method buffers the response into a string. Use it when the complete SSE transcript is sufficient. For incremental UI updates, use the package client's exposed Dio instance with ResponseType.stream, as shown below.
Request model
AiChatRequestModel contains a required messages list. Each AiChatMessageModel has:
Field | Type | Description |
|---|---|---|
|
|
|
|
| Non-blank natural-language text visible to the user |
Send messages in chronological order. The latest message should normally have the user role. Do not send system, developer, or tool messages; the server creates and manages those internally.
Receive the complete response
Stream incremental updates
For a token-by-token chat UI, serialize the generated request model and request a streamed Dio response. The secure metadata keeps the generated OAuth interceptor active.
Keep the CancelToken with the active request so the UI can stop generation when the user leaves the chat or taps a cancel action.
SSE events
The response uses text/event-stream:
Event | Client behavior |
|---|---|
| Append the |
| Treat as server-side tool progress; do not execute the tool on the client |
| Mark the assistant response as complete |
| Stop processing and show an appropriate error state |
An HTTP 200 only confirms that the stream was opened. The stream can still end with an error event, so always handle both HTTP failures and SSE errors.
Conversation ownership
The server does not own the client conversation history. The application should:
Store only user-visible
userandassistantmessages.Send the relevant history in chronological order with every request.
Append content deltas to a pending assistant message.
Persist that assistant message only after a successful
doneevent.Exclude incomplete responses after cancellation or an error.
The client must not discover or call MCP tools for this chat flow. The server selects and executes tools using the authenticated user context.