Chat API

A chat API is a set of HTTP endpoints that lets software send, receive and manage chat messages without a person operating a chat window. Instead of a human typing into a widget and pressing send, your code makes an authenticated request to an API endpoint such as POST /messages, and the platform delivers that message on whichever channel the conversation belongs to. Messages travelling in the other direction are pushed to a URL you register, so your system learns about them the moment they arrive instead of asking repeatedly whether anything is new.

Almost every chat API is built as a REST API: predictable resource URLs, JSON request and response bodies, and the standard HTTP verbs for create, read, update and delete. A minority also expose a WebSocket connection for cases where a persistent stream beats a sequence of individual requests — typing indicators, presence, or anything where one round trip per event is too slow to feel live.

The category covers more ground than the name suggests. A chat API might power in-app messaging between two users of a marketplace, a support conversation that starts in a website widget and continues on WhatsApp, an internal alerting channel that posts into Slack, or a chatbot that answers questions and books appointments. What unites them is the same idea: chat becomes something your software can drive, observe and store, rather than a black box a human operates.

The confusion around the term comes from three different products answering to it. A chat API that moves messages, a chatbot API that manages the automation deciding what to say, and a platform messaging API such as the WhatsApp Cloud API or the Telegram Bot API that reaches exactly one network. They overlap, most vendors ship more than one of them, and the marketing rarely distinguishes. The reliable way to tell them apart is to read the endpoint list rather than the product name.

A chat API integration has three moving parts: authenticating, sending, and receiving. Each one fails in its own characteristic way, and knowing which part you are in saves most of the debugging time.

Authentication

Nearly every chat API authenticates with a bearer token sent in an Authorization header — Authorization: Bearer <token>. You generate the token from your account, store it in a server-side environment variable, and never let it reach front-end JavaScript, because a token shipped in a browser bundle is a token anyone can read and reuse. Platforms that let a third party act on someone else's workspace layer OAuth on top, so the user grants scoped access rather than handing over a master key. When every call suddenly returns 401, suspect a rotated or revoked token before you suspect your own code.

Sending messages

Sending is the straightforward half. You POST a JSON body containing a recipient identifier, a message type and the content, and you get back a structured response with a message ID and a status. The complication is that the same call can be rejected at two different layers: by the chat platform itself, and by the underlying channel the message is destined for. A message that your platform accepts happily can still be refused by WhatsApp because the customer service window has closed, and that refusal often arrives later, in a status webhook, rather than in the original response.

Receiving messages

Incoming messages, delivery receipts and status changes arrive through a webhook. You register an HTTPS URL, subscribe to the events you care about, and the provider sends an HTTP POST with a JSON payload the instant one occurs. The alternative — polling an endpoint on a timer — wastes requests, burns rate limit and always lags reality, which is why webhooks are the default in every serious chat API. Providers expect a fast 2xx acknowledgement and will retry with backoff if they do not get one.

These three terms are used interchangeably in search queries and precisely in documentation, which is why the same search returns wildly different pages. The distinction is worth learning because it determines what you can build.

The practical rule: if the endpoints are verbs about messages, it is a chat API. If they are nouns about bots, it is a chatbot API. If the base URL belongs to Meta, Telegram or Discord, it is a platform messaging API and its rules are that platform's rules, not your vendor's.

A real integration usually touches at least two of these rows. You create a bot through a chatbot API, connect it to a channel whose messaging API has its own quotas and windows, and then send and receive through the chat endpoints. Each layer can reject a message for its own reasons, which is why an error you cannot explain is usually an error from a layer you were not thinking about. Per-platform quotas and windows are documented in the platform limits reference, and the numeric codes each platform returns are decoded in the error code reference.

Whatever the vendor, chat APIs are assembled from the same handful of building blocks. Recognising them makes an unfamiliar set of documentation readable in minutes.

• Authentication credentials. An API key, bearer token or OAuth grant that identifies your application and scopes what it may do. Server-side only, rotatable, and the single most common cause of a working integration suddenly breaking.
• Conversation and message resources. The core nouns. A conversation groups messages between participants; a message carries content, a type (text, image, file, template), a sender, a timestamp and a delivery status. Every meaningful operation is a verb applied to one of these.
• Channels. The network a conversation is delivered over — a website widget, WhatsApp, Messenger, Telegram, Slack, SMS. Each channel adds its own constraints on message formats, media sizes and when you are allowed to initiate contact.
• Webhooks and events. The push side of the API. An event is a typed notification (message.received, message.delivered, conversation.closed) delivered to a URL you own, normally with a signature you can verify.
• Rate limits. Caps on requests per second or per window, enforced with HTTP 429 or a platform-specific code. See rate limiting for how backoff and queuing should be built around them.
• SDKs. Thin language-specific wrappers over the HTTP calls. An SDK saves boilerplate, but it also rewrites error messages, so keep the raw response available when debugging.

Two components deserve extra attention during evaluation. First, whether webhooks are included at all or only on higher tiers — a chat API you can only poll is a substantially weaker tool than its documentation implies. Second, whether the API exposes message history, not just sending, because analytics, compliance exports and handover to a human agent all depend on being able to read a conversation back.

Chat APIs turn up in more products than most people realise, usually invisibly. Some representative patterns:

