Workspace

API Keys

Create named keys, tie them to the right project, rotate them safely, and keep every protected HRS call tied to a clear purpose.

Naming and scope

Every key should be named for the project and the workload it powers. That makes billing, audit review, and incident response much easier under real load.

Keys stay tied to a project and server-side only. Browser bundles, native clients, and support surfaces never receive the raw secret.

Rotation and replacement

Key rotation is part of normal operations, not an edge case. The platform keeps old and new key windows visible long enough for safe cutovers.

Usage views and webhook health help teams confirm that a rotation completed cleanly before they fully retire the old secret.

Create the first key

After the first sandbox project exists, create one clearly named key, store it server-side, run a protected lookup, and confirm the key shows usage on the dashboard.

That first successful call proves the workspace, the project, and the key are all wired correctly.

Name and store the first sandbox keybash

PAYTOCOMMIT_PROJECT=sandbox-workforce-review
PAYTOCOMMIT_KEY_LABEL=hrs-sandbox-backend
PAYTOCOMMIT_API_KEY=ptc_live_replace_me

curl https://api.paytocommit.com/v1/hrs/lookup \
  -H "Authorization: Bearer $PAYTOCOMMIT_API_KEY" \
  -H "X-PayToCommit-Project: $PAYTOCOMMIT_PROJECT" \
  -H "Content-Type: application/json" \
  -d '{
    "subject": { "legal_name": "Jordan Lee", "country": "US" },
    "consent_scope": "hrs.lookup.identity",
    "declared_purpose": "workforce_vetting"
  }'

Keep keys on the server and label them for the exact project and workload they power.