Hive User Management API Guide

Auth method: API Key (Bearer token in Authorization header)

Setup steps

1. Log in to Hive and navigate to My Profile > Apps & Integrations > API.
2. Generate a personal API key from the API section.
3. Include the key in all requests as: Authorization: Bearer
4. Optionally scope requests to a specific workspace by including the workspace ID in the request body or query params.

List workspace members

• Method: GET
• URL: https://app.hive.com/api/v1/workspaces/{workspaceId}/members
• Watch out for: Workspace ID must be known in advance; retrieve it from the Hive UI or the workspaces endpoint.

Request example

GET /api/v1/workspaces/{workspaceId}/members
Authorization: Bearer <api_key>

Response example

[
  {
    "id": "usr_abc123",
    "email": "user@example.com",
    "firstName": "Jane",
    "lastName": "Doe",
    "role": "member"
  }
]

Get workspace member by ID

• Method: GET
• URL: https://app.hive.com/api/v1/workspaces/{workspaceId}/members/{userId}
• Watch out for: Returns 404 if the user is not a member of the specified workspace.

Request example

GET /api/v1/workspaces/{workspaceId}/members/{userId}
Authorization: Bearer <api_key>

Response example

{
  "id": "usr_abc123",
  "email": "user@example.com",
  "firstName": "Jane",
  "lastName": "Doe",
  "role": "member"
}

Invite user to workspace

• Method: POST
• URL: https://app.hive.com/api/v1/workspaces/{workspaceId}/members
• Watch out for: Sends an email invitation; user must accept before becoming active. Seat limits apply per plan.

Request example

POST /api/v1/workspaces/{workspaceId}/members
Authorization: Bearer <api_key>
Content-Type: application/json

{"email": "newuser@example.com", "role": "member"}

Response example

{
  "id": "usr_xyz789",
  "email": "newuser@example.com",
  "status": "invited"
}

Remove user from workspace

• Method: DELETE
• URL: https://app.hive.com/api/v1/workspaces/{workspaceId}/members/{userId}
• Watch out for: Removing a member does not delete their Hive account; it only removes workspace access. Use SCIM deactivation for full lifecycle management.

Request example

DELETE /api/v1/workspaces/{workspaceId}/members/{userId}
Authorization: Bearer <api_key>

Response example

{
  "success": true
}

List workspaces

• Method: GET
• URL: https://app.hive.com/api/v1/workspaces
• Watch out for: Returns only workspaces accessible to the API key owner.

Request example

GET /api/v1/workspaces
Authorization: Bearer <api_key>

Response example

[
  {
    "id": "ws_001",
    "name": "Acme Corp"
  }
]

• Rate limits: Hive's public API documentation does not publish explicit numeric rate limits. Practical limits are enforced server-side; excessive requests may result in 429 responses.
• Rate-limit headers: Unknown
• Retry-After header: Unknown
• Rate-limit notes: No official rate limit figures published as of research date. Handle 429 responses with exponential backoff.
• Pagination method: none
• Default page size: 0
• Max page size: 0
• Pagination pointer: Not documented

• Webhooks available: No
• Webhook notes: Hive's public API documentation does not document outbound webhooks for user or membership events as of research date.
• Alternative event strategy: Poll the members endpoint periodically to detect changes, or use SCIM provisioning for event-driven user lifecycle management via your IdP.

• SCIM available: Yes

• SCIM version: 2.0

• Plan required: Enterprise Security Add-on (requires Enterprise plan or Teams plan with Security Add-on; SAML SSO prerequisite)

• Endpoint: https://app.hive.com/scim/v2

• Supported operations: Create user (POST /Users), Read user (GET /Users/{id}), List users (GET /Users), Update user (PUT /Users/{id}), Deactivate/deprovision user (PATCH /Users/{id} with active=false), Create group (POST /Groups), List groups (GET /Groups), Update group membership (PATCH /Groups/{id})

Limitations:

