Reference · built on requestConnectorIdentity, IT & observability

JumpCloud

Users, user groups, systems, system groups, and Directory Insights events from a JumpCloud org through the JumpCloud API v1 and v2.

Request accessPricing ↗

About

JumpCloud is a cloud directory that joins users, devices, groups, LDAP, RADIUS, and SSO in one org. API v1 at https://console.jumpcloud.com/api covers systemusers, systems, commands, and command results. API v2 at /api/v2 covers user groups, system groups, policies, software apps, and the JumpCloud Graph that binds objects to each other. Directory Insights at https://api.jumpcloud.com/insights/directory/v1/events returns audit and authentication events.

Through Fibric, an operator reads a user, the groups and systems bound to it, and the events behind them, then proposes a suspension, a group change, or a device lock. You approve it once, and the receipt records the command results.

This is a reference listing. It documents what Fibric would read from JumpCloud and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • System users through GET /api/systemusers, with state STAGED, ACTIVATED, or SUSPENDED, and TOTP enrollment through /systemusers/{id}/totpinfo
  • Systems through GET /api/systems, plus System Insights tables such as disk_encryption, apps, certificates, and logged_in_users under /api/v2/systeminsights
  • User groups and system groups through /api/v2/usergroups and /api/v2/systemgroups, with members, membership, and associations
  • Graph traversals such as /api/v2/users/{user_id}/systems and /api/v2/systems/{system_id}/users
  • Directory Insights events by service: directory, sso, radius, ldap, systems, mdm, software, and password_manager, from an RFC 3339 start_time
  • Policies and software apps through /api/v2/policies and /api/v2/softwareapps, and command results through /api/commandresults

Proposed actions

  • Target capability: propose Suspend System User or Activate System User through POST /api/systemusers/{id}/state/suspend or /state/activate
  • Target capability: propose Manage the members of a User Group or System Group through POST /api/v2/usergroups/{group_id}/members or /systemgroups/{group_id}/members
  • Target capability: propose Lock a System, Restart a System, or Erase a System through /api/systems/{system_id}/command/builtin/lock, restart, or erase
  • Target capability: propose Expire a system user's password or Reset a system user's MFA token

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Suspend the user and lock the laptop together

    The operator traverses /api/v2/users/{user_id}/systems, then proposes Suspend System User and Lock a System for each bound device. One approval, one receipt with the command results.

    With Offboarding Sweep

  • Find users without a second factor

    totpinfo and the MFA fields on systemusers show enrollment. The operator lists ACTIVATED users without TOTP and proposes Update a system user's MFA properties for the ones you pick.

    With MFA Gaps

  • Read the audit trail in one place

    Directory Insights events across directory, sso, radius, ldap, and systems are pulled from a start_time and tied to the user and system records they name.

    With Audit Trail

  • Review who is in which group

    User group membership and associations, plus the systems each group binds, become one review page. Each removal is a proposed members change with the group id and the before state.

    With Access Review

Requirements

  • A JumpCloud org and an administrator whose API access is enabled; only admins with the Billing role can enable it
  • An API key with an expiry, 90 days by default and between one hour and 365 days; a new key revokes the old one
  • An administrator role for Directory Insights; a command runner receives 403
  • The regional host for your org: console.jumpcloud.com, console.eu.jumpcloud.com, or console.in.jumpcloud.com
Authentication
An API key from the Admin Portal's API Settings, sent in the x-api-key header; the key carries the full access of the administrator who created it, and MSP admins add x-org-id per client org.

Limits

  • v2 list endpoints return at most 100 records per request, 10 by default, paged with limit and skip
  • Directory Insights keeps events for 90 days; longer storage needs JumpCloud's AWS Serverless Application export to your S3 bucket
  • An API key is shown once, and each administrator holds a different key
  • System Context signatures work on Linux hosts only and cover a system's own record and group associations

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request JumpCloud ↗

Questions and answers

What is the difference between API v1 and v2?
v1 at /api manages commands, systems, and system users. v2 at /api/v2 manages directory objects such as user groups, system groups, policies, and applications, and the JumpCloud Graph that records associations and memberships between them. Some tasks call both.
How are audit events read?
Directory Insights uses one POST endpoint, /insights/directory/v1/events, with a JSON body naming service, for example directory, sso, radius, ldap, systems, or all, and an RFC 3339 start_time. Events are stored for 90 days. MSP admins pass x-org-id per client organization.
How is the API key scoped?
It is tied to the administrator who created it and grants the same access as that admin's console account. API access is off by default and a Billing role admin enables it. Keys expire after 90 days by default, adjustable from one hour to 365 days.
Ask about JumpCloud

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with JumpCloud through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy