Privacy Policy

01What this covers

This describes what seams collects when you use the gateway, the console and the hosted portal, what we do with it, and how long we hold it. It applies to you as our customer, and to the end users you provision keys for.

You are the controller of your end users' data and we are your processor. What you tell your customers about their data is your responsibility; what we do with it is described here.

02What we do not store

We do not store prompt or completion content. Not in logs, not in the usage record, not in a debug buffer. The record a request produces has no messages field, no prompt field, no completion field and no body field, and there is no configuration that adds one.

This is a property of the data model rather than a setting. Request and response bodies pass through the gateway to the provider and are not written down on the way.

03What we do collect

Enough to bill correctly and to show your customers what they used.

• Account data: your organisation name, the email addresses of your staff, and authentication material for the console.
• End-user identifiers you supply when minting a key, typically an email address or an internal id, stored as the actor label so usage can be attributed.
• Request metadata: timestamp, model alias, resolved provider model, token counts, latency, status and computed cost. No content.
• Ledger entries: credits granted, holds taken, charges settled, all as integer micro-dollar amounts.
• Ordinary operational data such as IP address and user agent for requests to the console and portal, used for security and abuse prevention.

04Provider credentials

If you bring your own provider key, it is encrypted with a cloud KMS key before it is stored. Plaintext exists only inside the request that needs it, in memory, for the length of that request.

Resolved credentials are never written to a cache that persists to disk or replicates over a network, never logged, and never included in an error message. The object holding one throws if something tries to serialise it.

05Who else sees it

Your requests reach the model provider you have selected, because that is what the product does. Their handling of that traffic is governed by their terms, not ours, and you should read them.

Beyond that we use a small number of subprocessors for hosting, databases and payments. We do not sell data, and we do not use your traffic or your customers' traffic to train anything.

06How long we keep it

Usage records and ledger entries are retained while your account is open and for as long afterwards as tax and accounting rules require, because they are the evidence behind invoices.

The ledger is append-only by design: entries are never edited or deleted in place. A correction is a new entry, which is what makes an audit trail worth having.

Account data is deleted within thirty days of you closing your account, other than records we are required to keep.

07Your rights

You can export your account's usage and ledger data at any time from the console or the API. If you need access, correction or deletion for an end user, contact us and we will act on it within thirty days.

Because we do not hold prompt or completion content, a content deletion request has nothing for us to delete, which is the point of not collecting it.

08Changes

If this document changes in a way that materially affects you, we will tell you before it takes effect. The date at the top always reflects the current version.