Environments and Testing
HollyHR's public API beta is live-only. API keys created in HollyHR act on the
organisation that created them, and GET /me reports:
Code
There is no hidden sandbox behind hhr_live_ keys, and there is no separate
test key prefix in the beta contract. Treat every successful write as a live
organisation change.
How to test safely
Use a non-production HollyHR organisation for integration development whenever possible. Create a dedicated API key for that organisation, grant only the scopes required by the test, and keep the key separate from production configuration.
When testing against a live customer organisation:
- start with read-only scopes;
- use small, clearly named test records;
- use idempotency keys on every write;
- read the resource first and send
If-Matchwhen the endpoint requires an ETag; - verify webhook receivers with
POST /webhooks/{webhookId}/testbefore subscribing to production events; - use
GET /mein startup checks so the integration logs the organisation, key id, granted scopes, actor type, and live environment before doing work.
Base URLs
Use the same app origin the organisation uses to sign in:
Code
If the organisation uses a custom HollyHR domain, use that custom origin instead. Local, preview, and staging app deployments are not a public sandbox contract and should not be used as customer integration targets unless HollyHR has explicitly arranged that with you.
Future sandbox
HollyHR has an internal synthetic demo-tenant provisioning flow for reviewer, partner, and TTFC evidence. It still uses ordinary tenant-scoped API keys and is not a public sandbox-key contract.
A future hhr_test_ key prefix or self-service sandbox organisation model may
be added when partner onboarding needs it. That future feature must be explicit
in GET /me, the API-key prefix, docs, webhooks, audit logs, and support
workflows. It will not be introduced by silently changing live-key behavior.