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.

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; a revoked key stops authenticating immediately. 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 current surfaces mint, but a bare as_… prefix is a real legacy format that some paths still generate and that still authenticates — 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. There is no alias between them — set the one your runtime actually reads.

Plane	Env var	Notes
SDKs — Next.js, Express, .NET (`ApiKey` option)	`CHECKPOINT_API_KEY`	Read by the Checkpoint SDK packages directly.
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.

The Project ID has the same split: SDKs and dashboard config read a plain projectId/ProjectId, while the worker/deploy plane reads AGENTSHIELD_PROJECT_ID (the project's friendly ID).

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

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

Credentials