Gateways
The unit of isolation the product is built around — what a gateway owns, what isolation means in practice, and when to use more than one.
A gateway is the boundary everything else in Salyro sits inside. Requests are sent to a gateway, and the credentials that fulfil them, the keys that authenticate them, and the records of what happened all belong to that gateway and to no other.
Deciding how many gateways to create is therefore an architectural decision rather than a setup step. It determines how your costs break down, how far a leaked key reaches, and which requests can be told apart from which afterwards.
The hierarchy is flat
An account owns gateways. That is the whole of it — there is no organization, no team and no project layer between them, and none is planned for this version.
The flatness is deliberate. A gateway is already the isolation boundary, so a second grouping above it would be a second answer to the same question, and the two would disagree the first time somebody moved something.
What a gateway owns
Six things belong to a gateway, and none of them is shared with another:
- Provider credentials — your OpenAI, Anthropic, Google Gemini and Grok keys, connected to this gateway
- Salyro API keys — the keys your code authenticates with
- Request logs — one record per request that went through it
- Conversations — the prompts and responses themselves
- Usage and cost — tokens and the cost computed from them
- Settings — including the rate limits attached to its keys
There is no account-level pool of provider credentials that gateways draw from. If two gateways both call OpenAI, each one holds its own credential, even when both credentials come from the same OpenAI account.
What isolation actually means
The list above is worth little as a list. It is worth something as four consequences you can rely on:
- A Salyro API key issued by one gateway does not work against another. There is no key that spans gateways.
- Usage and cost accumulate per gateway. A figure for one gateway is a figure for the traffic that went through it, with nothing else mixed in.
- Logs and conversations are visible within the gateway that produced them.
- Rate limits are set per API key, and a key belongs to one gateway — so traffic through one gateway cannot consume another's allowance.
Disabling a gateway blocks all of its API keys at once, without discarding the history behind it.
When to use more than one
Three reasons come up in practice, and all three are the same reason seen from different angles — you want something separated that a single gateway would merge.
Environments
A gateway per environment keeps a development experiment out of production's cost figures, and keeps a development key from reaching production's provider credentials.
Cost attribution
Usage breaks down by gateway, so a gateway per feature, per customer or per team is what makes “what did this cost us” answerable. It has to be decided before the traffic runs, not after.
Blast radius
A leaked key reaches one gateway. Splitting the surfaces that hold keys is what decides how much of your traffic a single leak affects.
What the gateway boundary does not do
Routing through Salyro is pass-through. A request names a model, and it goes to the provider that owns that model.
There is no smart routing, no automatic failover to a second provider, and no load balancing across providers. This is a decision rather than an omission: it is what makes the behaviour predictable, and what lets a log say exactly where every request went. A provider that fails is a failure you receive, not one Salyro quietly routes around.
Budgets and spend limits are not enforced. Rate limits per API key are — see API keys — but nothing in the product stops requests because a cost threshold was reached.