Chat API: what it is, how it works, and when you actually need one

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, your code makes an authenticated request to an API endpoint such as POST /messages, and the platform delivers the message on whatever channel is attached to that conversation. Messages arriving in the other direction are pushed to a URL you register, so your system finds out about them the moment they happen rather than by polling.

Almost every chat API is a REST API: predictable URLs, JSON request and response bodies, and 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 requests - live typing indicators, presence, anything where a round trip per event is too slow.

The reason this term is confusing is that three different products answer to it. A chat API that moves messages, a chatbot API that manages the automation behind them, and a platform messaging API like the WhatsApp Cloud API that only reaches one network. They overlap, most vendors ship more than one of them, and the marketing rarely distinguishes. The table below does.

Read the endpoint list, not the product name. 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.

In practice a working integration touches at least two rows. You create the bot through a chatbot API, connect it to a channel whose messaging API has its own quotas, and then send and receive through the chat endpoints. The per-platform quotas live in the platform limits reference.

1. 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, keep it in a server-side environment variable, and never let it reach front-end JavaScript, because a token in a browser bundle is a token anyone can read. Larger platforms layer OAuth on top when a third party needs scoped access to someone else's workspace. Rotate on exposure, and treat a sudden wall of 401s as a rotated or revoked token before you suspect your own code.

2. Requests and rate limits

Sending is the easy half: a JSON body with a recipient, a message type and content, posted to a send endpoint. The half that bites is rate limiting. Every provider caps requests per second and most consumer channels add a second layer of their own - per-recipient windows, daily send tiers, template quotas. Build backoff in from the start rather than after the first incident: read the retry hint the response gives you, queue rather than drop, and log the numeric code so a spike is visible in your own metrics.

3. Events and webhooks

Incoming messages, delivery receipts and status changes arrive through a webhook: you register an HTTPS URL, subscribe to the events you want, and the provider POSTs a JSON payload the moment one occurs. Three rules cover most of the pain. Verify the signature against the raw request body before any parsing middleware touches it. Acknowledge with a 2xx immediately and do the real work on a queue, because a handler that takes seconds will be retried and you will process the same event twice. And make the handler idempotent, because at-least-once delivery is the norm, not an edge case.

This is the decision most people are really making when they search for a chat API. 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, and the API earns its keep on the specific things a platform cannot express.

A useful ordering: if a native connector already exists for the system you want to reach, use it - the full list is under integrations. If there is no connector but both ends are on Zapier, that usually gets you there without deploying anything. Reach for the API when you need per-tenant provisioning at volume, logic that has to execute inside your own backend, or latency a scheduled automation cannot meet. That framing is expanded on the API integration feature page.

"Free chatbot API for website" is a query with a gap between what people expect and what the market offers, so it is worth being blunt. Free tiers across this category are generous about the product and careful about the API, for a structural reason: a chat widget costs a provider almost nothing per extra user, while API calls cost real money per request and are trivially easy to abuse. Expect the free plan to cover the builder, the widget and a monthly conversation allowance; expect API keys, higher rate limits and webhook fan-out to sit behind a paid tier.

Three things are worth checking before you commit to any of them. Whether the free tier includes API access at all or only the hosted product. Whether there is a hard rate limit or a soft one that silently queues. And whether webhooks are included, because a chat API you can only poll is a much weaker tool than the docs make it sound.

On Conferbot specifically: the free plan is free forever and covers building and running a chatbot - one bot, a monthly conversation allowance, the widget, live agent handoff and analytics - with no card required. Programmatic API access sits on the paid tiers; the pricing page carries the current split, and it is the thing to read rather than this sentence if you are budgeting. If you only want to try the mechanics without spending anything, the free developer tools include a Telegram bot token checker and a WhatsApp template checker that exercise real platform APIs.

The REST API exposes the same objects you manage in the dashboard, so anything you can set up by hand can be scripted. 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 controls presentation: updating a bot's appearance, and uploading or removing the icons it shows in the chat window. 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.

Webhooks handle the other direction - your endpoint receives events as they happen instead of you polling for them. Alongside REST, Conferbot ships an MCP (Model Context Protocol) server that exposes the same operations as tools an AI assistant can call directly, which is the shorter path if you would rather ask an assistant to provision a bot than write the HTTP call yourself.

That set covers the automation people 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 Conferbot - an order-status update from an ERP, a shipping notification from a fulfilment tool. The endpoint reference and an interactive request builder live on the developer API page and in the documentation.

Most chat API failures are not bugs in your code - they are the platform underneath saying no, in its own vocabulary. Start with the status code and the platform error object rather than your wrapper's summary, because SDKs rewrite the message and the numeric code survives every layer. The error code reference decodes what WhatsApp, Telegram, Discord and the rest return, one page per code, with the cause and an ordered fix. If calls fail only sometimes, check the platform limits reference - rate caps, messaging windows and template quotas produce failures that look random until you know the number you are hitting. And if events simply never arrive, the webhook debugging guide works the causes in order: unreachable endpoint, wrong subscription, signature mismatch, handler too slow to acknowledge.

• API endpointDefinition, structure, examples
• WebhookPush vs poll, signatures, retries
• REST APIVerbs, resources, status codes
• Developer API & MCPEndpoints, auth, request builder
• API integration featureWhere the API sits in the product
• Native integrationsUse a connector before writing code
• Chatbot API rate limitingBackoff, queues, 429s in practice
• Free developer toolsToken and template checkers

Try the product before you write the integration

Build a chatbot in the visual editor, put it on your site, and only reach for the API once you know what the flow needs to do.