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

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

Request example

Response schema (immediate)

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

AspectAsyncSync
ImplementationSubmit + pollWait for answer
Latency to response0.1s (submit)5-60s
ScalabilityBetter for high concurrencyLimited by request connections
ComplexityMore code (polling loop)Simpler
Best forBackground jobs, queuesReal-time chat UI