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.
Keys should be named for the exact project and workload they serve, never treated like unlabeled secrets.
Rotation health belongs on the key page itself so operators can act without leaving the setup lane.
The key page should make cleanup as visible as issuance.
The first key should read like a real workload name, not a generic environment label.
Browser bundles, native apps, and support flows should never receive the raw secret.
Keys stay tied to a project and server-side only. Browser bundles, native clients, and support surfaces never receive the raw secret.
Usage views and webhook health help teams confirm that a rotation completed cleanly before they fully retire the old secret.
That first successful call proves the workspace, the project, and the key are all wired correctly.
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.
Each key should stay named for one project and one workload.
Rotation health belongs on the key page itself, not in a hidden admin lane.
Immediately verify the new key from the playground after issuance.
The key page should make it obvious that raw secrets never belong in browser or mobile bundles.
Every key should remain traceable to one project and one job.
A new key should move directly into a live verification step.
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.
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.
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.