Create Scoped API Keys for Model Access

Give every application its own key

A Flonno API key is a bearer token: anyone who has the secret can make requests allowed by that key. Create a separate key for each application or environment so that a development token can be revoked without taking production offline. Give it a name that identifies its use, such as website-staging or research-worker.

Choose only the permissions the client needs. Chat completions use the chat:completions permission. Add models:read only when the client needs to list available models. A client that already knows its model ID can call the completion endpoint without requesting model-list access.

• Use a different key for each application and environment.
• Grant chat:completions only when the application sends chat requests.
• Grant models:read only if the application lists models at runtime.

Limit the models and lifetime

In the Flonno dashboard, create a key, select its permissions, choose the model IDs it may call, and set an expiry when the key is temporary. The catalog currently includes qwen3.5-397b-a17b, kimi-k3, gemma-4-31b-turbo, and nemotron-3-nano-omni-30b. Use the exact public model ID shown in the catalog and API response.

A key can allow every model or a selected subset. Prefer a selected subset when the application has a known workload. Flonno offers no expiry or expiry after 1, 7, 30, or 90 days. Short-lived keys are useful for experiments and CI jobs; a permanent key needs a clear owner and a rotation plan.

Flonno shows the secret once after creation and stores a one-way hash. Copy it directly into your server's secret manager or deployment environment. If the secret is lost, revoke that key and create a replacement; it cannot be revealed again from the dashboard.

• Restrict a key to the model IDs the application actually calls.
• Choose an expiry that matches the job or review schedule.
• Copy the secret at creation time and store it outside the repository.

Call the OpenAI-compatible endpoint

Send the token in the Authorization header and use the public model ID in the JSON body. Keep the token in a server-side environment variable named FLONNO_API_KEY; do not embed it in browser JavaScript, a mobile app, or a checked-in configuration file.

curl https://flonno.com/v1/chat/completions \
  -H "Authorization: Bearer $FLONNO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"qwen3.5-397b-a17b","messages":[{"role":"user","content":"Summarize this report."}]}'

Review activity and rotate deliberately

The Activity logs view records the request key, source IP, model, response status, duration, and reported token usage when available. Use those records to spot an unexpected model choice or a key that is no longer needed. A failed request can still appear in the log with its status, so check the response and the dashboard record together when debugging.

When an application changes owner or a token may have leaked, revoke its key and issue a replacement with the same narrow permissions. Update the application's secret, confirm requests succeed, and then remove any old copy from deployment settings. Revocation takes effect for later requests; it does not erase previous activity records.

• Check which named key made a request before changing model access.
• Rotate one application key at a time and verify the new secret works.
• Revoke unused or exposed keys from the dashboard.