Trust

Security at Selora

What we store, what we deliberately do not store, and how keys and money are handled. This page describes the system as it runs today.

Last updated 2026-11-08

API keys

A key is generated once and shown once. Only a SHA-256 hash and a short hint are stored, so a copy of the database cannot be replayed against the API.

  • Per-key scopes: model allowlist, RPM, spend limit, expiry
  • Revocation takes effect on the next request
  • Session tokens cannot call inference; API keys cannot manage the account

Prompts and responses

Request bodies and completions are not written to our database. The usage table records what billing needs: model, token counts, cost, latency, status and error code.

  • Request-body logging is disabled at the HTTP layer
  • Prompt text, attachments and outputs are not persisted
  • Network metadata is a one-way hash plus a country code, aged out after 90 days
  • Content is transmitted to the model provider that serves the request

Transport

Traffic reaches Selora through Cloudflare over TLS, with HSTS published at the edge and at the origin. The gateway and the console talk over loopback inside the host.

  • TLS 1.2+ with HSTS (one year, includeSubDomains)
  • No cross-origin calls to the gateway from the browser
  • Payment pages are hosted by the payment provider, not by us

Money and ledger

Money is stored as exact micro-units, never floating point. Credits are posted through one ledger path with an idempotency key, and a repeated callback cannot credit twice.

  • Payment webhooks are signature-checked before anything is credited
  • An unrecognised payment status is never credited
  • Corrections are separate audited rows; ledger entries are not edited

Accounts and access

Passwords are hashed with scrypt and a random per-password salt. Console sessions are signed tokens with an expiry; the free trial is bound to a verified Telegram account.

  • Email codes are single-use and time-limited
  • Admin actions are recorded against the operator account
  • Account deletion is available from the console

Operations

The API runs as an isolated service behind a reverse proxy, with health checks, restart supervision and structured logs that carry request metadata rather than payloads.

  • Provider credentials are read from a protected config file, never from the database
  • Provider keys are held per deployment, not per customer
  • Status and incident history are public on the status page

What we do not do

Sell or share your data

We do not sell customer data, and we do not use your prompts to train models.

Train on your traffic

Prompts and completions are not retained for training or evaluation.

Store card numbers

Card and wallet payments are handled on the payment provider’s hosted page.

Sub-processors

To answer a request, its content is sent to the model provider serving that model, and payment details are handled by the payment provider for the rail you choose. We keep a current list on request for teams that need it for their own review.

Report a vulnerability

Send a description and reproduction steps through the contact page. Include the affected endpoint and the impact you observed. We will confirm receipt, keep you updated while it is fixed, and credit you if you want to be named. Please do not test against other customers' accounts or run load tests without asking first.

Contact the teamSystem status