.png)
Commvault Cloud Integration Guide
Connect Commvault Cloud protection, recovery, inventory, and job operations with enterprise systems through REST APIs, selected notifications, and scheduled workflows.
Commvault Cloud integration options at a glance
Commvault Cloud primarily integrates through documented REST APIs for administration and operational automation. These APIs can expose Clients, Subclients, Plans, Backup jobs, Restore jobs, storage, alerts, and related resources, while backup and restore actions are generally asynchronous and return job or operation identifiers. Commvault also provides notification and alerting capabilities, although callback coverage is event-specific rather than universal. Martini can consume the REST APIs, securely manage token-based authentication, schedule polling and reconciliation workflows, receive supported notifications, map payloads, apply authorization and business rules, and expose controlled APIs for restore requests or protection operations.
| Integration point | Supported by Commvault Cloud? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Administer and automate protection operations, retrieve Clients, Subclients, Plans, Backup jobs, Restore jobs, storage, alerts, and related resources. | Martini can consume Commvault Cloud REST endpoints from workflows, map request and response payloads, apply business rules, and expose controlled APIs around selected operations. |
| Authentication | Yes | Authenticate service accounts or application identities using access tokens, application registration where required, and role-based permissions. | Martini can store credentials, client secrets, tokens, and tenant-specific configuration in secrets or environment configuration and use them in API workflows. |
| Webhooks / outbound callbacks | Limited | Receive selected alert, backup, restore, compliance, or infrastructure notifications where the target tenant and event type support a callback mechanism. | Martini can receive supported notifications, validate and transform payloads, and combine notifications with scheduled reconciliation. Coverage must be confirmed for each event type. |
| Bulk / async / batch APIs | Limited | Track asynchronous Backup and Restore jobs and perform larger inventory or operational synchronizations using documented filters and pagination where available. | Martini can persist returned job identifiers, poll status with bounded retries and timeouts, and maintain incremental checkpoints for larger synchronizations. |
| File / attachment APIs | Limited | Perform workload-specific file-level recovery or protected-data operations where the Commvault Cloud API and protected workload expose those capabilities. | Martini can orchestrate documented recovery calls, but it should not treat Commvault Cloud as a general-purpose file or attachment service. |
| SOAP APIs | Legacy | Support older Commvault web-service interfaces only when the target release explicitly requires and documents them. | Martini can consume SOAP services when a compatible legacy endpoint is confirmed, but REST APIs should be preferred for new Commvault Cloud integrations. |
| Database / analytics access | Not confirmed | Direct access to the internal Commvault Cloud control-plane database was not confirmed. Operational reporting should use documented APIs, exports, or supported analytics interfaces. | Martini can consume supported reporting endpoints or write normalized API results to an enterprise database without relying on direct Commvault database access. |
How Commvault Cloud exposes data and business events
Commvault Cloud REST APIs
REST is Commvault Cloud's primary confirmed integration mechanism for administration and operational automation. The APIs can be used to retrieve protection configuration and operational resources and to initiate supported backup or restore actions.
Martini implementation pattern
Martini implementation pattern: Martini workflows authenticate against the target tenant, call the required REST endpoints, validate responses, map Commvault Cloud objects to canonical models, and invoke downstream systems or return controlled API responses. API version, endpoint, resource names, and permissions are confirmed for each tenant.
Implementation sequence
Commvault Cloud asynchronous jobs
Backup and restore operations are generally asynchronous. A request can return a job or operation identifier while processing continues in Commvault Cloud.
Martini implementation pattern
Martini implementation pattern: Martini stores the returned identifier and request context, then polls the documented status resource with a bounded schedule. Where a supported event-specific notification exists, it can accelerate updates, while periodic reconciliation confirms the final state.
Implementation sequence
Commvault Cloud notifications
Commvault Cloud provides alert and notification capabilities, but callback coverage is event-specific and should not be generalized to every backup, restore, client, or configuration change.
Martini implementation pattern
Martini implementation pattern: Martini receives only documented notifications for the required event type, validates the source and payload, enriches the event with current REST data, and routes it to operational systems. Scheduled polling remains the fallback for events without supported callbacks.
Implementation sequence
Commvault Cloud inventory synchronization
Clients, Subclients, Plans, jobs, and related operational resources can be synchronized through documented REST queries. Large synchronizations should use pagination, filters, and incremental checkpoints where available.
Martini implementation pattern
Martini implementation pattern: A scheduled workflow retrieves pages or time windows of Commvault Cloud data, maps objects to a canonical model, compares state with the target, and records a durable checkpoint. Late-arriving changes and repeated pages are handled through stable external identifiers and idempotent writes.
Implementation sequence
Common Commvault Cloud integration patterns
Pattern 1: Synchronize backup and restore job status
When to use this pattern
Use this pattern when service management, monitoring, reporting, or audit systems need current Commvault Cloud protection and recovery status. It supports scheduled reconciliation and can incorporate selected event notifications without depending on universal webhook coverage.
Integration direction
Example Mapping
| Commvault Cloud Field | Canonical Field | Target Field |
|---|---|---|
| jobId | externalJobId | Correlation ID |
| jobType | operationType | Request type |
| status | operationStatus | State |
| startTime | startedAt | Opened at |
Martini implementation pattern
A scheduled Martini workflow queries recently changed Backup jobs and Restore jobs, applies a checkpoint and time window, normalizes status and failure details, and creates or updates downstream incidents or requests. Stable identifiers and idempotent writes prevent duplicates; transient API failures use bounded retries and persistent failures are routed for review.
Martini capabilities used
- workflows
- API consumption
- scheduling
- data mapping
- business rules
- error handling
- retry handling
Pattern 2: Orchestrate ITSM-driven restore requests
When to use this pattern
Use this pattern when an approved ServiceNow or Jira Service Management request should initiate a controlled Commvault Cloud restore operation. It is appropriate for environments requiring authorization, auditability, and asynchronous status updates.
Integration direction
Example Mapping
| Commvault Cloud Field | Canonical Field | Target Field |
|---|---|---|
| requestedBy | requestor | Authorization subject |
| clientId | protectedClientId | Client identifier |
| recoveryPoint | recoveryPoint | Restore point |
| requestId | correlationId | Operation correlation |
Martini implementation pattern
Martini exposes a controlled API that validates the requester, target Client, recovery point, and required approvals before calling the Commvault Cloud restore API. It stores the returned Restore job identifier, polls status with an overall timeout, and updates the originating request. Authorization failures and invalid recovery parameters are not retried.
Martini capabilities used
- APIs
- workflow orchestration
- authentication
- business rules
- data validation
- API consumption
- error handling
Pattern 3: Report protection policy compliance
When to use this pattern
Use this pattern when teams need to identify Clients without the required Plan, critical workloads without a recent successful Backup job, or protection settings that do not meet policy. The output can support compliance reporting and remediation queues.
Integration direction
Example Mapping
| Commvault Cloud Field | Canonical Field | Target Field |
|---|---|---|
| clientId | workloadId | Workload key |
| planId | protectionPlanId | Assigned policy |
| lastSuccessfulBackup | lastProtectedAt | Last successful protection |
| status | complianceStatus | Compliance result |
Martini implementation pattern
A scheduled Martini workflow retrieves Clients, Subclients, Plans, and recent Backup jobs, joins them by stable identifiers, and applies rules for plan assignment, backup freshness, and workload criticality. It writes normalized compliance results to a reporting database and routes exceptions for remediation, while pagination and checkpoints support repeatable processing.
Martini capabilities used
- scheduled workflows
- API consumption
- data mapping
- business rules
- database integration
- checkpointing
- error handling
Pattern 4: Provision protection for new workloads
When to use this pattern
Use this pattern when an infrastructure or application onboarding process should create or update Commvault Cloud protection configuration for a newly registered workload. The exact provisioning calls and supported workload resources must be verified for the tenant.
Integration direction
Example Mapping
| Commvault Cloud Field | Canonical Field | Target Field |
|---|---|---|
| resourceId | workloadExternalId | Client reference |
| workloadClass | protectionProfile | Plan selection |
| applicationName | serviceName | Subclient metadata |
| onboardingRequestId | correlationId | Provisioning reference |
Martini implementation pattern
An onboarding system calls a Martini API with workload and classification data. Martini validates the request, selects an approved Plan, checks for an existing Client or Subclient, and invokes documented Commvault Cloud configuration operations where available. Idempotency checks prevent duplicate configurations, and the workflow returns identifiers and actionable errors to the onboarding system.
Martini capabilities used
- APIs
- workflow orchestration
- data validation
- business rules
- API consumption
- idempotency
- error handling
Applications commonly integrated with Commvault Cloud
Commvault Cloud operational data and recovery workflows can be connected to service management, cloud operations, monitoring, and analytics applications. The exact implementation depends on the target Commvault Cloud tenant, supported workload, API version, and capabilities of the adjacent application.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| ServiceNow | Create incidents for failed backups, track restore requests, and publish protection status to operations teams. | Commvault Cloud → Martini → ServiceNow | Martini consumes Commvault Cloud job or alert data, normalizes status and severity, and creates or updates ServiceNow records. ServiceNow can call a Martini API for validated restore requests, while Martini tracks the resulting Commvault job identifier and updates the originating request. |
| Jira Service Management | Manage backup failures and recovery requests through development and operations service queues. | Jira Service Management → Martini → Commvault Cloud | A Martini API receives approved Jira Service Management requests, validates the target client and recovery parameters, invokes the appropriate Commvault Cloud REST operation, and returns or stores the asynchronous job identifier. Scheduled reconciliation can update Jira with completion or failure status. |
| Salesforce | Correlate protection and recovery activity with customer-service operations where the relevant Salesforce workload is supported. | Commvault Cloud → Martini → Salesforce | Martini retrieves selected Commvault Cloud status data, applies workload and business rules, and writes approved summaries to Salesforce through its APIs. This pattern should be validated against the protected workload and the Salesforce data model before implementation. |
| Microsoft Azure | Coordinate Azure workload protection with cloud operations and synchronize protection status for enterprise reporting. | Microsoft Azure → Martini → Commvault Cloud | An Azure-hosted onboarding or operations process calls a Martini API or scheduled workflow. Martini validates workload classification, maps Azure resource information to Commvault Cloud fields, invokes documented Commvault operations, and records resulting client or job identifiers. |
| Amazon Web Services | Connect AWS workload protection and recovery status with cloud operations processes. | Amazon Web Services → Martini → Commvault Cloud | Martini receives AWS workload or operations input, applies provisioning and authorization rules, and calls Commvault Cloud REST APIs where the required AWS workload and resource operations are available. It can then poll job status and publish normalized results to AWS-facing systems. |
| Microsoft Teams | Deliver selected backup, restore, or alert notifications to operations channels. | Commvault Cloud → Martini → Microsoft Teams | Martini polls Commvault Cloud or receives a supported event-specific notification, filters and enriches the event, and posts a concise message to Microsoft Teams through an approved endpoint. Duplicate suppression and severity rules prevent repeated channel notifications. |
| Splunk | Send Commvault Cloud job status, operational events, or audit information to security and operations analytics. | Commvault Cloud → Martini → Splunk | A scheduled Martini workflow queries incremental Commvault Cloud jobs or alerts, converts responses to a stable event schema, and forwards them to Splunk through its supported ingestion interface. Checkpoints, retries, and dead-letter handling protect against missed or duplicated events. |
| Datadog | Correlate backup health and recovery activity with infrastructure monitoring and incident management. | Commvault Cloud → Martini → Datadog | Martini retrieves filtered Commvault Cloud job and alert data, maps status and timing fields to the required Datadog event or metric model, and sends the result through an approved Datadog API. The workflow can apply thresholds and suppress unchanged states. |
How to build a Commvault Cloud integration in Martini
Objective
Establish the Commvault Cloud connection using the target tenant's documented token-based authentication flow and an appropriately scoped service account or application identity.
Instructions in Martini
- Confirm the tenant base URL, API version, authentication flow, and required roles.
- Store access tokens, client secrets, and endpoint configuration in Martini secrets or environment configuration.
- Separate read-only synchronization permissions from restore or configuration-changing permissions.
Objective
Select a scheduled, API-led, or supported event-specific trigger based on the required integration latency and Commvault Cloud notification coverage.
Instructions in Martini
- Use a scheduler for inventory, job-status, and reconciliation workflows.
- Expose a Martini API for approved restore or provisioning requests.
- Use received notifications only for event types confirmed in the target environment.
Objective
Call documented Commvault Cloud REST endpoints and retrieve the relevant object or asynchronous job status without assuming that one response contains all resources.
Instructions in Martini
- Use documented pagination, filters, and time windows.
- Persist job identifiers and synchronization checkpoints.
- Retrieve current resource details after receiving a notification when the event payload is incomplete.
Objective
Coordinate validation, API calls, asynchronous monitoring, downstream writes, and recovery paths in a maintainable Martini workflow.
Instructions in Martini
- Separate request initiation from job-status monitoring.
- Apply bounded polling and an overall timeout for Backup and Restore jobs.
- Keep read, write, and privileged recovery operations in clearly separated workflow paths.
Objective
Convert Commvault Cloud payloads into canonical models used by ITSM, CMDB, monitoring, reporting, or onboarding systems.
Instructions in Martini
- Map stable Commvault identifiers to external keys.
- Normalize status values, timestamps, scopes, and failure information.
- Preserve useful source identifiers and correlation data for audit and troubleshooting.
Objective
Enforce authorization, workload classification, compliance, idempotency, and operational policies before changing Commvault Cloud or downstream systems.
Instructions in Martini
- Validate requestor, Client, recovery point, and approval state before restore operations.
- Check existing Clients, Subclients, Plans, or requests before creating or updating them.
- Avoid retrying validation, authentication, or authorization failures.
Common Commvault Cloud data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| CommCell | Scope administration, clients, plans, jobs, storage, and permissions within a Commvault management boundary. | ITSM platforms, CMDBs, reporting databases, operational dashboards | Martini preserves CommCell identifiers and scope information while applying tenant and authorization rules before downstream synchronization. |
| Client | Represent a protected server, host, virtual machine, application host, or other workload endpoint. | CMDBs, service management platforms, cloud operations systems, reporting platforms | Martini retrieves Clients with documented filters or pagination, maps stable identifiers and protection attributes, and performs idempotent upserts. |
| Subclient | Define the logical data included in a backup or protection operation. | Application inventories, CMDBs, compliance reports, service management platforms | Martini associates Subclients with Clients and Plans, validates required relationships, and applies business rules for application or service classification. |
| Plan | Define protection, retention, storage, and related data-management policy settings. | Compliance platforms, reporting databases, onboarding systems, ITSM platforms | Martini compares Plan assignments and attributes against policy rules, reports exceptions, and can support controlled assignment workflows where permitted. |
| Backup job | Record execution of a backup or protection operation, including status, timing, scope, and identifiers. | ServiceNow, Jira Service Management, Splunk, Datadog, reporting databases | Martini polls or receives selected notifications, normalizes status and timestamps, stores checkpoints, and updates downstream systems idempotently. |
| Restore job | Record execution and progress of a recovery operation. | ServiceNow, Jira Service Management, operational dashboards, audit platforms | Martini validates restore requests, stores the returned job identifier, polls bounded status transitions, and publishes completion, failure, or timeout results. |
Authentication and security considerations
Token-based authentication
Commvault Cloud access commonly uses short-lived access tokens associated with a user, service account, or registered application. The exact flow depends on the tenant and API version.
Least-privilege access
Use separate identities or roles for inventory synchronization, backup initiation, restore operations, and protection-policy changes. Confirm tenant, CommCell, and application-level authorization boundaries.
Martini secret management
Store tokens, client secrets, tenant endpoints, and related configuration in Martini secrets or environment configuration rather than embedding them in workflows.
Privileged recovery operations
Restore initiation and protection-policy changes should require explicit authorization, validation, and audit details. Avoid logging tokens, protected-data content, or unnecessary personal information.
Operational considerations for Commvault Cloud integrations
API versions and schemas
Confirm the tenant base URL, API version, resource names, and response fields before creating reusable workflows. Test changes against representative Client, Subclient, Plan, Backup job, and Restore job responses.
Pagination and checkpoints
Use documented pagination and incremental filters for larger synchronizations. Store durable checkpoints and account for late-arriving status changes and clock differences.
Asynchronous jobs
Persist returned job identifiers and use bounded polling with an overall timeout. Distinguish queued, running, completed, failed, canceled, and partially completed states.
Throttling and retries
Confirm tenant-specific quotas. Use bounded concurrency and backoff for throttling and transient server errors, while avoiding retries for invalid or insufficient-permission requests.
Idempotency and testing
Use stable Commvault identifiers and correlation keys to make updates safe to repeat. Test restore and configuration-changing workflows in a non-production environment with authorization and failure scenarios.
Why use Martini instead of scripts or point-to-point integrations?
Centralized orchestration
Martini coordinates Commvault Cloud API calls, asynchronous job monitoring, downstream updates, validation, and recovery paths in reusable workflows rather than scattering logic across scripts.
Controlled API exposure
Martini can expose a controlled API for restore or protection requests while keeping Commvault-specific authentication, identifiers, permissions, and endpoint details behind a governed integration boundary.
Maintainable transformation
Mappings, canonical models, business rules, checkpoints, and error handling can be maintained as integration assets that support ITSM, CMDB, monitoring, reporting, and onboarding use cases.
Operational reliability
Workflows can apply bounded retries, idempotent writes, scheduled reconciliation, structured logging, and asynchronous status tracking to address the operational characteristics of backup and recovery APIs.
Frequently asked questions
Commvault Cloud can be integrated primarily through its documented REST APIs for administration, inventory, backup and restore operations, job monitoring, alerts, and related data-protection resources. Selected notification capabilities may support event-driven updates, while scheduled REST polling can handle events without a confirmed callback mechanism.
Yes. Martini can integrate with Commvault Cloud by consuming its REST APIs, managing token-based authentication, orchestrating asynchronous Backup and Restore jobs, polling status, processing selected notifications, mapping data, and exposing controlled APIs for downstream applications.
No. A dedicated Commvault Cloud connector is not required. Martini can use Commvault Cloud's confirmed native integration mechanisms, primarily REST APIs and token-based authentication, together with selected notifications or scheduled polling where appropriate.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Commvault Cloud. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Commvault, cloud infrastructure providers, or other third-party systems based on subscription, usage, and deployment model.
New projects should generally use the documented Commvault Cloud REST APIs with the tenant's current API version and authentication flow. Backup and restore operations should be designed as asynchronous job workflows. SOAP should be treated as legacy, and GraphQL was not confirmed in the supplied research.
Commvault Cloud provides alert and notification capabilities, but broad webhook coverage for all resources and lifecycle events was not confirmed. Treat notifications as selected-event functionality that must be validated for the required alert or job type. Martini can use scheduled REST polling and checkpoints for unsupported events.
A Martini workflow can retrieve Clients, Subclients, Plans, Backup jobs, Restore jobs, alerts, or other documented resources using pagination, filters, time windows, and durable checkpoints. It maps the results to the target model and performs idempotent updates, with periodic reconciliation to handle late-arriving status changes.
Martini can distinguish authentication, authorization, validation, throttling, transient API, and job-level failures. Transient errors can use bounded retries and backoff, while invalid or unauthorized requests should fail without retrying. Stable Commvault identifiers, correlation keys, pre-checks, and status reconciliation help prevent duplicate configuration changes or notifications.
Related Martini documentation
Workflows
Connect Commvault Cloud with your enterprise systems
Use Martini to build governed Commvault Cloud integrations for backup operations, recovery workflows, protection compliance, and operational reporting.