Providers

Salyro does not resell model access. You bring your own accounts with the model providers, connect their credentials to a gateway, and your requests are fulfilled against your own provider accounts — billed by the provider, at the provider's rates.

That model is the reason this page exists. Handing a provider key to a third party is the decision that has to be justified before anything else about the product matters, so what follows is what happens to that key, stated precisely enough to be checked.

The four providers

• OpenAI
• Anthropic
• Google Gemini
• Grok (xAI)

These four are supported from the first day. Text and vision input are the supported modalities; embeddings, image generation and audio are not part of this version. Which models a credential opens up is a property of the provider account behind it, and the identifiers you send in a request are documented in the Public API reference rather than here.

A credential belongs to one gateway

A provider credential is connected to a single gateway and is not shared with any other. Two gateways calling the same provider hold two credentials, even when both were issued from the same provider account.

There is no account-level credential store. This follows from the gateway being the isolation boundary: a credential reachable from every gateway would make the boundary decorative.

When you connect a credential, it is checked against the provider before it is saved, so a mistyped or already-revoked key is caught while you are configuring it rather than during a real request.

What Salyro commits to

Four commitments, which together are the whole answer to what happens to the key after you paste it:

1. It is encrypted at rest in AWS Secrets Manager

   Credentials are held in AWS Secrets Manager, encrypted under a KMS key. Secrets Manager is the only channel through which a secret is written or read.

2. It is never stored in the product database

   The database row that represents a credential holds the provider it belongs to, a name you chose, its status, and a pointer to the secret. The key itself is not among them, in any form.

3. It is never written to a log

   Neither the technical logs Salyro operates on nor the request logs you read carry a provider key. Everything attached to a technical log record passes through a redaction step first, so a key that reached one by accident — in an error message, a stack trace, an upstream response — is replaced before the record is written.

4. It is never returned to you after it is saved

   There is no read path for a saved credential. The dashboard shows the provider, the name, the status and the date, and never the value. If you need the key itself again, it comes from the provider, not from Salyro.

The credential is fetched from Secrets Manager while a request is being served, used for that request, and not retained afterwards.

Replacing a credential

Rotating a provider key means replacing the value held for an existing credential. The gateway, its API keys and its settings are untouched, so nothing downstream has to be reconfigured — requests served after the replacement use the new value.

Because the old value cannot be read back out of Salyro, the order of operations matters: create the new key at the provider, update it here, confirm requests still succeed, and only then revoke the old key at the provider. The guide Rotate a provider credential without downtime walks through it.

Revoking a credential at Salyro removes the gateway's ability to call that provider. Requests naming a model that credential served will fail from that point, which is the intended effect and the reason it is a deliberate action.