How-to
How to connect AI agents to your APIs
An agent reaches your systems through http_request, which calls any public REST API. No custom code, but two things decide whether it works well: how you authenticate, and how much of the response you let back in.
I built this tool, and the second part is where I got it wrong first — a single large field in a list response can eat the whole budget, so an agent sees one record out of hundreds and reports confidently on it.
Turn it on and authenticate
- Open the agent, click Edit, and tick `http_request` in the Tools section.
- In the Configuration box, describe in `system_prompt` when to call your API and what to do with the result.
- Pass credentials as request headers — the tool accepts a `headers` object, so an `Authorization` or `X-API-Key` header is the normal way in.
- Add `send_webhook` as well if the agent should push events out. That one needs an outbound webhook configured under Account → Integrations.
Methods available: GET, POST, PUT, PATCH, DELETE, HEAD. A request is time-bounded at 15 seconds, and you get 1,000 calls per day.
An API call adds almost nothing to the bill — what costs tokens is the response coming back into the next model call, which is exactly why the budget settings below matter. Source: a two-step worked example that looked up an order came to $0.0144, and one that failed on its first call $0.0024.
Keep the response small enough to be useful
This is the part that decides whether an agent gives you a real answer. A response is truncated to a character budget before the model sees it, so a fat JSON list arrives cut off.
| Setting | What it does | Cost |
|---|---|---|
select | Keep only named fields from each record of a JSON list. Dotted paths work, e.g. location.name | Free — it happens before truncation |
max_chars | Raise the response budget from 8,000 up to 25,000 characters | Input tokens on the next model call, and needs Pro or your own LLM key |
Try select first, always. On a list endpoint without it, one long field — a description, a body, a log — can consume the entire budget, so the agent sees a single record and has no way to know the rest existed.
What the guard will and will not allow
Every URL passes an SSRF check before the request is made: only internet-reachable hosts, so an agent cannot be talked into reading your internal network or a cloud metadata endpoint.
Redirects are followed, carefully
Up to three hops, each one re-checked against the guard rather than handed to the HTTP client to resolve. A chain longer than that is refused.
Credentials are dropped across hosts
If a redirect crosses to a different host, Authorization, Cookie, Proxy-Authorization and X-API-Key are stripped before the next hop. You wrote those headers and they usually hold a key, so forwarding them to wherever a 302 points would hand a stranger your credential. Browsers do the same thing for the same reason.
A refusal is visible
A blocked or failed call shows its status next to the tool name in the run. It does not pass silently — which matters, because the agent may still write an answer as though the call had worked.
Check it did what it said
Read the step rows, not the run status. Source: a run of mine finished as COMPLETED with both of its http_request calls refused 403, and the reply it drafted told the customer it had checked her orders. It cost $0.0204 and looked fine from outside.
Next
- See the other nine tools and their daily caps — see Give agents tools & integrations.
- Have your systems start a run — see Automate: schedules & webhook triggers.