AI Chatbot API Integration: Connect Your Bot to the Systems That Hold the Answers

Which way does the data flow? Three kinds of chatbot API work

‘Connect the chatbot to our API’ can describe opposite jobs, and projects drift when nobody says which one is meant. We separate them on the first call.

Outbound: the bot calls your systems

A visitor asks where an order is, whether a part is in stock or when their next service visit falls. The answer lives in your order platform, inventory database, field-service software or help desk. Our server calls that system’s API on the bot’s behalf and hands the relevant fields back to the model. This is the most common request, and most of this page covers it.

Inbound: your systems call the bot

Your mobile app, customer portal, kiosk or SMS gateway wants the chatbot’s brain without its web widget. Here we expose the chatbot itself as an authenticated endpoint: post a message and a session ID, receive a reply plus any structured actions. Your app owns the interface; the bot owns conversation logic, knowledge and guardrails.

Event-driven: your systems tell the bot what changed

When an order ships or a ticket moves, your platform pushes a webhook so the bot knows the latest state without asking over and over. Many projects combine all three, but each has its own authentication, threat model and failure behavior, so we scope them separately even when they ship together.

How a language model uses your API without ever holding the keys

Current AI models can request structured actions, usually called tool calling or function calling. The mechanics deserve attention, because they are where the safety comes from.

1. We define tools. Each tool has a name, a plain-English description of when to use it, and a strict schema for its arguments. A lookup_order tool, for example, might require an order number in your format plus the billing ZIP code.
2. The model proposes a call. When a visitor asks about an order, the model returns a request to run lookup_order with the arguments it pulled from the conversation. It executes nothing.
3. Our server decides. The integration service validates arguments against the schema, checks that this session may run the tool, applies per-visitor limits, and only then calls your API using credentials the model never sees.
4. The response is trimmed. Your API might return forty fields. The server passes back the handful the answer needs, which reduces token cost and keeps internal data such as margins or staff notes out of the model’s context.
5. The model replies. It phrases the result for the visitor; where it matters, dates and amounts in the reply are checked against the tool result before display.

Two habits make this dependable. A few sharp tools beat one generic ‘call any endpoint’ tool, since narrow tools are easier for the model to choose correctly and cannot be bent toward unrelated actions. And private lookups demand two facts the genuine customer knows, such as order number plus ZIP, so nobody can step through sequential order numbers reading strangers’ details.

Choosing an authentication model system by system

When the visitor is a signed-in customer

If the chatbot lives inside a portal where customers are already logged in, it should see only that customer’s data. We pass the portal’s session identity to the integration service, which scopes every API call with it, rather than trusting a customer number the model extracted from chat text. A visitor typing ‘I am account 5521’ changes nothing.

Reads are forgiving; writes need guardrails

Fetching opening hours and issuing a refund are both ‘API calls’, yet they deserve very different handling. We sort every operation into a tier before building it:

• Public reads. Service areas, product specifications, published availability. No identity check.
• Private reads. Order status, balances, appointment details. Verification or a logged-in session required.
• Reversible writes. Opening a support ticket, saving a callback request, drafting a quote. Allowed once the bot summarizes what it will send and the visitor agrees.
• Consequential writes. Cancellations, refunds, charges, account changes. Routed to a human approval queue or left out of the bot entirely.

The confirmation step lives in server state, not in prompt wording. The server records that a write was proposed, shows the visitor a summary with the exact values, and executes only after an explicit confirmation event tied to that specific proposal. A cleverly phrased message cannot skip the step, because the model does not control it.

Timeouts, retries, rate limits and idempotency

Chat is impatient. A visitor waits a few seconds for an answer, not thirty, and upstream systems are not always quick or even available. Our connectors are designed around that reality.

• Timeout budgets. Each tool call gets a timeout sized to the conversation, and a slow call triggers a holding message rather than a frozen widget.
• Retries only where safe. Reads and idempotent operations retry with exponential backoff and jitter; non-idempotent writes never retry blindly.
• Idempotency keys. Where your API supports them, every write carries a unique key so a network hiccup followed by a retry creates one ticket, not two. Where it does not, we check for an existing record first.
• Rate limits respected. A 429 response is read, any Retry-After header is honored, and per-visitor caps stop one busy conversation from draining a shared quota.
• Circuit breaking. If an upstream system fails repeatedly, the integration pauses calls briefly and the bot tells visitors plainly that live lookups are unavailable, offering a form or callback instead.
• Short-lived caching. Slow-changing data such as a product catalog is cached briefly; anything personal or fast-moving is fetched fresh.
• Pagination and size caps. List endpoints are paged, and the model is never handed hundreds of records to summarize.

