What’s New – API Docs and Operation ID Migration
slug: /whats-new-api-docs-and-operation-id-migration
title: What’s New – API Docs and Operation ID Migration
sidebar_label: What’s New – API Docs and Operation ID Migration
sidebar_position: 15
description: "Stay up-to-date with JumpCloud's upcoming API documentation changes, featuring unified API pages and a new, standardized operationID generation format for easier integration."
displayed_sidebar: supportSidebar
--- 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. 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.What is changing in JumpCloud’s API documentation experience?
Why is JumpCloud implementing the change?
Are the actual JumpCloud APIs changing?
Will my existing API integrations continue to work?
How you integrate Impact Direct HTTP calls (curl, Postman, custom REST clients using URLs + auth) No impact. Your integrations keep working as-is. Generated clients / SDKs built from JumpCloud OpenAPI specifications using operationId derived method names No runtime impact if you keep using legacy specifications. Method names will change when you regenerate from the new spec bundles. Automation keyed on legacy operationId strings (configs, tests, wrappers) Once you switch to new specifications, must update those identifiers CI/scripts that download OpenAPI YAML form fixed URLs Once you switch to new specifications, must update those URLs. How will the changes to operationId naming conventions in the OpenAPI specifications affect my existing API integrations?
Will the generated SDK or client method names change?
What should I do if I use OpenAPI Generator, AutoRest, or similar tools?
What action should the customers take before the final cutover?
When does the new API documentation experience take effect?
What’s the customer communication plan?
Who should customers contact if they have questions, feedback or require support?
Was this information helpful?