Hook your agent up to your APIs without handing it the keys
Sprites connect seamlessly to any HTTP API through the API Gateway. Connect the service once and the gateway injects the credentials. The raw token never lands inside the Sprite where an agent can read it.
What the gateway actually does
From inside a Sprite, calling an external API looks like calling a plain HTTP endpoint with no auth attached:
curl https://api.sprites.dev/v1/gateway/github/user/repos
See? No token in that request. You select which Sprites get access to each connection. The API gateway finds your org's connection, injects the real credentials, and proxies the call. The response streams back as if the Sprite had called the API directly. What the Sprite never gets is the key: that stays in the control plane (encrypted) and is attached to the request on the way out.
This is why you can safely run agents and their integrations (along with the code they generate) in Sprites. An agent that never holds a raw token can't leak it, log it, or ship it off in a curl to somewhere it shouldn't. You get the reach of a fully credentialed client with none of the exposure.
Connect a service once
Connect a service once at the org level, and it becomes a named connection that any authorized Sprite can use. OAuth providers like GitHub and Slack go through the normal authorize-and-grant flow.
OpenRouter connects for model access with your OpenRouter key. Anything else fits the custom connection; point it at a base URL, give it a token and how the token is sent, and you have a connector.
S3-compatible object stores connect the same way, with their own endpoint and credentials. One setup, reused everywhere, instead of a key copied into every environment that needs it.
Agents with connections
More power and efficiency, without sacrificing security
-
Every model behind one connection
Want to try the latest model blowing up the "trust-me-bro" benchmarks? Your OpenRouter connector puts a huge catalog of models behind a single OpenAI-compatible endpoint. Your agent asks for a model by name and the gateway routes the call, streams the tokens back, and keeps a running tally of what was used.
-
The key never enters the sprite
The credential lives in the control plane, and is injected per request on the way to the provider. Your agent works with your real services while never being able to read the secret behind them. That is Spriteish behavior: hardware isolation around the environment, controlled egress out of it, and a way to hold real API access without the raw token ever touching the box.
-
Scope every connection
A connection is not all-or-nothing. No Sprites can use it by default, and you grant access deliberately. Connect all Sprites with a specific label, or those whose name starts with a given prefix.
You scope the endpoints too, with allow and block patterns on the request path: a connection can permit posting messages on Slack and refuse everything else.
Fresh token, self service discovery
When OAuth tokens expire, the gateway refreshes them. A connection you set up months ago will still work without anyone having to rotate a token by hand. Sprites don't have to guess what they can reach.
A single list call returns the connections that are ready to use, each with its base URL, granted scopes, and a copy-paste example, alongside the providers still available to set up.
When an agent wants a permission it doesn't have, the same response points it at the URL to request more scopes. The agent discovers and uses its own integrations, and you decide what shows up there.
Frequently asked questions
What is the Fly.io Sprites API Gateway? +
It is a proxy that lets a Fly.io Sprite call external APIs like GitHub, Slack, and OpenRouter without holding the credentials. You connect a service once at the organization level, and the gateway injects the stored credentials and forwards each request, so a Sprite reaches your real services while the raw token stays in Fly.io's control plane.
Do I have to put API keys inside a Sprite to call external services? +
No. That is the whole point of the gateway on Fly.io. A Sprite calls the gateway URL with no token attached, and the gateway adds the credentials on the way to the provider. The key is never written to the Sprite, so an agent or the code it runs cannot read or leak it.
What services can I connect through Fly.io? +
GitHub and Slack connect over OAuth, OpenRouter connects for model access with a key you supply, and any other HTTP API connects as a custom connection using a base URL and token. S3-compatible object stores connect the same way. Each becomes a named connector that authorized Sprites on Fly.io can use.
Can I call LLMs through the gateway with OpenRouter? +
Yes. OpenRouter is a first-class connection on Fly.io, and it reaches a large catalog of models through one OpenAI-compatible endpoint. You connect it with your own OpenRouter key, and your agent calls models through the gateway while the key that pays for them never enters the Sprite.
How does the gateway know which Sprite is calling? +
Each Fly.io Sprite has its own platform-issued identity, and the gateway authenticates the request by that identity rather than by a key in the request. From there it maps the Sprite to its organization and finds the matching connection, so there is nothing for the Sprite itself to present or store.
Can I limit which Sprites use a connection and which endpoints they can hit? +
Yes. On Fly.io every connection is default-deny, and you grant access to specific Sprites by label or name prefix, or to all of them explicitly. You also scope the allowed request paths with allow and block patterns, so a connection can permit one endpoint, like posting a Slack message, and refuse everything else.
Does the gateway handle OAuth token refresh? +
Yes. The Fly.io gateway refreshes expiring OAuth tokens on its own, so a connection keeps working without anyone rotating credentials by hand. Your Sprites keep calling the same gateway URL, and the fresh token is injected for them each time.
How does an agent find out what it can reach? +
A Fly.io Sprite calls the gateway's list endpoint, which returns the connections that are ready to use, each with its base URL, granted scopes, and a ready-to-run example, plus the providers still available to set up. When more permissions are needed, the response includes a URL to request additional scopes.
Can I connect an API that isn't built in? +
Yes. Alongside the built-in providers, Fly.io supports a custom connection where you supply a base URL, a token, and how the token should be sent, which turns any HTTP API into a connector. S3-compatible object stores are supported the same way, so most services a Sprite needs can go through one gateway.