Summary and recommendation
Hotjar does not expose a server-side REST API for team or user management. The public API (v2) is scoped to data export - recordings, heatmaps, and feedback - and a client-side JavaScript Identify API for tagging visitor sessions.
There are no documented endpoints for creating, updating, or removing organization members, and no webhook system for user-management or account events. Any identity graph built on top of Hotjar for provisioning purposes cannot rely on a native API surface; all member lifecycle operations must go through the dashboard UI.
API quick reference
| Has user API | No |
| SCIM available | No |
| SCIM plan required | Scale (Custom pricing) |
Authentication
Auth method: Not documented
User object / data model
User object field mapping is not yet verified for this app.
Core endpoints
Endpoint coverage is not yet verified for this app.
Rate limits, pagination, and events
Rate limits: Not documented
Rate-limit headers: No
Retry-After header: No
Rate-limit notes: Not documented
Pagination method: none
Default page size: 0
Max page size: 0
Pagination pointer: Not documented
Webhooks available: No
Webhook notes: Hotjar does not document any webhook system for user-management or account events in official sources.
Alternative event strategy: Hotjar's client-side Identify API (JavaScript) can tag session data with user attributes, but this is not a server-side user-management mechanism.
SCIM API status
- SCIM available: No
- SCIM version: Not documented
- Plan required: Scale (Custom pricing)
- Endpoint: Not documented
Limitations:
- No SCIM provisioning is documented in official Hotjar help or developer docs.
- SSO (SAML) is available on Scale plans but automated provisioning/deprovisioning via SCIM is not offered.
- Okta is listed as a supported SSO IdP; Entra ID, Google Workspace, and OneLogin are not officially listed.
Common scenarios
Because no user-management API exists, the only viable automation path is SSO via SAML on Scale plans, with Okta confirmed as a supported IdP.
Even with SSO configured, automated provisioning and deprovisioning via SCIM is not available - users must still accept an invitation or be pre-provisioned through SSO configuration. Entra ID, Google Workspace, and OneLogin are not officially listed as supported IdPs.
For teams building an identity graph that requires Hotjar membership state, the absence of a machine-readable roster endpoint means any sync must be driven by out-of-band data sources rather than a Hotjar API response.
Scenario implementations are not yet verified for this app.
Why building this yourself is a trap
The client-side Identify API (hj('identify', userId, attributes)) is the most visible API surface in Hotjar's developer docs, and it is frequently mistaken for a user-management mechanism. It is not - it tags visitor session data with application-level user attributes for behavioral analytics purposes and has no effect on Hotjar organization membership, roles, or access.
Teams that attempt to build provisioning logic against this surface will find it has no server-side counterpart. The gap between Hotjar's analytics API and its complete absence of a provisioning API is a hard architectural constraint, not a configuration issue.
Automate Hotjar workflows without one-off scripts
Stitchflow builds and maintains end-to-end IT automation across your SaaS stack, including apps without APIs. Built for exactly how your company works, with human approvals where they matter.
