Where to find your Project ID and API key, and which env var each Checkpoint plane reads

Every Checkpoint integration needs a Project ID. Server-side integrations — Middleware, Gateway, .NET, a Govern/KYA-OS server — also need an API key; the browser surfaces (Pixel and Beacon) do not take one at all, since nothing in a page can hold a secret. This page is the single source for where to find both, what they look like, and which environment variable each runtime reads.

Prerequisites

A Checkpoint account with at least one project created.

Where to find them

Open Installations in the project's left-rail navigation (/dashboard/{orgId}/{projectId}/installations). Starting the Detect setup flow there (Configure & install → pick a layer) shows install snippets with your Project ID and, for the server/middleware layer, a live API key pre-filled into the code sample — copy them directly out of the snippet.

You can also ask the dashboard assistant for a project's credentials; it renders a card where you generate the API key and copy it.

Installations ships the Detect capability card today. If your integration is Enforce or Govern only, the same Project ID and API key values still apply — they're per-project, not per-capability.

Project ID

A name-based slug (e.g. acme-corp), or a UUID for older projects.
The same Project ID is used everywhere: the Pixel's data-project-id attribute, the Beacon's projectId config, and the .NET SDK's ProjectId option.

API key

Format: sk_ followed by a random hex string, e.g. sk_a1b2c3d4…. The exact length depends on which surface minted the key (dashboard-created keys are 64 hex characters; keys minted by a managed deploy are 48), so match on the sk_ prefix rather than on a fixed length.
API keys can be project-scoped (tied to one project) or user-scoped (not tied to any project) — the dashboard derives this from whether a project is attached.
Keys can be revoked at any time; revocation takes effect immediately on the instance that revoked the key, but the API-key validator caches valid keys for up to 5 minutes, so another running instance can keep accepting a revoked key until that cache entry expires. There is no separate "rotate" action — revoke the old key and create a new one.

as_live_… is not a real Checkpoint API key format. If you see that shape in older docs or examples, treat it as an error. Note the narrower claim: sk_… is what every current minting path generates. A bare as_… prefix is a real legacy format that no current path generates, but a key minted under that old scheme still authenticates if it was stored and never revoked, so validate by looking the key up, never by asserting a prefix.

Which env var to use

Checkpoint has two separate naming conventions for the same underlying dashboard API key, depending on which plane is reading it. For in-process SDKs there is no alias: set the one your runtime actually reads. The generated worker/deploy runtime is the exception: it prefers CHECKPOINT_API_KEY and falls back to AGENTSHIELD_API_KEY when only that name is set, and managed deploys provision both, so either works there.

Plane	Env var	Notes
SDKs — Next.js, Express, .NET (`ApiKey` option)	`CHECKPOINT_API_KEY`	Pass via the `apiKey`/`ApiKey` config option; the in-process Next.js and Express middleware and the .NET SDK require it explicit, with no environment fallback. The Next.js API client (`withCheckpointApi`) is the exception: it also reads this from the environment when `apiKey` is omitted.
Managed-deploy worker, self-hosted KYA-OS server, `AGENTSHIELD_*`	`AGENTSHIELD_API_KEY`	The worker/deploy/self-host naming convention. Set by managed deploys as a Cloudflare Worker secret alongside `CHECKPOINT_API_KEY`; the generated worker prefers `CHECKPOINT_API_KEY` when both are present.

The Project ID has the same split: SDKs and dashboard config take a plain projectId/ProjectId option, while the generated worker/deploy runtime prefers CHECKPOINT_PROJECT_ID and falls back to AGENTSHIELD_PROJECT_ID (the project's friendly ID); deploys provision both. The docs' own examples pass the Project ID from CHECKPOINT_PROJECT_ID (or NEXT_PUBLIC_CHECKPOINT_PROJECT_ID for browser surfaces): that's what the worker plane reads directly, but the in-process Next.js, Express, and .NET SDKs still need it passed as an explicit projectId/ProjectId option, not read from that env var.

Other environment variables the SDKs read

Beyond the API key, the @kya-os/checkpoint-nextjs API client (withCheckpointApi) reads these directly when the corresponding config field is omitted. CHECKPOINT_DEBUG is the exception: the API client combines it with the debug option by OR, so its logging turns on if either one is true and debug: false alone will not silence a CHECKPOINT_DEBUG=true environment; clear both to turn it off. The withCheckpoint middleware reads only its own debug option. All are optional.

Env var	Config equivalent	Effect
`CHECKPOINT_API_URL`	`baseUrl`	Override the API base URL (staging, self-hosted).
`CHECKPOINT_USE_EDGE`	`useEdge`	Set to `false` to call the Vercel-hosted API instead of the edge detection gateway. Any other value leaves it on.
`CHECKPOINT_DEBUG`	`debug`	Set to `true` to log detection decisions and errors to the console. Enabled when either this or `debug` is true; see note above.
`CHECKPOINT_SECRET`	`encryptionKey`	Encryption key for the session tracker. Set this in production — it otherwise falls back to a shared default.

The Beacon takes no API key. BeaconConfig accepts a projectId and nothing else credential-shaped — it runs in the browser, where an API key could not be kept secret anyway. If you are looking for where to put one, you do not need one.

Next Steps

Quick Start — first integration walkthrough
Middleware Enforcement — uses CHECKPOINT_API_KEY / ProjectId
Dashboard Deploy — where AGENTSHIELD_API_KEY is provisioned

Credentials