API Name: Create Bulk Schedule (Onboard) API
Automate and schedule bulk onboarding operations across your cloud instances and mount points.
API support for GCP instances is currently undergoing maintenance. We expect full functionality to be restored shortly
Overview
This API is used to create a bulk schedule job (such as an ONBOARD operation) for one or more combinations of cloud instances and their respective mount points. By accepting instance identifiers from the client, the backend automatically resolves the associated tenants before securely scheduling the bulk job.
What does this API do?
Lucidity's Create Bulk Schedule API allows you to programmatically define and schedule operations for multiple instances and disks simultaneously. You can specify whether an operation requires a reboot, set precise execution time windows, and dictate automated cleanup delays—all within a single API payload. This cleanup process refers to the removal of your original disks after Lucidity has migrated your data to a new set during onboarding. To ensure a safe transition and data integrity, Lucidity recommends a 3-day delay post-onboarding completion before the original disks are cleaned up.
Common Use Cases
Bulk Disk Onboarding: Schedule the onboarding of multiple mount points across different instances in a single request.
No Reboot Required: For configurations where a reboot isn't necessary, simply provide a scheduled Onboard Start Time.
Reboot Required: Depending on your OS, version, and whether you are onboarding a data or root disk, a reboot may be required. In these cases, you will provide a Reboot Time. While the onboarding process begins immediately in the background, it finalizes during your specified window.
Maintenance Window Planning: Precisely manage downtime by setting custom reboot windows for all reboot-required onboardings. This ensures that final cutovers only occur during predefined, low-impact periods that align with your operational requirements.
Business Value
Efficiency: Eliminate the need to manually onboard individual mount points, saving significant administrative time.
Risk Mitigation: Safely schedule reboot-dependent operations during off-peak hours to minimise business disruption.
Flexibility: Handle diverse configurations, such as reboot vs. no-reboot requirements, through a unified API payload.
Multi-Cloud Support
The Lucidity API provides a unified interface across AWS, Azure, and GCP, automatically handling provider-specific parameter requirements during job scheduling:
AWS: cloudProviderAccountId maps to the AWS Account ID.
Azure: cloudProviderAccountId maps to the Subscription ID. (Note: resourceGroup is mandatory).
GCP: cloudProviderAccountId maps to the GCP Project ID.
Lifecycle
SCHEDULED: Bulk job created successfully and awaiting its scheduled start time or reboot window (Returns unique jobId).
IN_PROGRESS: The scheduled onboarding operation is currently executing.
COMPLETED: The bulk onboarding job finished successfully.
FAILED: The job encountered an error during execution.
1. Create Schedule
Purpose: Initiate a scheduled onboard job for selected instances and mount points.
ENDPOINT: POST /external/client/api/v1/job-schedule/{scheduleType}/create (Use ONBOARD for scheduleType)
Best Practices
Security
Never log or commit API tokens to version control.
Use secure credential storage (vaults, secret managers).
Rotate access tokens regularly, as they are short-lived.
Use HTTPS only for all API communications.
Performance & Reliability
Separate Root and Data: Do not mix root mount points (e.g., "/" or "C") and data mount points (e.g., "D", "E") within the same request array.
Validate Time Constraints: Ensure scheduledStartTime is at least 5 minutes in the future. If a reboot is required, ensure rebootStartTime is at least 1 hour in the future.
Cost Optimization
Cleanup Delays: Set the cleanupDelayDays parameter appropriately (1, 3, 7, or 10 days) to automatically remove temporary artifacts and avoid unnecessary storage costs.
Operational Excellence
Track Job IDs: Always log the jobId returned in the 202 accepted response to monitor the progress of your scheduled operations.
Ensure Reboot Window Adequacy: When setting rebootRequired to true, verify that the rebootEndTime is set at least 30 minutes after the rebootStartTime to ensure the system has ample time to complete the process safely.
General Questions
Q: Can I schedule onboarding for multiple mount points on the same instance?
A: Yes, you can pass multiple objects in the mountPointScheduleExternalInfo array for the same instance, specifying different mount points (e.g., "D" and "E"). Just ensure you do not mix root and data mount points in the same request.Q: What are the valid values for the cleanup delay?
A: The cleanupDelayDays parameter accepts exactly 1, 3, 7, 10, or null (if no automated cleanup is desired).
Technical Questions
Q: How do I handle scheduling if a reboot is required?
A: Set rebootRequired to true inside the supportingScheduleExternalInfo object. You must then provide rebootStartTime (at least 1 hour from now) and rebootEndTime (at least 30 minutes after the start time). You do not need to provide scheduledStartTime in this scenario.Q: What time format should be used for scheduling parameters?
A: All time-related fields (scheduledStartTime, rebootStartTime, rebootEndTime) must use the ISO-8601 string format (e.g., "2026-03-15T14:00:00.000Z").Q: What happens if I forget to specify the OS type?
A: The osType field ("Windows" or "Linux") is required. Omitting it will result in a 400 Bad Request error.