IronStratum Get an API key

Privacy Policy

Last updated: [publication date]

This policy describes what IronStratum ("we", "us") does with data when you use api.ironstratum.com, the IronStratum console, and our published API models. It is written to be read, not skimmed past.

If you access IronStratum through a third-party marketplace or similar, your relationship with that marketplace is governed by its terms; this policy describes what we process to deliver the request.

We do not train on your data

We never train, fine-tune, evaluate, or otherwise improve models using your prompts or completions. Not with your permission, not by default, not "anonymized". This is a contractual commitment, not a policy preference; it also appears in our Terms of Service.

What we collect

Account data: email address, organization name, hashed password (argon2id), session tokens. We need it to give you an account and keep others out of it.

API keys: keys are shown once at creation and stored in hashed form. We cannot retrieve a key after creation; neither can anyone else.

Billing data: payments are processed by Stripe. Card data never reaches our servers. We store wallet balances, credit purchases, and per-request billing records.

Usage metadata, per request: model, token counts (including cached and reasoning breakdowns), latency, cost, request ID, timestamps, upstream status codes, and, if you send them, the HTTP-Referer and X-Title attribution headers. This is what our usage ledger is made of; it is how billing, the console usage views, and the per-request cost field in our API responses work.

Server access logs: like most web servers, we keep standard request logs for api.ironstratum.com, app.ironstratum.com, and ironstratum.com: source IP address, timestamp, requested URL, referrer, browser user-agent, response status, and transfer size. Retained up to 30 days, then deleted by log rotation; used to diagnose abuse and errors and to produce aggregate (IP-anonymized) traffic statistics. Never sold, never shared, not used for ad targeting.

Site analytics, marketing pages only: the public pages of ironstratum.com use Google Analytics to count page views. When you load one, Google's gtag.js sets cookies in your browser and receives the page URL, referrer, and browser user-agent for that visit. It never touches api.ironstratum.com, the console, or anything behind a login, and we do not use it for ad targeting. This is the only client-side tracking on the site.

Conversation content (prompts and completions): stored for continuity. When you send a request with a session_id, or any chat completion against a conversation-storing deployment, we store the exchanged turns (your prompts and the model's completions) so the conversation can continue on your next request without you resending history. This is the sole purpose: session continuity. Retention below; deletion controls below; and it does not change the no-training commitment in any way.

Two further, narrow content retentions exist regardless of conversations:

  1. Idempotency replay cache: if you send an Idempotency-Key header, we hold the request and response for up to 10 minutes so a retried request returns the original answer instead of a duplicate charge.
  2. Error excerpts: when a request fails against an upstream, we retain a ≤1 KiB excerpt of the request body in our debug log for 30 days, to diagnose the failure.

Where processing happens

Every model in our catalog is one of two kinds, identified per-model in our /v1/models endpoint and documentation:

In both cases: metadata comes back to us for billing and observability; your content goes only where it must to return an answer.

Retention

DataRetained
Conversation content (turns)30 days by default (inactivity-based), sooner if you delete it; see Your controls
Idempotency replay cache≤ 10 minutes
Error excerpts (≤1 KiB)30 days
Server access logsUp to 30 days (deleted by log rotation)
Usage metadata, account dataWhile your account is active, then as required by accounting and tax law
Billing recordsAs required by accounting and tax law

Retention detail, stated plainly: a conversation that goes inactive is aged out by the 30 day retention window (a shorter window can be configured per deployment); deleting a conversation removes its turns immediately and permanently: deletion is final, a deleted session_id is never revived. What survives deletion is the anonymized financial ledger: per-request billing rows (token counts, cost, model, timestamps) kept detached from the conversation and its content, because financial records must stay reconcilable.

Closing your account deletes your account data and API keys; billing and usage records survive only where accounting/tax law requires, detached from your login identity where feasible.

Who we share it with

Security

TLS for everything in transit. Passwords hashed with argon2id; API keys stored hashed; keys revocable instantly from the console. Every response carries an x-request-id you can quote to us for exact-request diagnosis; one of the reasons our logs can stay metadata-only.

Your controls

Export your usage history from the console or via the API. Delete any conversation, or every conversation of your account, from the console's Conversations page or via the API (DELETE /v1/conversations/{id}, DELETE /v1/conversations): content goes immediately, anonymized billing rows survive as described under Retention. Revoke any API key at any time. Close your account from the console or by contacting us. Ask us what metadata we hold about you: the metadata-plus-conversation design makes this a query we can actually answer precisely.

Changes

If we change this policy in a way that reduces a commitment above, we will notify account holders in advance. The no-training commitment will not be reduced.

Contact

[contact email: owner to set, e.g. privacy@ironstratum.com]