Each service would normally demand its own contract, its own credentials and its own session handling. A managed key collapses that into one thing: APIFuse keeps every per service credential on its side, and your integration authenticates with a single bearer token. When a service rotates credentials or renegotiates a session, nothing changes on your end.

One key, every service

A managed key is an opaque bearer token issued from the APIFuse dashboard. It may call every service its scopes allow, and a new key carries full scope by default. The key embeds no service credential of any kind, so you can revoke or rotate it at any time without touching anything on the service side.

Live and sandbox keys

The prefix tells you which environment a key belongs to. The two environments are fully isolated: objects created with a sandbox key never reach a real venue or service and are invisible to live keys, and the same holds in the other direction. Apart from the prefix the two kinds of key look and behave the same, so swapping the environment variable value is all it takes to move between environments.

The Authorization header

Every request carries the key in a standard bearer header. There is no query parameter fallback and no per service header. A missing or invalid key returns 401 with code unauthorized in the error envelope.

curl "https://api.frism.dev/v1/catch-table/restaurants?area=seongsu&cuisine=japanese" \
  -H "Authorization: Bearer frism_test_k3xample"

{
  "items": [
    {
      "id": "res_01J8Q9W3TE",
      "name": "Sushi Aoyagi",
      "area": "seongsu",
      "cuisine": "japanese",
      "price_band": "high",
      "bookable_online": true
    }
  ],
  "next_cursor": "cur_9f2kq"
}

The call above is from the .

Storing the key

A managed key is a server side secret. Keep it in an environment variable or a secret manager, and attach it only to requests your backend sends.

• Never put the key in a client bundle, a mobile app or a public repository. Anything the browser downloads is public.
• Route browser and app traffic through your own backend, and let that backend attach the key.
• Use a separate environment variable per environment, for example FRISM_API_KEY, so live and sandbox values never mix.

// Runs on the server only. The key comes from the environment.
const key = process.env.FRISM_API_KEY;
if (!key) throw new Error("FRISM_API_KEY is not set");

const response = await fetch(
  "https://api.frism.dev/v1/catch-table/restaurants?area=seongsu&cuisine=japanese",
  { headers: { Authorization: `Bearer ${key}` } },
);
if (!response.ok) {
  throw new Error(`APIFuse error: ${response.status}`);
}

const page = await response.json();
console.log(page.items[0].name); // "Sushi Aoyagi"

Rotating a key

Rotation needs no downtime because any number of keys can be valid at once. Rotate on a schedule, and immediately whenever a key may have leaked.

1. Create a second key with the same scopes in the dashboard.
2. Deploy the new key to your environment and confirm traffic authenticates with it.
3. Revoke the old key. Requests still using it start getting 401 unauthorized from that moment on.

Linked account services

Most services work with the managed key alone. and are linked-account services that act on behalf of an end user, so that user links their own account to your integration once. Once the link exists, nothing changes about how you call the API: requests still authenticate with the same managed key, and you never see or store the user's service credentials. Scope rules apply exactly as before.

Next, shows how to narrow what a key may call, and the documents the exact shape of 401 and 403 responses.