How Plan2API protects your logins and keys

What Plan2API stores and what it never keeps

Plan2API keeps only what it needs to route requests and show the dashboard. Whether you are connecting a Claude plan or another subscription, the login tokens themselves stay sealed inside your vault.

How a request opens your vault

When you make an API call, Plan2API opens your vault in memory for that single request:

1. Your request sends the Authorization: Bearer header with your p2a_ key, and its 16-character key id finds the key's slot in memory, so unknown ids are turned away without a database lookup.
2. Plan2API derives a check value from the key's 43-character secret using HKDF-SHA256 and the key's own random 16-byte salt, then compares it with the stored check value in constant time.
3. A second HKDF-SHA256 derivation gives a key-encryption key that unwraps the vault master key (AES-256-GCM).
4. The vault master key unwraps the vault's X25519 private key (AES-256-GCM).
5. The private key opens the sealed login for the provider being called (HPKE).
6. Plan2API calls the provider, and if the provider token is refreshed, the new token is sealed again within the same request.

The unwrapped vault master key lives only for the request that presented the key and isn't cached between requests, so logins are read and decrypted again for each request.

The vault v2 encryption

Every vault has its own X25519 key pair, and each layer is bound to the ids in the table below, so a sealed value fails to open if it is moved to another key, vault, credential or provider.

The vault's X25519 public key is stored as is, so when you connect a subscription in the dashboard while signed in with Google, the login is sealed into your vault without needing your API key. Only the vault's private key can open that sealed login, and unwrapping the private key takes an API key. Because each API key wraps the same vault master key under its own HKDF-SHA256 key, every key on your account opens the same vault, and revoking one key leaves the others working.

Older v1 logins, which were sealed with AES-256-GCM directly under the vault master key, still open as usual, and every new write seals with v2. The HPKE mode follows RFC 9180.

What Google sign-in can and can't do

You sign up with a Google account, and that browser session manages your account settings and dashboard, but it can't read your sealed logins or open your vault. With only a Google sign-in, you can:

• Connect new subscriptions so they get sealed to your vault's public key.
• Rename and revoke keys, except for the vault's last key, which fails with 409 last_key ("This is the vault's last key. Reset the vault instead if you lost it.").
• Mint a new key only by pasting an existing key, because minting has to wrap the vault master key, which only an existing key can unwrap.
• Reset the vault or delete the account after a fresh sign-in.

A vault reset requires a Google sign-in from the last 5 minutes: it deletes every key and every connected login, keeps your usage history and logs, and creates a new vault with a new key so you can reconnect each subscription. There is no recovery from a reset, because without an API key nobody, Plan2API included, can decrypt the old logins. Account deletion also takes a recent sign-in and removes your account, vaults, keys, connected logins, call logs and usage totals right away; deleted data can still sit in older encrypted backups, where the logins stay locked under a key Plan2API never had.

What the vault protects against, and what it doesn't

If a database or backup ever leaks, it holds only sealed logins, one-way check values and wrapped keys. None of that opens without one of your p2a_ keys, and the 43-character random secret (about 256 bits) in each key is never stored. A hijacked Google session can't read your logins or mint new keys on its own either.

The vault doesn't protect against a stolen API key or a compromised host. Anyone holding your p2a_ key can use your connected subscriptions until you revoke the key on the Keys page at plan2api.com/dashboard/keys, and someone in control of the live server could use your logins while requests are actively running.

Logs, hosting and provider sign-in

Plan2API reads keys only from the Authorization: Bearer header (detailed in the API reference) and refuses x-api-key with 401 invalid_api_key. Request logs record the key id as vault:<key id>, never the key itself, and call logs are kept for 7 days on Free, 30 days on Pro and 90 days on Scale (see plan details and pricing). Servers and the database run on OVHcloud in Germany with Cloudflare in front, encrypted backups stored with Cloudflare, and TLS used everywhere. The service uses Firebase for Google sign-in, Cloudflare, OVHcloud, Stripe as merchant of record for billing, Postmark for email and Clicktag for cookieless analytics, with no ads, no data sales and no model training on API data.

When you connect a subscription, for example when using a ChatGPT plan as an API, the sign-in happens on the provider's side: Claude uses a sign-in link and a pasted code, ChatGPT uses a one-time device code, Gemini uses Sign in with Google, and Kimi takes a Kimi Code API key. Because you authenticate directly with them, Plan2API never sees your Claude, ChatGPT or Google password.