Integrations
Agent200 connectors handle each provider's API, its OAuth flow and its tokens, and keep every end user's connections separate. You choose the services, endpoints and scopes. Your agent reaches all of them through one SDK.
Agent200 connector layer
Six of the services Agent200 connects to. See the full catalog.
Connectors
A connector is Agent200's integration with one external service. It lets Agent200 communicate with that service on behalf of your agent, so retrieving Slack messages never means implementing Slack's HTTP API yourself.
You configure the capability. When it is invoked, Agent200 talks to the provider and retrieves the information.
Depending on the service, a connector may handle
Authenticates every request to the provider the way that provider expects.
Knows what the service requires before it will release a user's data, and runs that authorization flow.
Exposes the provider operations Agent200 supports. You decide which of them your agent may use.
Builds each request in the provider's format and communicates with its API.
Fetches the right end user's tokens for each call and refreshes them where the provider allows it.
Reads data and, where you permit it, performs write operations through the provider's API.
Hands the API result back to Agent200's execution environment, where the model or your workflow can use it.
Services
Slack and Gmail appear in most examples on this site because they are familiar. They are two entries in a longer list, and every service below is reached through the same SDK.
Each end user authorizes their own account through managed OAuth. No connector fee is intended for operations that carry no provider cost.
Reached with your Agent200 API key and billed through Agent200. No separate provider keys or accounts.
The operations available for a service depend on what its API offers and on the scopes your users grant. Need a service that is not listed yet? Tell us which one.
Connectors and tools
The two are related but different. A model never sees a provider's HTTP API. It sees a tool: a name, a description of what it does, and the inputs it accepts.
Connector
Slack
Access to an external service.
Endpoint
Search messages
One supported API operation you have enabled.
Tool
slack_search
A capability the model can discover and invoke.
slack_search
One API operation, described so a model knows when to use it and which inputs it takes.
customer_context
Operations from the same service, or from different ones, behind one name.
brief
Your own sequence of operations with a structured result, configured once and referenced by name.
Illustrative
customer_context shows the shape of a multi-endpoint tool: CRM details, related emails and Slack conversations behind one name.
What the model receives
{
"name": "slack_search",
"description": "Search the user's Slack messages.",
"input": {
"query": "string"
}
}The model decides whether to call the tool. When it does, Agent200 executes the underlying Slack request through the connector and returns the result to the model.
Permissions
Connectors are not limited to retrieving information. Agent200 is intended to support write operations too, such as sending a message, subject to the endpoints a provider offers, the user's authorization and the permissions you configure.
Which services, endpoints and OAuth scopes your app is allowed to request or execute.
Access to their own external account, through the provider's consent screen.
The permissions it actually granted, on every request made through its API.
A tool only executes when the necessary permissions and authorization are both in place.
Slack
Gmail
This configuration determines what Agent200 may expose to the model or execute for your app. You also select the OAuth scopes each connector requests.
Illustrative The panel above shows one such configuration: allow the reads your agent needs, block the writes it does not. Set each permission in the dashboard, or through the SDK where it is supported.
Managed OAuth
Private data needs the end user's authorization, whatever key your app holds. Agent200 runs that authorization for supported services, so you don't implement OAuth once per provider.
Handled by Agent200
Step 1 of 6
The agent requests Gmail access
Agent200 checks the end user's connection status.
End user: Summarize my recent emails.
Your agent calls Agent200
The request runs for user_123 and needs a Gmail capability.
Step 2 of 6
Authorization is required
Agent200 provides an authorization URL, or starts the hosted authorization experience.
Gmail is not connected
Authorization requireduser_123 has not authorized a Gmail account in this project yet.
Returned to your app
Step 3 of 6
The end user authorizes access
They open the link and are redirected to the provider's OAuth page.
Productivity Agent wants to access your email account
Read your emails scope chosen by the developer
Illustration. The real consent screen is the provider's own, and the end user decides there.
Step 4 of 6
The provider redirects to Agent200
The OAuth callback is handled on an Agent200-controlled domain.
The provider redirects back with the result of the authorization. There is no callback endpoint for you to build, host or keep running.
Step 5 of 6
Agent200 stores the credentials
The authorized connection is associated with that end user.
user_123 is linked to Gmail account A
Step 6 of 6
The capability becomes available
Execution continues through the supported flow, or you resume the request.
Gmail is connected
200 OKThe Gmail capability can now execute for user_123, within the scopes that were granted.
Agent: Here is a summary of your recent emails…
Agent200 is intended to support two approaches. One keeps the moment inside your product; the other hands it to Agent200.
Approach A
Agent200 responds that authorization is required and includes a URL you can present to the end user. You control how the request is presented, in your own interface and your own words, and when execution resumes.
Approach B
Agent200 provides a hosted authorization experience that can resume the requested operation after the end user has authorized access, so there is less for you to build around the interruption.
Planned The hosted flow returns to Agent200 after the user authorizes and resumes the interrupted run, so your code does not have to retry it.
User isolation
Connections are stored per end user inside your project. When you invoke Agent200 for user_123, it uses that user's accounts and must never reach for anyone else's. This mapping is the foundation of the platform's identity model.
Request from your app
agent200.user("user_123").run({ … })
Developer project
Agent200 cannot give an agent access to information the external service has not authorized. What an agent can actually do is the narrowest of four things.
Only what they granted on the provider's consent screen.
Only the services, endpoints and scopes you enabled.
Only the operations the service actually exposes.
Any quotas, policies or limits the provider applies.
Choose the services, endpoints and scopes. Agent200 handles the provider APIs, the OAuth flow and every end user's connections.