Receiving webhooks instead of polling

Polling an API every few minutes to see whether anything changed wastes quota and still arrives late. When your platform can send webhooks, we build a receiver that treats each request as untrusted until proven otherwise:

1. Verify the signature, commonly an HMAC computed with a shared secret, before acting on the body.
2. Reject stale timestamps to block replayed requests.
3. Acknowledge quickly with a 2xx status and process in a background queue, so the sender does not time out and resend.
4. Deduplicate by event ID, since most senders guarantee at-least-once delivery, which sometimes means twice.
5. Tolerate out-of-order arrival by comparing record versions or timestamps before overwriting anything.

Where a system offers no webhooks, we poll on an interval that respects its limits and request only records changed since the previous run.

Field mapping and the messy middle

Most integration bugs are not in the HTTP request. They hide in the translation between what a person typed, what the model extracted and what the API expects.

• Formats. Phone numbers normalized to E.164, dates to ISO 8601 with an explicit time zone, currency as minor units where the API wants cents.
• Identifiers. Order and account numbers checked against their known pattern before any call, so a model that mistakes the letter O for a zero produces a clarifying question instead of a baffling ‘not found’.
• Enumerations. Free text such as ‘urgent, water everywhere’ mapped to your API’s permitted priority values through an explicit table rather than improvisation.
• Nulls and partial records. A missing ship date becomes ‘not scheduled yet’, never a blank or a nonsense date.
• Versioning. The connector pins an API version where the vendor allows it and records schema changes, so a vendor update raises an alert instead of silently producing wrong answers.

When the data sits in a database rather than behind an API, the approach changes; our chatbot database integration page covers read replicas, views and query guardrails.

Testing before customers touch it

• Sandbox credentials. Development runs against a test environment or test account, never live customer data, until the final check.
• Contract tests. If you publish an OpenAPI description, requests and responses are validated against it automatically, catching drift the day it appears.
• Fault injection. We simulate 500 errors, 429 responses, timeouts and malformed bodies to confirm the bot degrades politely.
• Conversation evaluations. A written set of realistic conversations runs on every change, checking both which tool the model picked and the final wording.
• Abuse attempts. Scripted efforts to read another customer’s record, invent arguments, skip confirmation or coax out credentials through prompt injection.
• Observability. Each tool call is logged with latency and result code, personal data masked, and alerts fire on error spikes after launch.

What we ask for during scoping

A short list of questions saves weeks later. Before quoting we ask:

• Which systems hold the data, and are their APIs documented with an OpenAPI file or only a vendor PDF?
• Is there a sandbox or test account?
• Which authentication method does each system use, and who in your organization can issue credentials?
• What are the published rate limits, and does any vendor charge per call?
• Which operations should the bot perform, which should it only suggest, and which are off limits?
• How sensitive is the data, and do contracts or regulations restrict where it may be processed?
• Who hears about it when a vendor changes its API?

If a system has no usable API, we say so. Options include a small purpose-built API placed in front of it, which falls under our custom software work, or reaching the data through another system that already syncs with it.

How an API integration project runs with EVOTECH IT LLC

Our team is US-based, works out of the Houston area, and carries over twenty years of business history along with a 5.0 Google rating. We build web, software and AI systems for clients nationwide, delivered entirely remotely. An API project moves through these stages:

1. A free phone or video consultation to map the systems involved and the questions the bot must answer.
2. A read of your API documentation and a trial call or two against the sandbox to confirm the basics behave as documented.
3. A fixed-scope written quote listing every tool, its tier, its authentication method and its fallback behavior.
4. Build of the integration service, tool definitions and conversation flows, with secrets in a managed store.
5. The testing described above, then a session where you try to break it yourself.
6. A staged launch with monitoring, and handover notes on credential rotation and how to switch off any single tool instantly.

For the wider picture of connecting AI to business software, see AI integration services; if the target is specifically your CRM, chatbot CRM integration goes deeper on contacts, deals and dedupe. Call (832) 359-2425 or book a free consultation.

Related services

Frequently asked questions