Skip to content
apikit

Privacy

The privacy story is the product. This page lists every fact about what happens to a key you paste into APIKit.

What happens when you test a key

  1. Your browser POSTs to /api/proxy/<provider> with the key in the x-apikit-key header. The body contains an action like validate or models; it does not contain the key.
  2. The Next.js route handler reads the key from the header, hands it to the provider adapter, and immediately discards it from local scope.
  3. The adapter calls the upstream provider (OpenAI, Anthropic, etc.) with the key in the standard auth header for that provider.
  4. The upstream response is returned to your browser. The key is not retained in any in-memory cache, queue, or log.
  5. The route handler exits. The key is unreachable.

What we do not do with your key

  • We do not log the key, the auth header, the request body, or any field that contains the key.
  • We do not persist the key to any database, file, or disk.
  • We do not include the key in error messages, OG images, share URLs, JWT payloads, analytics events, or telemetry.
  • We do not run analytics on the key value, hash the key, or aggregate keys across users.

Shareable result links

The optional "share redacted result" feature signs a JWT with the provider id, the last 4 chars of the key (for visual identification), the validation status, and a list of model ids. The full key is never in the JWT. The signing secret never leaves the server. Share links can be revoked by rotating the signing secret.

Rotation reminders

If RESEND_API_KEY is configured, you can opt into a 90-day rotation reminder. The signed JWT contains your email, the provider id, and the expiry timestamp. The full API key is never sent to the email service. We do not maintain a database of subscribers — the JWT is the only record.

Server-side logging

Vercel and any deployment platform sees the request method, path, response status, and aggregate latency. Headers — including x-apikit-key — are not included in our application logs. If you self-host, you control the logging stack.

Browser-side storage

We use localStorage only to remember your theme preference. We use sessionStorage briefly for the paste-to-route handoff (the pasted key is stored once and immediately consumed by the destination page). We never set cookies tied to your key.

Page-view analytics

We run first-party page-view analytics via Vercel Analytics. The script is served from the same origin (your browser POSTs events to /_vercel/insights/event and /_vercel/insights/vitals on this domain — never to a third-party host). No cookies are set. No fingerprinting. No third-party scripts.

What is collected, per page load:

  • The path you visited (e.g. /test/openai-api-key) and the referring page's host
  • Country at country level only (derived at the edge from your IP — the IP itself is not stored)
  • Device class (desktop / mobile / tablet) and browser family (Chrome / Firefox / Safari)
  • An anonymous, daily-rotated visitor counter (a hashed signal, not a persistent ID)
  • Web Vitals: LCP, INP, CLS, FCP, TTFB — to find slow pages and fix them

What is NOT collected:

  • Your API key, any prefix of it, or any redaction of it
  • Any request body sent to the proxy
  • Your full IP address, user agent string, or any cross-session identifier
  • Cookies of any kind
  • Mouse movements, clicks, scroll depth, or session replay

If you want to verify, open your browser's Network tab and watch for the /_vercel/insights/* requests — that's the entire surface area of analytics on this site.

Third-party requests

The browser does not load any third-party scripts. No ad networks, no Google Analytics, no Sentry, no font CDNs (fonts are self-hosted via next/font), no trackers. Outbound requests go from our server to the upstream LLM provider you tested, and that's it.

Reporting a security issue

See the security page and /.well-known/security.txt for our disclosure contact.