• Marketplace messaging. A buyer and seller exchange messages inside the platform rather than over email. The chat API stores the thread, enforces moderation rules and keeps both parties' contact details private — something no email integration can do.
• Order and delivery updates. An e-commerce backend posts a shipping notification into a live conversation on WhatsApp or Messenger. The customer replies with a question, and the reply arrives at the merchant's system through a webhook instead of an inbox nobody watches.
• Support handover. A chatbot answers routine questions and, when it cannot, uses the API to assign the conversation to a human agent with the full transcript attached. See human handoff for how that transition is designed.
• Multi-tenant provisioning. A SaaS product spins up a separate chatbot for each of its customers automatically at signup, applying that customer's colours and logo through the API rather than by hand.
• Internal alerting. A monitoring system posts incident messages into a Slack or Teams channel and reads the acknowledgement back, turning a chat channel into an operational interface.
• Compliance and analytics exports. A nightly job reads conversations through the API into a warehouse so that response times, deflection rates and satisfaction scores can be measured against everything else the business tracks.

What these have in common is that the chat is not the product — it is a channel between an existing system and a person. That is the signal that a chat API is the right tool. When the chat is the product and nothing else has to talk to it, a hosted platform almost always gets there faster.

Every chatbot that does anything useful sits on top of a chat API in both directions. Inbound, a webhook delivers each user message from the channel to the bot's logic. Outbound, the bot calls a send endpoint to reply. Between those two calls, the bot usually makes further API calls of its own — to a CRM, an order system, a knowledge base — which is what separates a chatbot that answers questions from one that completes tasks.

The chatbot API layer, as distinct from the message layer, is what makes fleets of bots manageable. On Conferbot, the REST API exposes the same objects you manage in the dashboard: the chatbot endpoints list every bot in a workspace, create a new one, fetch a single bot by its ID and delete it; a separate group updates a bot's appearance and uploads or removes the icons it shows in the chat window; and the messaging endpoints send a message into a conversation and update one that has already been sent. Authentication is a bearer token in the Authorization header. Alongside REST, Conferbot ships an MCP (Model Context Protocol) server that exposes the same operations as tools an AI assistant can call directly.

That set covers the automation teams actually ask for: provisioning a bot per customer in a multi-tenant product, keeping branding in sync when a client changes their colours, and pushing a message into a live conversation from a system that is not the chatbot platform. The full endpoint reference and an interactive request builder live on the developer API page, and the wider explainer — including how the choice between an API and a no-code builder plays out — is on the chat API guide.

One caveat worth stating plainly: many chatbot projects never need the API at all. If the requirement is a widget on a website that answers questions, captures leads and hands off to a person, the API is an implementation detail the platform already handles for you.

The failure modes of chat API integrations are remarkably consistent across vendors. These practices address the ones that account for most production incidents.

• Verify webhook signatures against the raw body. Most providers sign the payload with an HMAC. The check must run before any JSON parsing middleware reformats the body, or valid payloads will fail verification for reasons that look impossible.
• Acknowledge fast, process later. Return 2xx immediately and push the work onto a queue. A handler that takes seconds will be retried, and you will process the same event more than once.
• Make handlers idempotent. At-least-once delivery is the norm, not an edge case. Key on the provider's event or message ID and discard duplicates rather than trusting that they will not arrive.
• Build backoff before you need it. Read the retry hint the 429 response gives you, queue rather than drop, and add jitter so a burst of retries does not synchronise into a second burst.
• Log the raw error object, not your wrapper's summary. SDKs rewrite messages; numeric codes survive every layer. Capture the code, any subcode, the request or message ID and a timestamp, then count occurrences per code per hour so a spike is visible.
• Never put a token in the browser. If the front end needs to talk to the chat service, proxy through your own backend or use a short-lived scoped token issued per session.
• Handle the channel's rules, not just the API's. Messaging windows, template approval and per-recipient limits are enforced by the channel and will reject messages your chat API happily accepted.

When events stop arriving entirely, work the causes in a fixed order rather than guessing: unreachable endpoint, wrong subscription, signature mismatch, handler too slow to acknowledge. The webhook debugging guide walks that sequence in detail.

Most searches for a chat API are really a build-versus-buy question in disguise, and the honest answer is that the API is the right tool less often than it feels like it is. A no-code platform covers the common case; the API earns its keep on the specific things a platform cannot express.

Use a platform when the requirement is a chat experience: a widget on a site, a bot on WhatsApp, lead capture, FAQ deflection, booking, handover to an agent. You get channel connectors that are already written and maintained, token refresh and retries handled for you, and non-technical colleagues able to change what the bot says without a deploy. Time to a working conversation is measured in an afternoon rather than a sprint.

Reach for the API when something you own has to drive the chat. Per-tenant provisioning at volume. Logic that must execute inside your own backend for data-residency or latency reasons. A message that has to originate from an ERP or a fulfilment system. Analytics that need raw conversation data in your own warehouse. Those are real requirements a visual builder cannot satisfy, and they are worth the maintenance they bring with them.

A useful ordering before writing any code: if a native connector already exists for the system you want to reach, use it. If there is no connector but both ends are on Zapier, that usually gets you there without deploying anything. Only then does a direct API integration make sense. On cost, expect free tiers across this category to cover the hosted product generously and the API sparingly — a widget costs a provider almost nothing per extra user, while API calls cost money per request — so confirm whether API access and webhooks are included on the plan you are budgeting for before you build against it.