• SCIM provisioning is documented primarily for Okta; other IdP support (Entra ID, OneLogin) may require manual SCIM configuration.
• SAML SSO must be configured before enabling SCIM.
• Enterprise Security Add-on must be purchased separately; not included in base Teams plan.
• Full SCIM 2.0 schema compliance details not publicly documented beyond Okta integration guide.

Three integration patterns are supported by the current API surface:

• SCIM via Okta (recommended for lifecycle automation): Purchase the Enterprise Security Add-on, configure SAML SSO, then connect Hive's SCIM endpoint to Okta. User assignment in Okta triggers POST /scim/v2/Users; unassignment sends PATCH with active=false. SAML SSO must be fully operational before SCIM activation. Other IdPs (Entra ID, OneLogin) may require manual SCIM configuration - Okta is the only IdP with a documented integration guide.

• List workspace members via REST: GET /api/v1/workspaces/{workspaceId}/members with an admin-level API key returns an array of member objects including id, email, role, and status. Use this to build or refresh an identity graph snapshot. Pagination behavior is undocumented; test against large workspaces before assuming full result sets.

• Invite user via REST: POST /api/v1/workspaces/{workspaceId}/members with {"email": "...", "role": "member"} triggers an email invitation. The user's status field transitions from invited to active only after acceptance; poll GET /members/{userId} to confirm. Seat capacity limits on the plan will block the invite if the workspace is full.

Automated user onboarding via SCIM (Okta)

1. Purchase Enterprise Security Add-on and configure SAML SSO with Okta.
2. In Hive workspace settings, enable SCIM and copy the SCIM base URL and bearer token.
3. In Okta, add Hive as a SCIM-enabled app and configure the SCIM connector with the Hive SCIM endpoint and token.
4. Assign users or groups in Okta; Okta will POST to /scim/v2/Users to provision accounts in Hive.
5. Unassigning a user in Okta sends a PATCH with active=false to deactivate the Hive account.

Watch out for: SAML SSO must be fully functional before SCIM activation. Deprovisioning sets the user to inactive but does not delete workspace data.

List all members in a workspace via REST API

1. Generate a personal API key in Hive (My Profile > Apps & Integrations > API).
2. Retrieve the workspaceId from the Hive UI URL or the GET /workspaces endpoint.
3. Send GET https://app.hive.com/api/v1/workspaces/{workspaceId}/members with Authorization: Bearer .
4. Parse the returned array of member objects for email, id, and role fields.

Watch out for: API key is tied to the generating user's permissions; admin-level key recommended for full member visibility.

Invite a new user to a workspace via REST API

1. Authenticate with a workspace admin's API key.
2. POST to https://app.hive.com/api/v1/workspaces/{workspaceId}/members with body {"email": "user@example.com", "role": "member"}.
3. Hive sends an email invitation to the specified address.
4. Monitor member status via GET /members/{userId} until status transitions from 'invited' to 'active'.

Watch out for: Invitation acceptance is required; the user is not immediately active. Seat count on the plan may block the invite if the workspace is at capacity.

The primary integration risk is the mismatch between what the REST API and SCIM API each handle. The REST DELETE endpoint removes a user from a workspace but does not deactivate their Hive account - a user removed via REST can still access other workspaces.

Full deprovisioning requires SCIM, which is gated behind the Enterprise Security Add-on and an active SAML SSO configuration. Teams that build REST-only offboarding pipelines will have an incomplete deprovision path.

The personal API key model introduces a second risk: keys are scoped to the generating user's permissions and have no expiry or rotation policy enforced by the platform. If the key owner loses admin status or leaves the organization, the integration breaks silently.

There is no service account or machine credential concept documented in the v1 API.

For identity graph use cases, the absence of a global user directory endpoint means workspace membership must be queried per workspaceId.

In multi-workspace organizations, this requires enumerating workspaces first via GET /workspaces (which itself returns only workspaces visible to the key owner), then fanning out member queries - adding latency and surface area for incomplete coverage.