FAQs: New API Docs and Operation ID Migration

We have simplified our API documentation. Instead of separating everything by version numbers onto different pages, we have combined them. You can now find all Console endpoints (V1 and V2) on a single page (https://docs.jumpcloud.com/new). This keeps all related tools together so you don't have to jump back and forth between different links. JumpCloud is migrating the API documentation interface from ReDoc to Scalar to improve the user experience when you browse and use the API reference.

• The updated UI features a cleaner layout, improved navigation, and better readability, making it easier than ever to find the endpoints, guides, and code samples you need.
• The OpenAPI bundle layout, direct specs download URLs and operationId naming have also changed.

No. The API endpoints remain the same.

Production API calls do not break because of this change. Only tooling that depends on legacy specification URLs or legacy operationId names need planning before the new specifications/documentation are published.

In the new spec bundles (/new), we are replacing legacy  operation IDs (e.g., groups_system_list) with a deterministic, standardized format (e.g., getApiV2Systemgroups).

• Legacy: mixed camelCase and snake_case (example: groups_system_list)
• Standardized: HTTP method + host-root path in camelCase (example: getApiV2Systemgroups)

Here is how your existing API integrations will be affected.

• Direct HTTP integrations: No effect.
• OpenAPI driven codegen (SDKs, clients, wrappers): Generated method/function names are derived from operationId. Regenerating from new specifications produces new method names for the same endpoints. 
• Internal automation that stores operation names: Update stored operationIds to match the new standardized names 
• Migration support: Use the published mapping file as follows.
  • JumpCloud Console APIs - https://docs.jumpcloud.com/new/console/operation-id-mapping.yaml
  • Directory Insights APIs - https://docs.jumpcloud.com/new/api/insights/directory/operation-id-mapping.yaml

Yes, only when you regenerate from the new OpenAPI bundles.

• Same specifications / legacy documentation: Method names stay the same.
• New aggregate specifications (/new): Regenerated clients will use method names aligned to standardized operationId values.
• Already generated SDKs in production: Keep working until you choose to regenerate and update call sites. The API endpoints themselves are unchanged.

When evaluating or migrating to new specifications, update your specification download URLs, regenerate clients and use the operation-id-mapping.yaml to map legacy operationId to standardized operationIds and update call sites, tests and configs. Run your existing integration tests. HTTP behavior should be unchanged. Only client symbols differ.

• Now (preview period):
  • Review the new documentation at https://docs.jumpcloud.com/new.
  • If you use OpenAPI codegen or store operationId values, download the relevant mapping files and assess the migration effort. 
  • Update bookmarks/automation. Legacy URLs remain supported during preview. 
  • Watch for official communication for cutover date and retirement timeline. 
• Before cutover:
  • Direct HTTP users: Minimal action. Verify any hard-coded documentation/specifications URLS.
  • Codegen/SDK users: Regenerate clients from new bundles. Update method names using mapping file. Test in non-production environment. 
  • CI Pipelines: Update spec URLs and any logic that uses legacy spec URLs.
• After cutover:
  • New documentation becomes the default at https://docs.jumpcloud.com/ (no /new prefix will be present in the URL).
  • Current documentation move to https://docs.jumpcloud.com/legacy
  • Legacy versions specification files (YAML files) remain under /legacy/ until retirement.

No action is required if you make only direct HTTP calls and do not depend on the OpenAPI specification URLs or generated client method names.

The new API documentation experience is currently available as a preview starting July 15th 2026. Customers can review the new documentation and migration resources. JumpCloud will communicate the final cutover timeline through official channels before the new documentation experience becomes the primary API reference.

We’ll notify customers about the final cutover date through email communication.

Customers should reach out to JumpCloud support if they have questions, feedback, or require support. See Contact JumpCloud Support to learn more.