Chat.co gives you two different integration paths. They both rely on the same underlying platform, but they are built for different workflows. If you are deciding between the direct API and MCP, this guide will help you choose the right starting point.
Short Version
Build with the direct API when your software needs deterministic HTTP requests. Use MCP when you want an AI client to manage chatbots, content, and analytics through tools.
1. Two Ways to Connect Chat.co
The two integration paths serve different jobs:
| Option | Best For | How It Works |
|---|---|---|
| Direct API | Custom apps, backend services, websites, mobile products | Your software sends HTTP requests to Chat.co endpoints using an API key. |
| MCP | AI clients like Claude Desktop or Cursor acting on your Chat.co workspace | A local MCP server translates tool calls from your AI client into Chat.co API requests. |
You can use both. Many teams use the direct API for production software and MCP for internal operations, experimentation, and content management.
2. When to Use the Direct API
The direct API is the right choice when you want explicit control over requests and responses.
Choose the direct API when:
- You are embedding chat into a website or product
- You need predictable request and response handling in code
- You want to manage authentication entirely inside your own backend
- You are integrating Chat.co into an app, workflow engine, or internal tool
- You only need chat and conversation access for a specific bot
Typical direct API pattern
- 1. Generate an API key in Chat.co Settings
- 2. Assign it to a chatbot when appropriate
- 3. Store it in your backend or secure vault
- 4. Call the Client API endpoints directly over HTTPS
If this matches your use case, start with the API documentation.
3. When to Use MCP
MCP is the better choice when you want an AI client to use Chat.co as a tool-enabled workspace instead of writing custom HTTP logic yourself.
Choose MCP when:
- You want Claude Desktop, Cursor, or another MCP-compatible client to work with Chat.co
- You want natural-language actions like “update this bot’s prompt” or “upload this document”
- You want a local AI client to manage content, analytics, or chatbot settings
- You want to approve access in the browser instead of manually copying API keys into the client
What MCP feels like
Your AI client sees Chat.co as a collection of tools: list bots, update prompts, start crawls, upload documents, review leads, and more.
What MCP is not
It is not a hosted browser experience. It is a local integration path that runs on your machine and uses an approved API key behind the scenes.
If this is what you want, go next to the MCP agent setup guide.
4. Authentication & Permissions
This is the most important difference for customers to understand.
| Topic | Direct API | MCP |
|---|---|---|
| Key creation | Generated manually from the dashboard | Created through agent login and approved in your browser |
| Default shape | Typically used for chat-focused API access | Typically used for broader tool access unless you narrow it |
| Where the key lives | Your app config or secret manager | A local key file used by the MCP server |
| Ideal permission model | Narrow and bot-scoped whenever possible | Use only the scopes the agent actually needs |
Why this matters
If you approve an MCP client with broad scopes, that client can do much more than send messages. It may be able to update chatbot settings, manage content, start crawl jobs, or read analytics depending on the scopes you approved.
5. Scoped vs Unscoped Access
Both integration styles can use chatbot-scoped or broader account access, but the tradeoff is especially important for MCP.
Use a scoped key when:
- You want to limit access to one chatbot
- You are connecting a client for a single team, workflow, or assistant
- You want the smallest practical blast radius
Use an unscoped key when:
- You need to create new chatbots
- You need account-level analytics or message allocation views
- You want one AI client to operate across multiple bots you own
In practice, many teams start broad in a staging environment, learn which tools matter, and then tighten scope for production use.
6. Security Model
The safest way to think about the two models is this:
Direct API security
Treat the API key like any other backend credential. Store it server-side, rotate it periodically, and keep it out of browser code and mobile bundles.
MCP security
Treat MCP as local delegated access. You are allowing an AI client on your machine to call Chat.co tools using a locally stored API key. Approval, scope, expiry, and revocation matter more here.
For an MCP connection, you should document:
- Which chatbot or account scope it has
- Which scopes it was granted
- Where the key file is stored
- Who is allowed to approve or renew the connection
7. Quick Decision Guide
Use the direct API if you are saying:
- “I need to embed chat in my product.”
- “I want my backend to send and receive messages.”
- “I need predictable JSON responses in code.”
Use MCP if you are saying:
- “I want Claude Desktop or Cursor to manage my Chat.co workspace.”
- “I want to ask an AI client to update prompts, upload docs, or review leads.”
- “I do not want to hand-wire every capability as raw API calls.”
Still unsure? Start with the direct API for customer-facing production traffic, then add MCP for internal operator workflows once your team understands the permission model.
8. Common Mistakes
Mistake: Treating MCP as “just another API key”
MCP is a local tool integration, not just a static credential pasted into code. It deserves its own setup, approval, and revocation guidance.
Mistake: Using a broad key when a scoped key would do
Limit access to the specific chatbot or capability set you actually need.
Mistake: Sending direct API keys from the browser
Keep API keys server-side or in approved local MCP setups. Do not ship them in client-side code.
Ready to set up an AI client? Continue to Connect Claude Desktop or Cursor with MCP.