Skip to main content
This page collects the lookup tables shared by Live Chat channel, Mobile SDK and API integration.

Error codes

Every error from the Visitor API and the history API comes back in the same shape. code is a string, not a number - branch on it, never on message. The HTTP status is on the status line and is not repeated in the body. For 5xx errors, message is always a fixed sentence; the real cause goes into the platform log. For 4xx errors, message is written for you to read and is worth displaying.

API channel - inbound message webhook

Live Chat - Visitor API

Several 404 codes deliberately cover more than one cause. CONNECTION_NOT_FOUND covers four cases, and ARTIFACT_NOT_FOUND covers both a missing file and one the caller has no rights to. That is by design, so nobody can probe which resources exist.

Console - channel configuration

System limits

API channel - inbound

API channel - callbacks

Live Chat

Organisation-wide quotas

Pre-production checklist

Live Chat channel

  • The channel configuration has been saved at least once and you have the embed snippet.
  • The snippet sits before the closing </body> tag, data-connection-key is correct, and data-app-origin still carries the /chat-widget/ path.
  • Tested on a phone, not only on a desktop.
  • If you use the mobile app: the device locale is passed, since the SDK does not read the default language from Console.
  • If you build your own interface: your domain is on the allow list, and you do not call with credentials: "include".

API channel

  • Messages go to the webhook host taken from Console (https://console-agents.fpt.ai/webhooks/api), not the application host.
  • The secret is in a secret store, not in source code or a config file committed to git.
  • Servers are clock-synced with NTP. More than 5 minutes out and every packet is rejected.
  • The signing function uses the raw bytes of the body, not a re-serialised version.
  • Signatures are compared with a constant-time function.
  • messageId is your own stable identifier and stays the same across retries.
  • The webhook returns 200 immediately and processes asynchronously. Each call has only 10 seconds.
  • The webhook handles the type == "verification" branch and echoes challenge.
  • Test callback has been run from Console and passed.
  • Deduplication on eventId is in place.
  • conversationId is stored from every callback, including the delivery acknowledgement.
  • A reconciliation loop over the history API compensates for failed callbacks.
  • A dedicated API key exists for reading history and is stored safely.
  • 429 is handled by reading the Retry-After header.
  • 503 is handled by retrying with backoff, and is not treated as a rejected message.