Define an HTTP action and the chatbot can call your CRM, your ticketing system, your inventory check. Webhooks publish events to the automation your client already uses. Every call logs what went out and what came back.
A chatbot that only answers is half a feature. The other half is the moment it creates the ticket, sends the lead, or marks the order — without your team typing it.
Build an action in three guided steps: when the agent should use it, what it needs to collect, and where it sends the result — webhooks, your APIs, or a ticket — with a readiness checklist before it ever goes live.
A chatbot that answers is useful. A chatbot that creates the support ticket, qualifies the lead into the CRM, or checks inventory before answering is a feature your client signs the retainer for. Actions are the HTTP calls. Webhooks are the events your client's automation already listens for. The inspector shows you every call and every response so debugging is fast.
Any HTTP endpoint can be an action — no vendor-specific connector required.
Outbound webhooks for events your client's automation already handles.
Run inspector shows the full payload and response for every call.
The visitor asked to open a ticket. The chatbot promised. The chatbot did not. The visitor is upset; the agency hears about it. Actions close that gap.
Every client has a different CRM, a different help desk, a different inventory system. Writing a connector for each one does not scale.
The webhook went out. The receiver returned a 500. The chatbot moved on. Without an inspector you find out in the next account review when the metrics are off.
Define a name, an endpoint, an auth header, the payload shape. The chatbot can now call it. Most internal APIs are HTTP — every one of them becomes an action.
Make, n8n, Zapier, or a custom endpoint. The chatbot publishes the event; the receiver does whatever it does. Optional signing for the receivers that verify signatures.
The chatbot called the action. The receiver responded. Both visible in the inspector. When something fails, the inspector is where you go first.
Identify what the chatbot needs to do beyond answering — create a ticket, send a lead, check inventory.
Define the action or webhook and test it in the inspector.
Let the chatbot use it. Watch the runs.
When something fails, the inspector tells you what went out and what came back.
How often the chatbot is actually calling out, not just answering.
Which integrations are flaky. Fix the cause, not the symptom.
Receiver response code per event. 200 means delivered; the rest means investigate.
Sales chatbots that create the CRM record after qualifying the visitor.
Support chatbots that open the ticket in Zendesk, Freshdesk, or Help Scout before handing off.
Operational chatbots that check inventory, status, or pricing against an internal API before answering.
Actions are scoped per client — one client's actions cannot reach another's endpoints.
Webhook signing is optional but recommended for receivers that verify signatures.
The inspector shows every call but only inside the client and agency context.
Yes — if the API speaks HTTP, the chatbot can call it. You define the endpoint, the auth, the payload shape, and the chatbot uses it like any other tool.
You do not need one. The webhook is the integration — Make, Zapier, and n8n all listen for webhooks natively. We send the event; their automation picks it up.
The inspector shows the request and the response. You debug from the same screen, fix the action or the receiver, and the next run uses the corrected version.
Tell us what you are trying to ship, and we will show you the pieces of the platform that get you there.