What Is a Chatbot API? Three Layers, Three Bills, and the Limits You Design Around (2026)

Quick answer: A chatbot API is programmatic access to a bot: a URL you send a request to, a key that proves who you are, and a JSON response you do something with. The confusion is that three unrelated products share the label. A model API such as OpenAI's or Anthropic's turns text into text and knows nothing about your customers. A platform API is what a chatbot vendor exposes so your other systems can act on the bot it hosts for you. A channel API belongs to WhatsApp, Telegram, or Messenger and moves the message across the network. You will meet all three on a single project, they are priced on three different meters, and the one your vendor gates behind a higher tier is almost always the middle one.

The three layers

Nothing else in this entry makes sense until this table does. Read it as a stack: the channel is closest to the customer, the model is furthest, and the platform sits between them holding the state.

A worked example makes the stack concrete. A customer messages your WhatsApp number. Meta's WhatsApp Business API receives it and forwards it to your vendor. Your vendor's runtime decides what to do, and if the step needs generated text it calls a large language model through a model API. Your order system, meanwhile, learns the parcel shipped and calls your vendor's platform API to push a notification back down the same path. Three APIs, three bills, one conversation.

flowchart LR
 C[Customer] <--> CH[Channel API<br/>WhatsApp / Telegram / Messenger]
 CH <--> P[Chatbot platform runtime]
 P --> M[Model API<br/>tokens in, tokens out]
 M --> P
 P <-->|platform API| S[Your systems<br/>CRM, orders, billing]
 style P fill:#ffe8cc
 style S fill:#f5f5f5

Figure 1. The stack, with the platform in the middle holding contact state. The double arrow between your systems and the platform is the part this entry is mostly about, because it is the only leg where you choose both ends.

What a call actually looks like

Strip the vocabulary and every platform API works the same way. You send an HTTP request to a documented endpoint. You attach a key in the header so the vendor knows which account you are acting on. You put JSON in the body describing what you want. You get JSON back with a status code attached.

Manychat's public interface is representative and unusually well documented for the category. Its methods split along the ordinary line: GET requests read state, such as fetching a contact's custom fields, while POST requests change it, such as setting a field value or sending content to a named contact. The account key lives in Settings, and there is a second key for profile-level objects like templates, which is the sort of detail that costs an afternoon when you assume there is only one.

Two directions matter, and vendors document the distinction least clearly of anything on this page. A platform API call is outbound: your code initiates, the vendor responds. A webhook is inbound: the vendor initiates when something happens and your server responds. Order shipped, so you call the API. Customer replied, so the webhook calls you. Any integration that only moves in one direction is either polling wastefully or missing events, and the webhook entry covers the receiving side, including signature verification and retry behavior.

Setup time varies more than the documentation suggests, and the two figures we can offer carry different weight. On Botpress we measured the developer path during 11 hours of active paid-tier testing in May 2026: CLI install plus browser OAuth ran under 90 seconds, and the edit-deploy-test loop settled around 15 seconds for small changes. For Chatbase's AI Actions surface, wiring an authenticated Stripe lookup is an anchored editorial estimate of roughly 17 minutes covering authentication, parameter mapping, and the conversational trigger. That second number comes from a projected scenario assessment rather than a stopwatch, and we label it that way because the difference matters to anyone planning a week around it. Take the first as observed and the second as a planning figure. Both point the same direction: on either platform this is configuration work, not construction, which is the whole argument for buying a platform API instead of assembling the stack yourself.

Where API access sits on the price list

This is the layer buyers get wrong most expensively, because "has an API" appears on nearly every feature comparison and the tier it appears on rarely does. Across our own review sessions, API access is frequently a paywall feature and not a baseline one.

Chatbotscape earns affiliate commission on some of the platforms named below. It does not change what we publish, and the tier facts in this table are taken from vendor pricing pages on the dates given. See our affiliate disclosure.

Read that column twice before you build a roadmap on top of a trial account. A prototype that works beautifully on a free plan can require a tier jump of an order of magnitude to reach production, and that jump is not a negotiation, it is a checkout page. The integration guide has the ladder of cheaper options to try first.

