A little distance between agents & secrets

Give agents access.
Keep your keys.

Your agent needs an API. It doesn't need your API key. Thru puts a secure connection in between, adding your credentials behind the scenes.

Make the connection I'm an agent

ANY API. YOUR CREDENTIALS. A SEPARATE ACCESS TOKEN.

THE CONNECTION, AT A GLANCE

Your credentials

Your agentRequest + access token

ThruKeys added here

Any APIYour chosen destination

API responses return. Stored credentials stay in Thru.

01 / Agent knows the connection02 / Thru holds the key

No credentials in the conversation

Standard HTTP. No special SDK.

Expiring connections. Revoke anytime.

A small handoff. A safer workflow.

Four steps. Then you're Thru.

Let your agent handle the setup. You handle the one thing that should stay private.

01 / SHARE

Point your agent here.

Give your agent https://thru.snd.one and tell it which API you want to use. It can read the instructions and help you find the right credentials.

02 / SET UP

Your agent opens a connection.

It defines the destination, credential fields, and how the keys belong in each request. Thru returns a private setup link for you.

03 / CONNECT

Add your keys yourself.

Open the link, review the exact destination and permissions, and enter your credentials directly into Thru. Tell your agent you're connected.

04 / GO

The requests go Thru.

Your agent calls the proxy with its own access token. Thru adds the API credentials on the server, forwards the request, and returns the response.

For the other side of the chat

Hello, agent.
Here's your way in.

No account or credential is needed to create a proxy. Define a connection, give the user its auth_url, then use your separate access_token to check its status and send requests.

Ask the user to enter provider credentials on the setup page. Keep them out of the conversation. Your access token also grants API access; keep it private.

llms.txt ↗OpenAPI schema ↗

curl -X POST 'https://thru.snd.one/api/proxies' \
  -H 'Content-Type: application/json' \
  -d '{
    "name": "GitHub workspace",
    "description": "Read issues and pull requests.",
    "target_url": "https://api.github.com",
    "credential_url": "https://github.com/settings/tokens",
    "credentials": [
      {"key": "api_key", "label": "GitHub access token"}
    ],
    "headers": {"Authorization": "Bearer {{api_key}}"},
    "allowed_methods": ["GET", "HEAD", "OPTIONS"]
  }'

# Send the returned auth_url to the user.
# They enter their GitHub token directly into Thru.
# Then check the connection with your agent access_token:

curl 'https://thru.snd.one/api/proxies/PROXY_ID' \
  -H 'Authorization: Bearer AGENT_ACCESS_TOKEN'

# Wait until the response says:
{
  "status": "authenticated",
  "proxy_url": "https://thru.snd.one/p/PROXY_ID"
}

# Use the proxy URL in place of the API base URL.
# Authenticate to Thru with the agent access_token.

curl 'https://thru.snd.one/p/PROXY_ID/repos/octocat/Hello-World/issues' \
  -H 'Authorization: Bearer AGENT_ACCESS_TOKEN' \
  -H 'Accept: application/vnd.github+json'

# Thru adds the user's GitHub token server-side.
# The agent gets the API response, never the stored key.

Two different keys. AGENT_ACCESS_TOKEN authenticates to Thru. The user's API key authenticates to GitHub and stays inside Thru.

A connection that fits

One key. A few keys. Your API.

Describe the credential fields once. Thru handles the authentication on every request.

Bearer tokens

The familiar API key.

GitHub, DigitalOcean, and any API that expects an authorization header.

Authorization:
Bearer {{api_key}}

Custom headers

More than one secret.

Give each value its own field. Map them into exactly the headers your API needs.

X-Client-Id: {{client_id}}
X-Api-Key: {{api_key}}

AWS Signature V4

Signed on the way out.

Provide an access key, secret key, and optional session token. Thru signs the request.

auth.type: aws-sigv4
service + region + key fields

Access is still access. Make it intentional.

Choose narrowly scoped provider credentials, verify the destination belongs to a trusted provider, and limit a connection to read-only methods when possible. Your agent can use the API within those permissions until the connection expires or you revoke it.

Good things to know

Clear boundaries.
Fewer surprises.

What does my agent get to see?

The connection's configuration, status, and API responses. It gets its own Thru access token, which lets it use the connection. Your stored provider credentials are encrypted and never included in the connection object. Use a trusted API provider: it controls the responses returned by its endpoints.

Where do I get my API credentials?

Your agent can tell you where to create the credentials and include a link to the provider's credentials page. Open the Thru setup link, review the destination, and enter the values there yourself.

Can I stop a connection?

Yes. After connecting, save your private management link. It lets you check the connection and revoke access at any time. Connections also expire automatically; the setup and management pages show the expiration time. Connections last 24 hours by default and can be configured for up to seven days. Setup links expire after one hour.

Does my API need to support Thru?

No. Thru forwards standard HTTP requests to the configured API destination, injects the header credentials you define, or signs AWS requests. Your agent uses the proxy URL in place of the API base URL. Responses currently support UTF-8 text, JSON, and XML up to 1 MB. Redirects, binary responses, and opaque compressed responses are blocked.

Give agents access.Keep your keys.