How to Integrate a Chatbot
Four Rungs, and Why Most Small Businesses Should Stop at Two (2026)
Quick answer: Integration means your bot can reach a system that holds the answer. There are four ways to do it, in ascending order of cost and control: a native connector your vendor built, a no-code bridge such as Zapier or Make, an HTTP or webhook block you configure yourself, and a custom build against the platform API. Nearly every small business should start at rung one and stop at the first rung that works. The expensive mistake is not choosing the wrong rung. It is connecting six systems because they were available, then finding out eight months later that two of them quietly stopped working.
Our glossary entry on chatbot APIs covers the three layers that share the name, where API access sits on each vendor's price list, and the published rate limits. This page assumes you have read none of that and want to connect a bot to the system your customers keep asking about.
Start with two questions, not a list of tools
Before you open an integrations directory, answer these. They take ten minutes and they eliminate most of what the directory will suggest.
What does the customer ask that the bot cannot currently answer? Pull a fortnight of real conversations and count. Not the questions you imagine, the ones that are there. In practice this collapses into a short list: where is my order, what did I pay, when is my appointment, can someone call me back. Each one names exactly one system.
What would the bot have to do, read or write? Reading is cheap and safe. Writing is neither. A bot that reads order status needs one credential with one permission and cannot damage anything if it misbehaves. A bot that issues refunds needs an approval path, an audit trail, and a much harder conversation with whoever owns that system. Our security and PII guide covers scoping; the point here is that read and write integrations are different projects with different timelines, and merging them into one ticket is how the whole thing stalls.
The four rungs
Rung one: a native connector. Your vendor built and maintains it. You click, authorize, and it works. This is the correct default and the only rung where somebody else owns the breakage. The catch is coverage, and coverage is uneven in ways that are hard to predict from marketing pages. From our own review sessions: Tidio has a deep native Shopify integration and a native WordPress plugin, while Telegram is third-party only. Manychat lists Mailchimp, ActiveCampaign, Kit, HubSpot, Klaviyo, Google Sheets and Hotmart natively, and pushes Shopify, Stripe and Calendly through Zapier or Make. Chatbase covers Stripe, Zendesk, Salesforce, Slack, Notion and Calendly natively, with HubSpot and Shopify arriving via Zapier. Check the specific tool, not the count.
Rung two: a no-code bridge. Zapier, Make, or the equivalent sits between two systems that do not know each other. This rung is underrated by technical teams and overused by everyone else. It is the right answer when the trigger is infrequent and latency does not matter: writing a completed conversation into a spreadsheet, creating a CRM record after a qualified lead. It is the wrong answer inside a live conversation, because you are now waiting on a third service to respond before your customer sees anything. Availability is broad in our review set and worth checking anyway, since it is how several platforms reach the tools their native lists skip: Manychat routes Shopify, Stripe, and Calendly this way, Chatbase reaches HubSpot and Shopify the same way, and Tidio uses it for Telegram. When a vendor says it integrates with a tool, this is often the rung they mean.
Rung three: an HTTP or webhook block. Most flow builders ship one. You give it a URL, headers, a body, and a mapping from the response back into contact fields. No code, but you do need to understand what a JSON path is. Typebot builds its whole integration story around this block, which is why it reaches services no vendor list mentions, and it pairs with genuine bring-your-own-key model access for the same reason. Manychat splits the idea in two, with an external request for calling out and a dynamic block for fetching message content to send back, and gates both behind a paid plan. SendPulse ships an API-request block and webhooks on its Pro tier and documents limited API access on its permanent free plan, which makes it the cheapest place in our set to get near this rung without paying first. This is where most SMB integrations should end.
Rung four: a custom build against the platform API. Your code calls the vendor, the vendor's webhook calls your code, and you own both ends. Reserve this for the case where the integration is your product and not a convenience: real-time inventory, regulated workflows, anything where a spreadsheet in the middle is not acceptable. Budget for the tier, since API access is frequently gated above the plan you prototyped on, and budget for someone to maintain it.
| Rung | Build effort | Who fixes it when it breaks | Use it when |
|---|---|---|---|
| Native connector | Minutes | Your vendor | The tool you need is on their list |
| No-code bridge | An afternoon, plus a subscription | You, with a vendor-shaped safety net | The action happens after the conversation ends |
| HTTP / webhook block | An afternoon, plus a mapping you will revisit | You | The service exists but nobody built a connector |
| Custom API build | A developer week, plus the plan tier | You, forever | The integration is the product |
The rungs are not a maturity model. A business running three native connectors and one HTTP block is not behind a business running a custom build. It is usually ahead, because it has less to keep alive.
Sequencing, when you have more than one
Do them one at a time, in the order the conversation count gave you, and leave two weeks between each. The reason is diagnostic rather than cautious: when two integrations ship together and the bot starts behaving oddly, you have no clean way to attribute it, and you will spend longer bisecting than you saved by parallelizing.
Ship each one behind a narrow trigger first. One intent, one flow branch, one customer segment if your platform supports that. Watch it for a week with the QA regression set you should already be running, then widen. The widening step is where most of the value arrives and it costs nothing once the plumbing works.
Where these break, and why you will not notice
This is the section that matters, and it is missing from most integration documentation because vendors write about the happy path. One of the four below we hit ourselves. The other three are patterns we describe from platform behavior and vendor documentation, not incidents we have logged, and each says so where it appears.
Silent credential drift. During our Manychat review we hit this in its purest form. A Telegram channel that had worked was connected to a bot left idle for roughly four months. The token registration on Telegram's side had drifted, so the platform received no events. The Manychat channel toggle still read "Enabled." There was no warning banner, no webhook health indicator, no error anywhere in the interface. The visible symptom was zero contacts and an empty inbox, which is indistinguishable from a quiet week. Recovery meant revoking the token through Telegram's BotFather, generating a new one, and reconnecting the channel. Messages sent during the broken window were not replayed, and they never will be.
That incident generalizes. Any credential can expire, be rotated by whoever owns the other system, or be invalidated by a permission change three departments away, and most chatbot platforms report the result as silence instead of as an error. We have observed the failure on one platform and one channel; we have not audited how the others surface it, which is exactly why the canary below is worth an hour.
Sandbox credentials reaching production. Payment processors, shipping providers, and most CRMs issue test keys alongside live ones, and they answer politely to both. A flow built against a test key works perfectly in every rehearsal and returns fictional data to real customers. Nothing in the chatbot platform can detect this, because from its side the call succeeded. The countermeasure is procedural: name the key in the field description, and make the first live conversation one you run yourself against a record you can verify.
Schema drift on the other side. Your mapping pulls order_status out of a JSON response. Eight months later the other system's release notes rename it, and your mapping now writes an empty value into a contact field. The bot does not error; it says nothing where it used to say something. Nobody who reads release notes for that system is watching your chatbot, and nobody watching your chatbot reads those release notes. This gap is organizational rather than technical, which is why it survives so long.
Limits that only appear at campaign volume. Integrations tested one conversation at a time meet their ceiling the first time a broadcast fires, when a fortnight of calls arrives in ninety seconds. The channel and platform ceilings are published, and our chatbot API entry collects the numbers alongside the vendor-documented timeout and error-mapping behavior your flow inherits. Read them before the campaign, because the failure looks like a successful send with missing replies.
What it costs to keep, not to build
Build cost is the number people estimate, and it is the smaller of the two. The rung table above has it. The number nobody puts in the plan is what happens after.
Maintenance scales with the count of connections, not their complexity, which is counterintuitive enough that it catches people who have built harder things. Every integration is a standing commitment to notice when the other side changes: an API version deprecated, a field renamed, a credential rotated, a plan downgraded. Our working estimate, offered as a planning heuristic and not as measured data, is that three connections stay comfortable at about an hour of attention a quarter, while ten stop being a background task and become part of somebody's job description.
So the honest comparison is not integration cost against zero. It is integration cost against the staff time the integration removes, on your own numbers, which is the calculation in our ROI quick math and the ROI calculator. An order-status lookup that deflects 60 conversations a week at four minutes each is four hours of recovered time weekly, and it justifies real effort. A calendar sync that fires twice a month does not, however satisfying it is to switch on.
One more line item that surprises people: integrations are among the heaviest things to carry through a platform change. Our 14-day migration playbook puts channel re-connection first as the step that stretches a timeline, since moving a WhatsApp number between Business Solution Providers has approval windows nobody on your side controls. Deep integrations to a CRM, a payment processor, or a handoff routing rule come next, and they need end-to-end retesting on a real conversation before cutover. Flows export; credentials do not. Every connector you add raises your switching cost, which is worth knowing while you are still choosing.
The demo-day script
Five things to make a vendor demonstrate, with your own hands on the trackpad. These are deliberately operational: the specification questions about tiers, read-and-write scope, and documented limits belong to the chatbot API entry, which has them as a checklist. What follows is what you can only learn by watching the product move.
Show me this specific tool, connected. Name your CRM, not a category. "We integrate with CRMs" and "we have a native HubSpot connector" are different products.
Open a conversation where an integration ran. You are looking for whether the log shows the call, the payload, and the response, or only the reply the customer got. Debugging without the first three is guesswork.
Break it on purpose. Ask them to point an HTTP block at a URL that returns an error and show you what the customer sees. This one question predicts more production pain than the rest combined.
Show me the credential screen. Where do keys live, who can see them, what happens when one expires, and does the platform tell anyone. Ask specifically whether test and live keys are visually distinguishable once saved.
Rebuild one in front of me. Ask the sales engineer to delete a working connector and set it up again while you time it. You learn the real setup path, the permissions it asks for, and whether the smooth demo depended on preparation you will not have.
A note on independence: Chatbotscape earns affiliate commission on several of the platforms named on this page. Our review sessions are run on accounts we pay for or on free tiers we open ourselves, and we publish the tier limits vendors would rather bury. See the affiliate disclosure.
Platform choice follows from the answers, not the feature grid. If you have not shortlisted yet, our best chatbot platforms for small business list ranks the options we have tested, and the channel-specific guides for adding a bot to your website and connecting Shopify cover the two integrations most SMBs do first.
Frequently asked questions
What does chatbot integration actually mean?
Connecting your bot to a system that holds an answer it does not have: a CRM, an order database, a calendar, a payment processor. The word covers both directions, which is why vendors can use it loosely. A bot that reads your order table looks identical to a customer as one that writes into your CRM, but the second needs approval paths and an audit trail that the first does not. When a vendor says "integrates with," ask which direction they mean before you ask which mechanism.
Which integration should I build first?
Whichever one answers the question your customers ask most, which you find by counting a fortnight of real conversations instead of guessing. For most SMBs that is order or appointment status, and it is a read-only lookup, which is the cheapest and safest kind to start with.
Do I need a developer to integrate a chatbot?
For rungs one and two, no. For rung three you need someone comfortable reading JSON and mapping a response field, which is a skill an operations person can pick up in an afternoon. Rung four is a build and needs a developer, including for the maintenance nobody budgets for.
Is Zapier good enough, or do I need a real API integration?
Zapier and Make are genuinely good enough when the action happens after the conversation: logging a lead, creating a ticket, updating a sheet. They are the wrong tool inside a live conversation, because the customer is waiting while a third service responds. If a customer is watching a typing indicator, use a direct HTTP call.
My integration stopped working. What do I check, in what order?
Credentials first, because they fail most often and most silently. Then the response body, since a renamed field turns a working mapping into a blank answer without raising an error. Then volume, in case you crossed a rate ceiling during a campaign. Then the other system's release notes for the period since it last worked. Only after those four is it worth reopening the flow itself, which is almost never the thing that changed.
How many integrations should a small business chatbot have?
Fewer than the number you can name reasons for. Three well-chosen, monitored connections outperform ten switched on during a trial, because each one is a standing maintenance commitment and an increment to your switching cost if you ever change platform.
What is the difference between an integration and a webhook?
An integration is the outcome; a webhook is one mechanism for reaching it, specifically the inbound one where the platform calls your server when something happens. Most complete integrations use a webhook in one direction and an API call in the other.
Related guides
- Chatbot API (glossary) — the three layers that share the name, tier gating, and published rate limits
- Webhook (glossary) — the inbound mechanism, including signature verification and retries
- Add a chatbot to your website — the first integration most SMBs do
- Shopify chatbot integration — the worked ecommerce case, end to end
- Build a chatbot knowledge base — the cheaper fix when the answer is in a document, not a database
- Chatbot security and PII handling — how to scope credentials before a write integration
- Chatbot QA testing protocol — the regression set every new connection needs
- Migrating vendors in 14 days — why integrations dominate switching cost
- Best chatbot platforms for small business — ranked options, including integration depth
Sources
- Telegram. Bots FAQ — token management through BotFather, the effect of revoking a token, and webhook requirements. core.telegram.org/bots/faq (read 3 August 2026).
- Manychat. Dev Tools: Basics — the paid-plan gate on Dev Tools, and the split between an external request and a dynamic block. Vendor article last updated 3 December 2025. help.manychat.com (read 3 August 2026). The platform limits documented in the same article are covered in our chatbot API entry and are not restated here.
- Chatbotscape platform reviews, first-party sessions: Manychat (the Telegram token-drift incident and recovery sequence, and the native integrations list verified 25 May 2026), Tidio (native Shopify and WordPress, Telegram third-party only, 26 May 2026), Chatbase (native integration list and API tier gating, 26 May 2026), SendPulse (REST API and webhooks on paid plans, limited on the free plan, 26 May 2026), Typebot (HTTP request block and bring-your-own-key model access, 26 May 2026).
- Chatbotscape. Chatbot API /glossary/chatbot-api — companion entry holding the layer taxonomy, the tier-gating table, the channel rate limits, and the vendor-documented timeout and error-mapping behavior.
- Chatbotscape evaluation methodology. /methodology (continuously updated).
About this guide
Chatbotscape launched in 2026 as an independent review site for chatbot platforms. This guide is part of our SMB chatbot Academy. The four-rung ladder, the two opening questions, and the demo-day script are our editorial working model rather than an industry framework, and they are deliberately biased toward the cheapest rung that answers the customer's question, which frequently means recommending against building anything. To flag an issue or share your own results, write to editorial@chatbotscape.com.
Methodology
The rung ladder, the sequencing rule, the four failure modes, and the demo-day script are our editorial working model, assembled from the integration surfaces we exercised during our own authenticated platform review sessions and cross-referenced against current vendor documentation. The Telegram credential-drift incident is a first-party observation from our Manychat review session, reproduced there in full with the recovery sequence; the other three failure modes are patterns we describe from platform behavior and vendor documentation rather than incidents we have logged, and the page says so where each appears. The maintenance-load figures are a planning heuristic, labeled as such inline, not measured data. Native integration lists reflect vendor pages captured in May 2026 and are re-verified quarterly. Tier references use monthly-billed rates per our pricing methodology. This page and the chatbot API glossary entry are a deliberate pair with a split scope: the glossary owns the layer taxonomy, the tier-gating table, and every published limit, including the vendor-documented timeout and error-mapping rules, while this page owns what to connect, in what order, and how to keep it alive. Where the two touch, this page links instead of restating.
Last updated
5 August 2026 — Initial publication aligned to methodology v3.12.1. Next scheduled refresh: 5 November 2026.