Skip to content
VAIF Studio Docs
By meaning

Key types

Project API keys carry their role in their prefix, so the right key ends up in the right place.

Quick reference

Section titled “Quick reference”
Prefix Role Row rules Safe in browser bundles? Where to use it
vk_pub_… anon Apply Yes Web and mobile apps
vk_srv_… service_role Bypassed No Servers, cron jobs, CI scripts, admin tools
vaif_… legacy Apply Depends on its scopes Keys created before the split, and extra secret keys you create

vk_pub_… (anon)

Section titled “vk_pub_… (anon)”

The default key for client code. It identifies the project but not a user. Row rules decide which rows each request can see; the signed-in user is identified by the access token sent as Authorization: Bearer <token>.

import { createVaifClient } from "@vaifstudio/client";


const vaif = createVaifClient({
  baseUrl: "https://api.vaif.studio",
  projectId: process.env.VAIF_PROJECT_ID,
  apiKey: process.env.VAIF_PUBLISHABLE_KEY, // vk_pub_…
});

vk_srv_… (service_role)

Section titled “vk_srv_… (service_role)”

The secret key bypasses row rules: every row in every table is visible. Use it only where the code itself is the trust boundary: server handlers, background jobs, scripts and migrations.

import { createVaifClient } from "@vaifstudio/client";


const admin = createVaifClient({
  baseUrl: "https://api.vaif.studio",
  projectId: process.env.VAIF_PROJECT_ID,
  apiKey: process.env.VAIF_SECRET_KEY, // vk_srv_…
});

The API refuses a vk_srv_… key sent from a browser origin, and the SDK logs a warning when one is used where window exists. Other client runtimes cannot always be detected, so the rule stands: never ship a vk_srv_… key to a client.

Legacy vaif_… keys

Section titled “Legacy vaif_… keys”

Projects created before the split have vaif_… keys with the legacy role, and secret keys you create on Security > Credentials start with vaif_ too. They keep working. To get the vk_pub_ / vk_srv_ pair on an older project, call POST /projects/{projectId}/api-keys/split with a console access token; it issues the pair and leaves the existing keys in place, so you can move clients over and then revoke the old key.

If a secret key leaks

Section titled “If a secret key leaks”
  1. Rotate or revoke it on Security > Credentials.
  2. Put the new key in your server configuration.
  3. Review the project’s audit log under Security > Audit for activity you don’t recognize.
Section titled “Related”