Chatbot API Integration: Connect Your Chatbot to Any REST API

Chatbot API integration means letting a chatbot call another system's API in the middle of a conversation - to look something up, create a record or trigger a workflow - and use the result in its next reply. Instead of answering only with pre-written text, the bot can fetch an order status, add a lead to your CRM or book a slot in a calendar.

Three ways to connect a Conferbot chatbot to other systems

• Webhook node (any REST API): call any HTTPS endpoint from inside a flow with GET, POST, PUT, PATCH or DELETE, custom headers and a request body, then store the response in a variable.
• Native integration nodes: ready-made steps for tools such as Google Sheets, Google Calendar, HubSpot, Slack, Airtable and Stripe, configured without writing requests by hand.
• Zapier: the Zapier node reaches 2,000+ more apps with no code.

Going the other way, the Conferbot REST API and outgoing webhooks let your own systems create bots, send messages into conversations and receive events. See the developer API documentation for endpoints and authentication, or the chat API explainer if you are deciding whether you need an API at all.

What API integration enables

• Data retrieval: "What's my order status?" - the bot asks for the order number, calls your order API and replies with the status.
• Data creation: "Book me in for Tuesday" - the bot creates the booking and confirms it.
• Data updates: "Change my shipping address" - the bot updates the record in your system.
• Workflow triggers: a completed lead form posts to your CRM or a Slack channel.

Short answer: you can add a Conferbot chatbot to your website for free, but calling external APIs from the bot and using the Conferbot REST API start on the Starter plan at $19/month. Here is exactly what each plan includes, so you can decide before you build.

A practical path: build and test your bot on the free chatbot maker, put it live on your site, and upgrade to Starter on the day you need the bot to talk to your own API. Pricing is flat per workspace - see all plans.

The webhook node calls any publicly reachable HTTPS endpoint from within a conversation flow, with control over the method, headers, body and what happens with the response.

Supported HTTP methods

• GET: retrieve data (order status, account details, product info)
• POST: create records (book an appointment, submit a lead, open a ticket)
• PUT / PATCH: update existing records (change an address, modify a booking)
• DELETE: remove records (cancel an appointment)

Request configuration

• Endpoint URL: use ${variable} to insert values from the conversation, for example an order number the visitor typed.
• Headers: add Content-Type, Authorization and any vendor-specific headers.
• Request body: send JSON built from conversation variables such as name, email and selections.
• Timeout: requests time out after 10 seconds, so design a fallback branch for a slow upstream.

Response handling

The response is stored in a variable you name on the node, and every node after it can read that variable with ${variable} syntax - in a message, in a condition, or in the body of the next API call:

• Name the variable on the webhook node, for example booking.
• Use it downstream as ${booking} in any later message or condition.
• Branch on it with a condition node to show one reply when the lookup succeeded and another when it did not.
• Chain calls by referencing the first response inside the second request body.

The builder lets you test the call while you are editing, so you can see the real response shape before you wire the next node to it. See the no-code chatbot builder for how nodes connect.

Most APIs need credentials. The webhook node handles the common patterns without code.

• API key or bearer token in a header: add an Authorization or X-API-Key header on the node.
• Token endpoint: point the node at a token URL and it fetches an access token before calling the API, for services that issue short-lived tokens.
• Custom headers: for vendors with their own header names, add any header you need.

Good practice

• Create a dedicated key for the chatbot with the narrowest permissions your API allows.
• Only send the conversation fields the API actually needs.
• Rotate keys when a teammate with access leaves, and limit who can edit flows with team roles.

For calls in the other direction, the Conferbot REST API uses a bearer token in the Authorization header, issued from your account - details are in the developer documentation.

API calls from the bot are one direction. Webhooks and the REST API cover the other: your systems hearing about conversations, and your systems pushing messages in.

From the conversation out to your systems

• Lead captured: post name, email and answers to your CRM or a Google Sheet the moment the visitor submits them.
• Booking made: create the calendar event and notify the team in Slack.
• Payment step: hand off to Stripe from inside the flow.
• Anything else: send a POST to your own endpoint, or route it through Zapier.

From your systems into a conversation

The REST API's messaging endpoints let you send a message into a conversation from a system that is not Conferbot - an order-status update from your store, for example. Because the same bot runs on every connected channel, that message reaches the visitor wherever the conversation lives.

When an endpoint does not receive what you expect, the developer docs link to a webhook debugging guide.

A bot that quotes yesterday's stock level breaks trust. Choose the pattern by how often the data changes.

• Live lookup: for order status, availability or balances, call the API at the moment the visitor asks. The answer is always current; the cost is a short wait while the call runs.
• Content the bot already knows: for things that rarely change - opening hours, policies, product descriptions - put them in the bot's knowledge base so it can answer without a call.
• Write-back: when the visitor gives you new information, send it to the system of record (CRM, Sheet, booking tool) in the same flow so there is one source of truth.

External APIs go down, return errors and hit rate limits. A bot that shows raw errors or stalls mid-conversation loses the visitor, so plan for failure in the flow itself.

• Check the response: after the webhook node, add a condition on the stored variable - one branch for a good result, one for anything else.
• Write a human fallback message: instead of "Error 500," say "I can't reach our booking system right now."
• Offer a next step: collect the visitor's email so your team can follow up, or hand the chat to a person through live chat.
• Respect the 10-second timeout: point the node at endpoints that answer quickly; move slow jobs to a background process that you notify with a POST.
• Mind upstream limits: your API's own rate limits still apply, so avoid calling it on every message when one call per conversation will do.

Pick the lightest option that does the job.

Browse the full integrations hub, or read about the mobile SDK.

These are common patterns teams build with the webhook node and native integrations. Each runs without custom backend code inside Conferbot - you only need the API you are calling.

E-commerce: order status

The bot asks for the order number and email, calls your store's order API with a GET request, and replies with the status and tracking link. If the lookup fails, it offers a handover to a person.

Services: appointment booking

The bot collects the service and preferred time, checks availability with the Google Calendar integration, books the slot and confirms - on your website or on WhatsApp.

B2B: lead routing

The bot qualifies the visitor, creates the contact in HubSpot and posts a summary to the sales channel in Slack.

SaaS: account questions

The bot calls your product API for the customer's plan or usage and answers directly; complex billing questions go to an AI agent or a human.

Start from an industry template and add the API step.

This example builds a bot that checks the weather for any city with a public weather API. The same steps work for a CRM lookup, a booking system or your own backend.

Step 1: Ask for the input

In the visual builder, add a question node "Which city?" and save the answer in a variable called city.

Step 2: Add the webhook node

• Method: GET
• URL: the API endpoint with ${city} in the query string
• Headers: your API key, if the service uses a header
• Save response as: weather

Step 3: Use the response

Add a message node that reads from ${weather}, and a condition node that sends failures to a friendly fallback message.

Step 4: Test and publish

Test the call in the builder, try an invalid city to check the fallback, then publish. The bot works the same on every connected channel.

Next steps

• Swap the weather API for your CRM or order system.
• Use POST to create records instead of reading them.
• Chain two calls by using the first response in the second request.