HollyHR Developer Docs
  • HollyHR
  • Sign in
  • Manage API keys
  • Start Here
  • Core API
  • AI and MCP
  • API Reference
  • Recipes
  • Resources
RequestsPagination examplesEnvironments and testingWebhooksProvider readinessOpenAPI imports
Core API

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
{ "environment": { "type": "live", "sandbox": false }, "actor": { "type": "api_key" } }

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-Match when the endpoint requires an ETag;
  • verify webhook receivers with POST /webhooks/{webhookId}/test before subscribing to production events;
  • use GET /me in 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:

TerminalCode
export HOLLYHR_API_BASE_URL="https://{workspace}.hollyhr.com/api/v1"

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.

Last modified on June 24, 2026
Pagination examplesWebhooks
On this page
  • How to test safely
  • Base URLs
  • Future sandbox
JSON