Overview
The asynchronous chat endpoint accepts a message and returns immediately with arequest_id. Your application then polls the status endpoint until the answer is ready.
Use this when your integration uses background job patterns, message queues, or webhooks to handle results asynchronously.
When to use async chat
- Your application already uses job or queue processing
- You want non-blocking request handling
- You expect high concurrency or spike traffic
- You prefer polling over waiting for a 60-second response
- You want to decouple request submission from result handling
Authentication
This endpoint requires an API key in theX-API-Key header:
Request body
The user’s question or statement. Required.
A stable identifier for the conversation. If omitted, a new session is created.
The user’s email address. Required when creating a new session. Optional for follow-up messages.
The AI model to use. Defaults to the site’s configured model or
gpt-4o-mini.Language for the response (e.g.,
en, tr, es).Locale code for UI context (e.g.,
en-US, tr-TR).Request example
Response schema (immediate)
A unique identifier for this chat request. Use it to poll the status endpoint.
The session identifier for this conversation.
Always
pending on the initial response.An optional placeholder message to show the user while processing.
Response example
Polling the status
After receiving the initial response, poll the status endpoint to check completion:Complete workflow example
Error responses
Same error codes as sync chat:400: Invalid request401: Authentication failed403: Plan does not include M2M API404: Site not found429: Rate limited500: Server error
Polling strategy
Recommended polling approach:- Initial poll: Wait 1-2 seconds before first status check
- Polling interval: Check every 1-2 seconds
- Timeout: Stop after 2-5 minutes (typical completion is 5-30 seconds)
- Backoff on failure: If status endpoint returns 5xx, implement exponential backoff
Comparison: async vs sync
| Aspect | Async | Sync |
|---|---|---|
| Implementation | Submit + poll | Wait for answer |
| Latency to response | 0.1s (submit) | 5-60s |
| Scalability | Better for high concurrency | Limited by request connections |
| Complexity | More code (polling loop) | Simpler |
| Best for | Background jobs, queues | Real-time chat UI |
Related endpoints
- M2M Chat (Sync) — Blocking alternative
- M2M Chat Status — Poll request status
- M2M Chat Feedback — Submit quality feedback
- M2M Sessions — List conversations