Skip to main content

Overview

The asynchronous chat endpoint accepts a message and returns immediately with a request_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
For immediate synchronous answers, use sync chat.

Authentication

This endpoint requires an API key in the X-API-Key header:
The API key must belong to a tenant that owns the specified site.

Request body

string
required
The user’s question or statement. Required.
string
A stable identifier for the conversation. If omitted, a new session is created.
string
The user’s email address. Required when creating a new session. Optional for follow-up messages.
string
The AI model to use. Defaults to the site’s configured model or gpt-4o-mini.
string
Language for the response (e.g., en, tr, es).
string
Locale code for UI context (e.g., en-US, tr-TR).

Request example

Response schema (immediate)

string
A unique identifier for this chat request. Use it to poll the status endpoint.
string
The session identifier for this conversation.
string
Always pending on the initial response.
string
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:
Example:

Complete workflow example

Error responses

Same error codes as sync chat:
  • 400: Invalid request
  • 401: Authentication failed
  • 403: Plan does not include M2M API
  • 404: Site not found
  • 429: Rate limited
  • 500: Server error

Polling strategy

Recommended polling approach:
  1. Initial poll: Wait 1-2 seconds before first status check
  2. Polling interval: Check every 1-2 seconds
  3. Timeout: Stop after 2-5 minutes (typical completion is 5-30 seconds)
  4. Backoff on failure: If status endpoint returns 5xx, implement exponential backoff
Example adaptive polling:

Comparison: async vs sync