Beyond chat: connect your AI support agent to HTTP APIs

Knowledge is the right source for stable answers: policies, product instructions, setup steps, and other material your team maintains. Some support questions depend on information that changes too often to copy into a document. Service status and live availability are two simple examples.

That is where an HTTP API can help. In Bubblo, an Action makes a configured endpoint available to the organization’s stateless AI runtime during a conversation.

Knowledge answers versus live data

Use knowledge when the answer should change only after someone edits and re-indexes the source. Use an Action when the answer must come from a system at conversation time.

Keeping this boundary clear makes the support experience easier to reason about:

• “How does your cancellation policy work?” belongs in knowledge.
• “Is the API operational right now?” can come from a status endpoint.
• “How do I install the widget?” belongs in knowledge.
• “Is this service currently available?” can come from a live availability endpoint.

What a Bubblo Action does today

An Action belongs directly to an organization. It contains a name, description, HTTP method, HTTPS URL template, request and authentication settings, and test and enabled states. The AI uses the name and description to decide whether the endpoint is relevant. The runtime can call only Actions in that organization that are enabled and have passed a test at their current configuration version.

Actions currently support GET and POST. Request configuration can combine dynamic string, number, or boolean inputs with fixed values: a placeholder such as {order_id} sends the matching input in the path, other Params go in the query string, and POST can send JSON Body fields. Fixed query values, fixed body values, and headers are also supported.

For authentication, choose no authentication, a Bearer token, or an API key header. Saved secrets are encrypted and cannot be viewed again. These controls can protect the request to your API, but dynamic inputs and stored credentials do not by themselves prove that a visitor may access a particular account. Your endpoint must still enforce the authorization required by the workflow.

Choose a safe first endpoint

A useful first Action should be:

• Read-only in effect. Start with information retrieval rather than an irreversible operation.
• Configured without secrets in the URL. Use the encrypted Bearer or API key fields for credentials; never place secrets or customer data in a configured URL.
• Fast. Every Action request has a five-second hard timeout.
• Small and predictable. Responses are limited to 20 KB, so return concise text or JSON that is directly relevant to the support question.
• Clearly described. Tell the agent what the endpoint returns and when it should be used.

A public service-status summary is a better first test than a refund endpoint. It proves the live-data loop without introducing customer authentication or a destructive side effect.

Configure and test the Action

Open Harness → Actions and create a new Action. Use a short, specific name such as check_service_status, select GET or POST, enter the HTTPS URL template, describe when the organization’s AI should use it, and add any dynamic inputs, fixed request values, headers, or authentication the endpoint needs.

Save the Action as a draft. Bubblo validates the configuration when it is saved, and a new or changed version stays disabled until that exact version passes a test. Enter representative values and select Run test; this sends a real request to the endpoint. After a successful test, turn on Enable this action.

Then test the enabled Action through the real widget:

1. Ask a question that clearly matches the Action description.
2. Check whether the answer uses the endpoint’s current response.
3. Open Call logs and review the status and duration.
4. Ask an unrelated question and confirm that the Action is not used unnecessarily.
5. Disable the Action if the endpoint changes or begins returning unreliable data.

Successful and failed attempts are logged, and the dashboard shows the latest matching calls. Every request has a five-second timeout, accepts at most 20 KB of response data, and treats only HTTP 200 as success. Configuration changes can take up to 60 seconds to reach a new AI turn. See the Actions documentation for the current fields and limits.

Keep a human path for exceptions

An Action can make a narrow part of support faster, but it does not remove the need for judgment. Authentication failures, unusual account states, refunds, and other sensitive cases should remain visible in Inbox, where a teammate can take over the conversation.

The most credible rollout is incremental: connect one low-risk source of live data, review its logs, learn which questions trigger it, and expand only when the API contract and safety controls are ready.