Public beta security
Security at API Many
Last reviewed August 29, 2026. API Many is in public beta. This page describes present design practices, not a certification, audit report, service-level agreement, or guarantee that an incident cannot occur.
Current controls
Credential handling. Customer API key secrets are displayed once. The service retains a one-way hash and limited identifying metadata. Upstream provider credentials stay in server-side configuration and are not included in the public model response.
Transport and browser boundaries. Production traffic is intended to use HTTPS. API requests use Bearer authentication, authenticated account actions use secured sessions and same-origin checks where applicable, and payment webhooks are verified by the billing integration.
Request accountability. Accepted requests receive a gateway record with model, route attempt, status, usage, balance reservation, and billing metadata. Idempotency and conservative handling of uncertain outcomes are used to reduce accidental duplicate provider submissions and charges.
Provider isolation. Public model IDs are separated from private route credentials and upstream model names. Health and circuit state can exclude a failing route. We do not automatically send an uncertain request to another provider when the first provider may already have accepted it.
Payments. Stripe processes payment-card details. API Many does not receive or store a full card number.
Public-beta limitations
We do not claim SOC 2, ISO 27001, PCI certification, penetration-test coverage, a bug bounty, 24/7 monitoring, a recovery-time objective, or a response-time commitment unless a separate written document expressly says so. Do not use the public beta for regulated or safety-critical workloads without a written review of the required controls and eligible provider route.
Your responsibilities
Keep API keys only in server-side secret storage; never embed them in a public website, mobile application, repository, log, or support message. Use separate keys for separate environments, revoke unused keys, rotate a suspected key immediately, restrict access to the account, validate user input, set reasonable token and spending limits, and avoid submitting secrets or regulated data in prompts.
Report a vulnerability
Email [email protected] with “API Many security report” in the subject. Include the affected URL or component, steps to reproduce, impact, and a safe proof of concept. Do not include an API key, customer data, destructive payload, or data obtained from another account. Wait for a safe exchange method before sending sensitive evidence.
Please avoid privacy violations, persistence, social engineering, denial of service, automated high-volume scanning, changing data you do not own, or accessing more information than needed to demonstrate the issue. We do not currently offer a bounty or promise a response deadline. We will use the contact details you provide to investigate and coordinate an appropriate fix or disclosure.
Security incidents
If we confirm an incident, we will investigate, contain, and notify affected users or authorities when required by law. The status page explains the limits of public beta status reporting. For suspected key compromise, revoke the key first and then contact support with its name or last four characters—never the secret.