The model layer prices differently again, per token and not per plan, which is why a fixed monthly bot budget and a variable model bill do not reconcile without arithmetic. Our LLM API cost calculator and the OpenAI pricing calculator exist for that reconciliation, and the BYOLLM entry covers when you hold the model key yourself instead of renting the vendor's.

The limits that actually shape your design

Rate limits sound like an operations concern and behave like a design constraint. They decide whether your idea is possible before they decide whether it is fast.

Channel throughput. Meta's documentation puts default Cloud API throughput at 80 messages per second per business phone number, upgradable to 1,000 for numbers that qualify. Telegram publishes tighter numbers in its Bots FAQ: roughly 30 messages per second for bulk sends, one message per second within a single chat, and no more than 20 per minute into a group, with 429 errors past those thresholds. Telegram's paid broadcast route lifts the ceiling to 1,000 per second, priced at 0.1 Stars per message above the free 30 per second, and it requires a balance of 100,000 Stars and 100,000 monthly active users to switch on. That last requirement quietly excludes almost every small business, so a broadcast to a large Telegram audience is a scheduling problem rather than a purchasing one.

Platform ceilings. Vendor limits are lower and less visible. Manychat documents a fixed 10-second timeout on external requests that cannot be changed, a 2,000-character cap on request URLs, and HTTPS-only endpoints. It also documents something more consequential than any of those: if a dynamic block request fails and no fallback content is configured, the rest of the automation stops. The customer is left mid-conversation with no message and no error, which is a failure mode you find in a support ticket rather than a dashboard.

Response mapping. The same documentation notes that only JSON responses can be mapped into contact fields, and that non-200 responses cannot be mapped at all, so you cannot branch a flow on a specific error code. Your integration therefore has exactly two states from the bot's point of view: it worked, or it did not. Anything more nuanced has to be handled by your own server before the response ever comes back.

Design to those numbers, not around them. An endpoint that answers in eight seconds on a good day will silently break a Manychat flow on a bad one, and the fix is a fast acknowledgment plus a later push through the platform API, not a faster database.

What an API will not do for you

Programmatic access is narrower than it sounds, and the gaps are consistent across vendors. Most platform APIs let you act on conversations and contacts. Far fewer let you build or edit the bot itself, so flow logic stays in the visual editor where a human drew it. Knowledge sources usually sit behind their own upload interface rather than an endpoint, which the knowledge base entry covers. And nothing in any of these APIs changes what the channel permits: WhatsApp's template rules and messaging windows apply identically whether a human or a script sent the message.

There is also a newer path worth separating from this one. The Model Context Protocol standardizes how an AI agent reaches tools and data at runtime, which is a different question from how your CRM pushes a record into a bot. A vendor can ship an MCP server and still gate its REST API behind a higher tier. SendPulse does both, running an MCP server alongside the REST surface it sells with paid plans.

How to read a vendor's API claim

Four questions turn a checkmark on a comparison table into something you can plan against. Ask them in a demo, in this order, and ask to see the screen instead of settling for the answer. These are the specification questions; the operational ones, the checks you can only make by watching the product move, are in the integration guide's demo-day script.

• Which tier, exactly? Not "do you have an API" but "on which plan does it turn on, and what does that plan cost billed monthly." Our pricing methodology explains why the monthly figure is the one to compare.
• Read, write, or both? An API that reads contacts but cannot send a message solves half a problem, and it is usually the half you already had covered.
• What are the documented limits? Rate, timeout, payload size. A vendor that cannot produce these numbers has not been asked for them by anyone building at scale.
• What happens when a call fails? Ask specifically whether the conversation continues, halts, or falls back, then ask to see that behavior in a live flow.

Then look at the documentation itself for thirty seconds. Public, versioned, with a request and response example per endpoint is a working developer surface. A support article describing an API is a plan to build one.

Related terms

