Releases & environments

SDK release/environment/dist/commitSha vs Settings API keys — two different ‘environment’ ideas.

Two different “environment” ideas

Concept	Where	Purpose
Settings → Environments / API keys	Dashboard project settings	Named API keys that all ingest into the same project; use different keys for staging vs production apps if you want operational separation
SDK `environment` option	`HumanBehaviorTracker.init`	String tag stamped on error reports (e.g. `production`, `staging`) for Issues filters

They are independent. A staging API key does not automatically set SDK environment: "staging" — set the init option explicitly.

Set at init (and mirrored on the React provider options):

Option	Stamped on	Used for
`release`	Error reports	Releases product; issue filters; required for source-map upload pairing
`environment`	Error reports	Issues environment filter
`dist`	Error reports	Optional build discriminator; pairs with `release` when looking up maps
`commitSha`	Error reports	GitHub blob links for culprits when available

HumanBehaviorTracker.init(apiKey, {
  release: "1.4.2",
  environment: "production",
  dist: "web",
  commitSha: process.env.NEXT_PUBLIC_GIT_SHA,
});

Upload maps with the same release / dist — see Source maps.

From the project schema / Environments UI:

Field	Meaning
`key`	Secret presented once; typically prefixed `hb_`
`name`	Unique per project (e.g. “Production”, “Staging”)
`scopes`	Reserved JSON list — not enforced today
Rotate / delete	Immediate invalidate; update client env vars

Keys authenticate ingestion via Authorization: Bearer <key>. They do not encode release or SDK environment.

Surface	Consumes
Releases	`release` (and related error aggregates)
Issues filters	`environment`, `release`
Settings → Environments	API key CRUD