Secure Connections: How OAuth and API-Key Keep Your Data Safe

The moment a chat widget can do more than talk, the question changes. It stops being "will the bot give a good answer?" and becomes "what is this thing allowed to touch, and where do my keys live?" Those are fair questions to ask before you let any tool reach into your store, your help desk, or your CRM. A bot that can book a meeting or look up an order is handling real systems with real credentials, and you deserve to know exactly how that link is built.

Here is the short version. BestChatBot never holds your passwords. A specialized credential provider stores the connection encrypted, refreshes the tokens on its own, and hands the bot a narrow, scoped permission to act, nothing more. We think that separation is the whole game: the part that talks to your visitors and the part that holds your secrets should never be the same box.

This page walks through how a connection is actually wired, what OAuth and API-key mean for you in plain terms, and the guardrails that decide who is allowed to do what.

Why your credentials never sit with the bot

Most people picture a connection as "paste your password into the chatbot and hope." That is the model we refused to build. Storing a customer's live credentials next to the public-facing widget is the kind of shortcut that looks fine until the day it is not.

Instead, the credentials live with a specialized provider whose only job is holding connections safely. When you link a tool, the secret goes straight into that vault, encrypted at rest. The bot itself never reads your raw password or API token. It asks the provider to perform an action on your behalf, and the provider, holding the real key, makes the call. Your secret stays in one place, behind one door, away from the chat surface entirely.

There is a practical upside too. Access tokens expire. When they do, the provider refreshes them quietly in the background, so the connection keeps working without anyone re-entering a password every few weeks. You set the link up once. The hard part of keeping it alive is somebody else's problem. You can see how every connector follows this same pattern in the integrations overview.

OAuth and API-key, in plain terms

Two ways exist to authorize a connection, and the right one depends on the tool you are linking. Both end up in the same encrypted vault. The difference is how you grant the permission in the first place.

OAuth is the "sign in with" flow you already know. You click connect, a secure window from the tool itself opens, you approve the access, and the tool hands back a scoped token. You never type a password into our dashboard. The approval happens on the tool's own site, and you can revoke it from there any time. This is the cleaner path, and it is what the dashboard uses wherever the tool supports it.

API-key covers the tools that authorize with a generated key instead of a sign-in window. You create a key inside that tool's settings, scoped to what the bot needs, and paste it into the connection once. From that point it behaves the same as an OAuth token: it lands in the encrypted vault, the bot never sees the raw value, and the provider uses it to act. If a tool only offers a key, that is the route. If it offers both, OAuth wins.

The two methods are not a quality ranking. They are just what each tool exposes. Across the eight connectors, scheduling, support, CRM, payments, and e-commerce, you will see a mix of both, and the dashboard tells you which one a given tool uses before you connect it.

Identity decides who can do what

Encrypting credentials protects your side of the link. The other half of security is the visitor side: making sure the bot only does customer-specific things for the actual customer.

A customer-specific action, looking up someone's order, reading their ticket history, changing a subscription, needs a verified visitor identity. Your site passes the widget a signed token that proves who the person is. With that token, the bot pins the action to that verified identity: the email and name come from the signed claim, not from whatever someone typed into the chat box. No token means the bot will not touch private data. It either stays on the anonymous path or blocks the action outright. There is no quiet downgrade where it guesses and hopes.

That rule closes the obvious hole. Without it, a stranger could type a known customer's email and fish for their order history or support thread. With identity verification in place, the bot reads only what the signed token says the person owns. The deeper mechanics of this live in the write-up on identity-verified actions with JWT, which covers the token flow end to end.

One workspace, walled off from the rest

BestChatBot runs as a multi-tenant service, which is a fancy way of saying many businesses share the same platform. The connections you make, the knowledge you upload, and the actions your bot takes belong to your workspace alone. They are isolated from every other tenant by design, not by politeness.

That isolation matters most for connections. Your encrypted credentials are scoped to your workspace. Another business on the platform cannot reach your help desk, your store, or your CRM, because their bot operates inside its own walled space with its own keys. The grounding follows the same boundary: the bot answers from your knowledge, not anyone else's, which is the same discipline behind our grounded, no-hallucination answers. Your data does not leak sideways into someone else's bot, and theirs does not leak into yours.

A record of what the bot did

Trust is easier to give when you can check the work. Every action the bot takes leaves a trail: what was attempted, on whose behalf, and what the result was. You are not taking it on faith that the bot behaved. You can look.

This audit record turns "the AI did something" into "the AI created this ticket, for this verified visitor, at this time, and it succeeded." When something looks off, you have the receipt. When a customer asks what happened, you can answer. The combination of encrypted credentials, identity-gated actions, and a visible record is what we mean when we say a connection is secure. Not a badge, the actual behavior.

What this needs from your plan

Answering questions from your knowledge base works on every plan, and that path never touches a third-party credential. Taking actions, the part that uses these secure connections to reach into your tools, is a paid capability. Action execution runs on the Pro and Business tiers, where the connectors switch on.

The split is deliberate. Grounded answers are the baseline any site should have. Letting the bot hold a scoped key and act on your real systems is a different level of capability, and it lives where the connectors live. If you are sizing this out, the pricing guide shows which tier turns on actions. For the technical view of how the widget itself loads on your site, the website widget setup covers the install side, and the support agent API is there if you want to drive things programmatically.

FAQ

Does BestChatBot store my passwords or API keys?

No. A specialized credential provider stores the connection encrypted at rest, separate from the chat widget. The bot never reads your raw password or API token. It asks the provider to act on your behalf, and the provider, holding the real key, makes the call. Your secret stays in one place, away from the public chat surface.

What is the difference between OAuth and API-key?

OAuth is a "sign in with" flow: you approve access on the tool's own site and it hands back a scoped token, with no password typed into our dashboard. API-key is for tools that authorize with a generated key instead: you create a scoped key in that tool and paste it once. Both end up encrypted in the same vault, and the bot never sees the raw value.

Can the bot act on a customer's private data without checking who they are?

No. Customer-specific actions need a verified visitor identity, a signed token your site passes to the widget. The bot pins the email and name from that signed claim, not from free text. No token means it blocks the action or stays on the anonymous path. It never silently downgrades and guesses.

Is my workspace separated from other businesses on the platform?

Yes. The service is multi-tenant, and each workspace is walled off. Your encrypted credentials, your knowledge, and your actions are scoped to your workspace alone. Another business on the platform cannot reach your connected tools, and the bot answers only from your knowledge, not anyone else's.

Can I see what the bot did with a connection?

Yes. Every action leaves an audit record: what was attempted, on whose behalf, and the result. So "the AI did something" becomes "the AI created this ticket, for this verified visitor, at this time." When you need to check the work, the record is there.

Want to see how each connection is wired before you turn one on? Start with the integrations overview to see every connector and the authorization method it uses, then connect the one your team already runs.