• Webhook — the inbound half of the same conversation, and the one your server has to receive.
• WhatsApp Business API — the channel layer most SMB integrations actually run on.
• Telegram bot — the channel with the most permissive setup and the tightest broadcast ceiling.
• Large language model — what the model layer of the stack is calling.
• BYOLLM — holding the model key yourself instead of renting the vendor's.
• Model Context Protocol — the agent-to-tool standard, distinct from the vendor REST API described here.

FAQ

What is a chatbot API in simple terms?

A set of web addresses your software can call to make a bot do something, plus a key that proves the call is yours. Instead of a person opening the dashboard and clicking send, your order system sends a request and the message goes out. The same interface usually works in reverse through a webhook, so the bot can notify your systems when a customer replies.

Is a chatbot API the same as an AI or LLM API?

No, and the giveaway is what each one remembers. An LLM API is stateless: it has no idea who your customers are or which conversation it is in, and anything it appears to remember was re-sent in the request. A chatbot platform API is the opposite, built almost entirely around state it holds for you, which is why its endpoints are named after contacts and conversations rather than after completions.

Is there a free chatbot API?

The phrase points at two different things, which is why the search results are confusing. Free model APIs are common: providers and open-weight hosts run free or trial tiers you can build against immediately, metered by tokens. Free platform APIs are rare, because the platform API is the thing vendors charge for. The tier table above has the specifics for the platforms we have reviewed. If you want to prototype at zero cost, the realistic combination is a model API's free tier plus a platform that exposes at least a limited API on its free plan, which in our review set means SendPulse.

What is the difference between a chatbot API and a webhook?

Direction, and the practical consequence is where you can build. An API call you can test from your laptop with any HTTP client before a single line of production code exists. A webhook cannot be tested that way, because the vendor has to reach you: you need a public HTTPS endpoint with a valid certificate, and Telegram additionally restricts webhooks to ports 443, 80, 88, and 8443, rejects redirects, and requires the certificate's common name to match the domain exactly. Plan the inbound half first, since it is the half with infrastructure attached.

Do platform API calls eat my message credits?

Sometimes, and it is worth asking before you build a polling loop. Reads generally do not, but any call that results in a message reaching a customer is a message on your plan's meter, whether a person or a script triggered it. That matters most on credit-metered plans, where an integration that pushes a status update per order can consume a monthly allowance faster than the conversations it was meant to reduce. Ask the vendor which endpoints are billable and get the answer in writing.

Can I build a whole chatbot with just an API?

Yes, and most SMBs should not. A model API plus your own server gives you total control over behavior, data, and cost, and it also gives you responsibility for channel approvals, contact storage, retries, and the on-call rotation when the webhook endpoint goes down at midnight. The platforms we review exist to hold that responsibility. Choose the build when your requirements genuinely fall outside what a platform can express, and see the integration guide for the cheaper rungs to rule out first.

Sources

• Telegram. Bots FAQ — per-chat, per-group, and broadcast limits, paid broadcast terms, and webhook requirements. core.telegram.org/bots/faq (read 3 August 2026).
• Meta. Throughput, WhatsApp Business Platform documentation — default 80 messages per second per business phone number with an upgrade path to 1,000. developers.facebook.com (checked 3 August 2026).
• Manychat. Dev Tools: Basics — paid-plan gating, API key locations, the fixed 10-second timeout, the 2,000-character URL cap, JSON-only response mapping, and fallback behavior when a request fails. Vendor article last updated 3 December 2025. help.manychat.com (read 3 August 2026).
• Manychat. Public API reference. api.manychat.com/swagger (referenced 3 August 2026).
• Chatbotscape platform reviews, first-party sessions: Chatbase (Standard tier API access, pricing page verified 26 May 2026), Tidio (OpenAPI on Plus, 26 May 2026), SendPulse (REST API and webhooks on paid plans, limited on free, 26 May 2026), Manychat, Botpress (public API reference and CLI, 26 May 2026), Typebot (HTTP request block and self-host, 26 May 2026).
• Chatbotscape evaluation methodology. /methodology (continuously updated).