Connect a chatbot to a REST API without code
Let the AI helper configure a public customer lookup, then prove both the authorized and denied results.
API Connectors fetch current data during a conversation. Unlike indexed knowledge, customer, order or inventory data is called only when the assistant has collected the required fields.
This reproducible example uses the public JSONPlaceholder test API and no secret. Customer ID 1 returns fictional data, while a validation rule requires the matching email before the chatbot may reveal name, company and website.
What you will have at the end
- An AI-generated active REST connector
- Required user ID and email fields with response validation
- A successful lookup and a blocked wrong-email attempt
Before you start
- Standard plan or higher
- A documented HTTPS test endpoint
- Non-sensitive test records
- A defined allow and deny expectation
Collect, call, validate, answer
The prompt decides when the connector is eligible. Fields tell the assistant which values to collect, the request template calls the endpoint and validation rules compare visitor input with the response.
Validation must happen before any sensitive response data is presented.
01–07
Set it up step by step
Open the empty API Connectors list
Start on the intended chatbot before adding a live tool.
Open the chatbot and select API Connectors. The empty state explains that connectors can fetch order status, tickets, inventory or any other documented REST response. Select Add API Connector.
Keep one business capability per connector. Narrow names and prompts make tool selection easier to test and permissions easier to audit.
Choose Set up with AI
Describe the outcome instead of translating documentation field by field.
The dialog offers Set up with AI and Set up manually. Choose the AI assistant when you have a clear endpoint and outcome; use manual setup when an approved configuration must be copied exactly.
The assistant can research and populate fields, but you remain responsible for reviewing endpoint, method, headers, field types, validation and prompt before saving. Do not paste production secrets into the chat.
Describe the JSONPlaceholder lookup and review generated fields
The AI helper fills a complete, inspectable first draft.
Ask for `https://jsonplaceholder.typicode.com/users/{user_id}` with required `user_id` as Number and `email` as Email. Instruct the assistant to validate email against response path `email` without case sensitivity and reveal only name, `company.name` and website.
The verified helper created “JSONPlaceholder Customer Lookup”, GET, empty headers, the two required fields and the correct endpoint placeholder. JSONPlaceholder contains fictional demo records, so the tutorial does not expose real customer data or credentials.
Review validation and tool instructions
Security controls must be explicit before Create.
Confirm the validation compares input field `email` with response path `email` using Equals (ignore case). Use a neutral failure message: “The email address does not match this customer profile. Please try again.”
The tool prompt must say when to use the connector, which fields to collect and which response fields may be presented. For production, use a dedicated read-only credential in headers or server-side secret handling and never let an AI-generated patch broaden permissions unnoticed.
Create and verify the active connector card
Confirm method, endpoint, fields and active status together.
Select Create and return to the list. The active card should show JSONPlaceholder Customer Lookup, GET, the endpoint, prompt summary, `user_id` and `email` fields and the enabled switch.
Do not proceed to chat testing if the card is inactive or the endpoint differs from the reviewed form. A saved configuration is not yet proof that the API call and security rule work.
Test the authorized customer lookup
Use a fixed record with a known exact response.
Open the live visitor widget and ask: “Look up demo customer 1. The verification email is Sincere@april.biz.” The connector calls `/users/1`, validates the email and returns Leanne Graham, company Romaguera-Crona and website hildegard.org.
Record the exact input and visible answer. This is the allow-path baseline for future regression tests; a different model may phrase the text differently, but the three authorized facts must remain correct.
Prove that a wrong email is blocked
The deny-path test is as important as the successful result.
In the same controlled test, ask for customer 1 with `wrong@example.com`. The verified chatbot states that the email does not match and reveals no new customer details.
Repeat this deny test after changes to fields, validation paths, endpoint response shape, prompt or model. For sensitive production data, also test missing fields, malformed responses, timeouts, 401/403, 404 and rate limits.
Example & result
See the practical test and its result
Every tutorial includes a fixed input, the expected outcome and a transparent record of what was actually verified locally.
Practical example: Connect a chatbot to a REST API without code
This exact scenario was completed with the temporary tutorial account.
Exact test input
Look up demo customer 1 with Sincere@april.biz, then repeat with wrong@example.com.
Expected result
The matching email reveals only name, company and website; the wrong email reveals no customer record.
What was actually verified
The real connector returned Leanne Graham, Romaguera-Crona and hildegard.org for the valid input, then blocked wrong@example.com with the configured validation message.
Tips & tricks
Make the setup reliable
Test with realistic examples, record your baseline and change one setting at a time. That makes real improvements visible.
Use a read-only API identity
The chatbot should not receive write or delete permissions when it only needs order status.
Test malformed responses
Verify timeouts, missing fields, non-200 responses and invalid JSON so visitors receive a safe fallback.
Choose a model with reliable tool use
Compare the same allow and deny prompts in Model Arena. Prefer the fastest economical model that consistently collects all fields, calls the connector once and respects validation.
When something does not work
Troubleshooting
Check status, permissions and test data systematically before changing the model or prompt.
The expected option is missing
Confirm the account plan, feature permissions and selected chatbot. Paid or beta features can be hidden when prerequisites are not met.
The test result is inconsistent
Reset the test conversation, keep the input identical and change one setting at a time so the cause remains measurable.
Ready for a production-style test
Review connector logs and permissions after launch. Add further actions only as separate, narrowly scoped connectors with their own validation.