Frontend-safe Keys | Proxyify Docs
Docs Frontend-safe Keys

Frontend-safe Keys

How to call the Proxyify API from a browser or mobile app without exposing your permanent API key.

The problem

Your prx- API key is tied to your account's full credit balance. If you embed it in client-side JavaScript, anyone who views your source can steal it, run requests on your account, and drain your credits.

Never put a prx- key in browser JavaScript, a React/Vue/Svelte bundle, a mobile app binary, or any code that ships to end users.

Solution

Two approaches, depending on your architecture:

Option 1 — Server-side proxy

Your backend holds the prx- key and makes requests to Proxyify on behalf of your users. Your frontend talks only to your own backend.

architecture
Browser → Your API → Proxyify → AI Provider (holds prx- key)

This is the safest approach. Add your own auth layer so only your logged-in users can trigger requests.

Option 2 — Ephemeral tokens

Your backend issues a short-lived bt- token scoped to a single user session. The browser uses this token directly with Proxyify.

architecture
Browser → Your API → POST /api/keys/ephemeral → bt-token Browser → Proxyify (using bt-token, expires in 1h)
Python (backend — issue token)
import requests # Call from your server, never from the browser res = requests.post( "https://proxyify.dev/api/keys/ephemeral/", headers={"Authorization": "Bearer prx-xxxxxxxxxxxxxxxx"}, json={"key_id": 42, "ttl": 3600}, ) token = res.json()["data"]["token"] # "bt-xxxxxxxxxxxx" # Return this token to the authenticated browser session
JavaScript (browser — use token)
const client = new OpenAI({ apiKey: btToken, // "bt-xxxxxxxxxxxx" from your server baseURL: "https://proxyify.dev/v1", dangerouslyAllowBrowser: true, }); const res = await client.chat.completions.create({ model: "openai/gpt-4o-mini", messages: [{ role: "user", content: userMessage }], });

When the token expires (after the TTL you specified), the next request returns 401. Your frontend should catch this and request a fresh token from your backend.

Recommended restrictions

For any key used in a client-facing context, apply these restrictions in the dashboard:

  • allowed_origins — lock to your domain (e.g. myapp.com)
  • allowed_categories — restrict to only the modalities your app needs
  • spending_limit — cap how much any one key can spend per day/week
  • allowed_models — allowlist specific models if possible