Connect a service to your agents
Found this helpful? Share it:
Found this helpful? Share it:
Connect a service once and your agents can use it. There is no second step: no connector to pick, no tool list to enable, no per-agent switch 🔌
You store one credential and say where it may be sent. That is the whole setup, and it is the only part that needs a person.
Everything else is worked out at the time of the call. When an agent makes a request, idapt looks at the address, finds the credential whose rules cover it, and attaches it on the server. The agent never receives the value, so it cannot repeat it back, and it cannot end up in the conversation history.
Any service with an API works, not only the ones in the directory. The integrations directory is a head start: those services come with their address, sign-in method, and paging behaviour already filled in. Anything else works the same way once you paste its address.
The new credential appears under Connections. Anything without a destination, like an SSH key or a database password, appears under Secrets instead.
An agent takes whichever route the service publishes, and you do not choose between them:
Its MCP server, when the service runs one. The agent asks what tools it offers and calls them.
Its API, which every service has. This is the route that makes the directory a convenience rather than a limit.
Its command-line tool, run on one of your computers with the credential mounted as an environment variable. Useful when the vendor's own tool already handles paging and retries well.
A service page in the directory shows which of the three it supports.
Each credential carries rules describing the addresses it is allowed to
reach. A rule for github.com covers
api.github.com and every other address under it.
Rules decide which stored credential matches a request. They are not a permission system: they route, and getting one wrong means a call fails rather than that something unsafe happens. Read where a credential can be sent for the full set.
If an agent reports that a credential cannot reach an address, the error names the exact command to widen it. You can also edit the rules on the credential itself.
It can use a credential by name and see which services the workspace has connected.
It can ask you to connect something, which opens the sign-in dialog for you to approve. It never completes a sign-in on its own.
It cannot read a stored value, and there is no command that returns one.
It cannot use a credential marked Human only, however that credential is shared.
An agent that can use a credential can send it to any address its rules allow, including one chosen from a web page it was asked to read. Keep the rules narrow for anything sensitive, and mark it Human only when no agent should touch it.
| Command | What it does |
|---|---|
idapt http request | Make an authenticated HTTP request to any API. |
| Command | What it does |
|---|---|
idapt service search | Search the curated services index. |
idapt service lookup | Look up a service by slug, domain or URL. |
Related articles
Credentials
Store API keys and app connections once, then let your commands, functions, and agents use them without pasting a key into a chat.
Where a credential can be sent
Rules decide which addresses a stored credential may reach, so the right one attaches automatically and the wrong one never does.
Was this helpful?