Ellipse Gradient for Header

Druva Data Resiliency Cloud Integration Guide

Integrate Druva Data Resiliency Cloud with enterprise systems through REST APIs, selected event notifications, asynchronous operations, and OAuth 2.0-style authentication.

Druva Data Resiliency Cloud integration options at a glance

Druva Data Resiliency Cloud provides REST APIs for retrieving protection status, users, devices, workloads, policies, alerts, audit information, and selected administrative or recovery operations. Selected scenarios also support event or notification mechanisms, while longer-running recovery, export, and administrative activities may require asynchronous job-status polling. File-oriented recovery or download access is available only for supported workloads and should not be treated as a universal attachment API. APIs use OAuth 2.0-style client authentication and bearer tokens. Martini can consume these APIs, receive applicable notifications, schedule incremental synchronization, transform responses, and orchestrate downstream workflows.

Integration pointSupported by Druva Data Resiliency Cloud?Common use casesHow Martini supports it
REST APIsYesRetrieve Organizations, Users, Devices, Workloads, Backup Policies, Alerts, Events, audit information, protection status, and selected administrative or recovery operations. Availability depends on the Druva API family and tenant.Martini can consume Druva REST endpoints from workflows, manage request sequencing, map responses, apply business rules, and expose controlled downstream APIs.
Webhooks and outbound callbacksLimitedReceive notifications for selected operational and protection scenarios where the relevant Druva product area and tenant provide event support. Coverage is not universal across objects or state changes.Martini can expose an authenticated API endpoint and trigger a workflow from applicable notifications, while using deduplication and reconciliation polling for missed or unsupported events.
Bulk, asynchronous, and batch operationsLimitedSubmit and monitor longer-running recovery, export, or administrative operations. Bulk behavior and job-status endpoints are specific to individual APIs.Martini can submit the operation, persist the returned job or operation identifier, poll status with bounded intervals, and route success, failure, timeout, or cancellation outcomes.
File and recovery data accessLimitedAccess recovery, export, or download operations for supported workload types. This is not a general-purpose attachment API and availability depends on workload and retention rules.Martini can orchestrate documented recovery or export calls, handle file-oriented responses where supported, and transfer approved outputs to downstream systems or storage.
AuthenticationYesUse OAuth 2.0-style application credentials to obtain bearer access tokens for Druva API calls. Token endpoints, permissions, scopes, and regional details can vary by service and tenant.Martini can store credentials in environment-specific secrets, obtain or refresh tokens as required, and apply authorization headers to API requests.
SDKs and client librariesLimitedDruva may provide examples, client libraries, or SDK support for selected API products, but the availability and coverage are API-specific.Martini can consume the underlying HTTP APIs directly and use custom JVM-compatible logic when specialized pagination, polling, or response processing is required.
Scheduled synchronizationYesPoll Druva APIs for Users, Devices, Workloads, Backup Policies, Alerts, Events, and protection or job status when event coverage is unavailable or reconciliation is required.Martini can schedule workflows, use pagination and incremental filters, persist checkpoints, apply overlap windows, and deliver normalized results to target systems.

How Druva Data Resiliency Cloud exposes data and business events

Druva REST APIs

Druva REST APIs provide the primary integration surface for administration, protection data, workload information, operations, reporting, and selected recovery activities. Exact resources and permissions vary by API family and tenant.

Martini implementation pattern

Martini implementation pattern: a workflow obtains an OAuth bearer token, calls the required Druva endpoint, follows pagination or continuation data, maps the response to a canonical model, applies business rules, and writes to the target system. Raw identifiers and checkpoints can be retained for audit and reconciliation.

Implementation sequence

Obtain an OAuth bearer access token
Call the documented Druva REST endpoint
Follow pagination or continuation information
Validate and map the response
Apply business and compliance rules
Write the result to the target system

Druva event notifications

Druva provides event and notification capabilities for selected operational and protection scenarios. These notifications are not a universal change stream for every Druva object or state transition.

Martini implementation pattern

Martini implementation pattern: Martini exposes an authenticated API endpoint for applicable Druva notifications, acknowledges promptly, and starts processing asynchronously where appropriate. The workflow uses event identifiers for idempotency and performs scheduled reconciliation against Druva APIs for missed, duplicated, or out-of-order notifications.

Implementation sequence

Receive the Druva notification
Validate the notification and source identifier
Acknowledge the request promptly
Check for duplicate processing
Retrieve additional Druva context when required
Route the normalized event to the target system

Asynchronous Druva operations

Recovery, export, and selected administrative activities may be long-running and return an operation or job identifier rather than a final result immediately. Bulk behavior is endpoint-specific.

Martini implementation pattern

Martini implementation pattern: one workflow submits the operation and stores its identifier, while a controlled polling workflow retrieves status until a terminal state. Martini applies bounded retries, timeout rules, and distinct handling for failed, cancelled, expired, or partially completed operations.

Implementation sequence

Submit the documented Druva operation
Persist the returned job or operation identifier
Schedule a bounded status check
Retrieve the current operation status
Apply terminal-state and timeout rules
Record and notify the final outcome

Scheduled Druva synchronization

Scheduled polling is appropriate when an event mechanism does not cover the required object or when periodic reconciliation is needed. Druva list endpoints should be treated as paginated unless documented otherwise.

Martini implementation pattern

Martini implementation pattern: a scheduler starts a workflow that reads the stored checkpoint, queries Druva with available time or status filters, processes each page, and commits the checkpoint only after the synchronization window succeeds. An overlap window helps account for late updates and clock differences.

Implementation sequence

Start the scheduled synchronization workflow
Read the last successful checkpoint
Query Druva using incremental filters
Process each paginated response
Write normalized records downstream
Commit the checkpoint after successful completion

Common Druva Data Resiliency Cloud integration patterns

Pattern 1: Route Druva protection alerts to ServiceNow

When to use this pattern

Use this pattern when operations teams need incidents for backup failures, protection gaps, recovery failures, or compliance exceptions. Event coverage is scenario-specific, so the workflow can combine notifications with API enrichment and reconciliation polling.

Integration direction
Druva Data Resiliency Cloud
Martini
ServiceNow
Example Mapping
Druva Data Resiliency Cloud FieldCanonical FieldTarget Field
alertIdsourceEventIdcorrelation_id
severityincidentPrioritypriority
protectionStatusprotectionStatesubcategory
workloadIdprotectedWorkloadIdconfiguration_item
Martini implementation pattern

Martini receives an applicable Druva notification or discovers the alert through polling, validates the payload, retrieves additional workload or device context when needed, and uses the alert identifier as an idempotency key. The workflow creates or updates a ServiceNow incident, retries transient failures, and routes unresolved cases for operational review.

Martini capabilities used
  • workflows
  • API consumption
  • API exposure
  • data mapping
  • business rules
  • error handling

Pattern 2: Build scheduled backup compliance reporting

When to use this pattern

Use this pattern to produce a normalized compliance dataset from Druva Backup Policies, Workloads, Devices, backup jobs, and protection status. It is useful when reporting systems need consistent results across workload types and periodic reconciliation.

Integration direction
Druva Data Resiliency Cloud
Martini
Splunk
Example Mapping
Druva Data Resiliency Cloud FieldCanonical FieldTarget Field
workloadIdprotectedAssetIdasset_id
backupStatusprotectionResultbackup_status
lastSuccessfulBackuplastProtectedAtlast_successful_backup
policyIdprotectionPolicyIdpolicy_id
Martini implementation pattern

A scheduled Martini workflow reads a checkpoint, queries paginated Druva endpoints with time-window filters where available, normalizes status values, and separates failed, incomplete, and skipped results. It applies compliance thresholds, sends the output to Splunk or another reporting destination, and commits the checkpoint only after all pages are processed.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • pagination handling
  • data mapping
  • business rules
  • monitoring

Pattern 3: Orchestrate Druva recovery operations

When to use this pattern

Use this pattern when a downstream application needs a controlled recovery request without calling Druva directly. It separates request acceptance from long-running recovery execution and provides an auditable status trail.

Integration direction
ServiceNow
Martini
Druva Data Resiliency Cloud
Example Mapping
Druva Data Resiliency Cloud FieldCanonical FieldTarget Field
recoveryTargetrequestedRecoveryDestinationDruva recovery target
workloadIdprotectedWorkloadIdDruva workload identifier
requestIdbusinessRequestIdoperation correlation key
operationStatusrecoveryStaterequest status
Martini implementation pattern

Martini exposes a controlled API, validates the requester and recovery parameters, and submits the documented Druva recovery operation. It stores the returned operation identifier, returns an accepted response for asynchronous processing, polls with bounded intervals, and notifies the requester or operations queue when the operation reaches a terminal state.

Martini capabilities used
  • API exposure
  • workflows
  • authentication
  • validation
  • asynchronous orchestration
  • error handling

Pattern 4: Synchronize Druva users and devices with IT operations

When to use this pattern

Use this pattern when an enterprise inventory, governance, or access-review process needs current protection status for Druva Users and Devices. It is appropriate for identifying users without recent protection or devices that have not checked in.

Integration direction
Druva Data Resiliency Cloud
Martini
ServiceNow
Example Mapping
Druva Data Resiliency Cloud FieldCanonical FieldTarget Field
userIdpersonIdcaller_id
deviceIdprotectedDeviceIdcmdb_ci
protectionStatusdeviceProtectionStateu_protection_status
lastCheckInlastObservedAtu_last_check_in
Martini implementation pattern

Martini periodically retrieves paginated Users and Devices, associates devices with owners where the API provides the relationship, and applies rules for stale check-ins or missing successful protection. It writes valid changes to ServiceNow or another inventory target, records source identifiers, and retries or quarantines invalid records without losing the synchronization checkpoint.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • data mapping
  • business rules
  • checkpointing
  • error handling

Applications commonly integrated with Druva Data Resiliency Cloud

Druva Data Resiliency Cloud can be integrated with adjacent business, security, operations, and reporting applications. The exact workload objects, event coverage, and API operations should be validated for the Druva tenant and product area in use.

Application Scenario Direction Martini Pattern
ServiceNow Create or update incidents and operational tasks from backup failures, protection gaps, recovery failures, or compliance exceptions. Druva Data Resiliency Cloud → Martini → ServiceNow Martini receives selected Druva alerts or polls for protection exceptions, enriches the event with workload or device context, applies severity and deduplication rules, and creates or updates a ServiceNow incident.
Splunk Centralize Druva audit, backup, alert, and operational information for search, correlation, and security monitoring. Druva Data Resiliency Cloud → Martini → Splunk A scheduled or event-driven Martini workflow retrieves Druva data, normalizes alert and audit fields, preserves source identifiers, and sends the resulting payload to Splunk through its supported ingestion interface.
Microsoft Sentinel Correlate Druva protection and security events with identity, endpoint, and cloud-security signals. Druva Data Resiliency Cloud → Martini → Microsoft Sentinel Martini consumes applicable Druva notifications or performs incremental polling, maps event severity and resource context to a security schema, and forwards validated events to the Sentinel ingestion path.
Jira Create engineering or operations work items for recurring backup failures, protection gaps, and recovery defects. Druva Data Resiliency Cloud → Martini → Jira Martini retrieves or receives Druva exceptions, applies an idempotency key based on the alert or job identifier, maps the exception to Jira fields, and updates existing issues on retry rather than creating duplicates.
Microsoft 365 Coordinate protection reporting for Exchange Online, OneDrive, SharePoint, and related Microsoft 365 workloads where supported. Microsoft 365 → Druva Data Resiliency Cloud → Martini Druva protects the supported Microsoft 365 workload, while Martini retrieves protection and recovery status and distributes normalized results to operational, governance, or reporting applications.
Google Workspace Expose protection and recovery status for Gmail, Drive, and other supported Google Workspace workloads to enterprise operations. Google Workspace → Druva Data Resiliency Cloud → Martini Martini periodically retrieves workload, user, and protection information exposed by Druva, applies tenant-specific business rules, and routes exceptions or compliance results to downstream systems.

How to build a Druva Data Resiliency Cloud integration in Martini

Objective

Establish access to the Druva API using an appropriately permissioned application and environment-specific OAuth credentials.

Instructions in Martini

  • Create or select a Druva API application for the required operations
  • Store the client ID and secret in Martini environment configuration or secrets
  • Confirm the token endpoint, API region, tenant context, permissions, and token lifetime
  • Use separate credentials for development, testing, and production

Objective

Select an event-driven, scheduled, or API-led entry point based on Druva event coverage and the integration use case.

Instructions in Martini

  • Use a Martini API endpoint for applicable Druva notifications
  • Use a scheduler for reconciliation and incremental synchronization
  • Expose a Martini API when downstream systems submit recovery requests
  • Do not assume every Druva object has webhook coverage

Objective

Call the required Druva REST resources and handle pagination, filters, continuation data, and asynchronous operation status.

Instructions in Martini

  • Call the documented Druva endpoint with a bearer token
  • Follow page tokens, offsets, or continuation links exactly as returned
  • Use time or status filters where available
  • Persist operation identifiers for long-running recovery or export activities

Objective

Coordinate enrichment, branching, asynchronous processing, and downstream writes in a maintainable Martini workflow.

Instructions in Martini

  • Separate notification acknowledgement from longer processing when appropriate
  • Retrieve additional Workloads, Devices, Policies, or alert context when needed
  • Branch on success, failure, timeout, cancellation, or incomplete states
  • Use bounded concurrency for large tenants

Objective

Transform Druva payloads into a canonical enterprise model while validating required fields and preserving source identifiers.

Instructions in Martini

  • Map Druva object fields to the target data model
  • Normalize protection status, severity, timestamps, and identifiers
  • Validate required values before external writes
  • Retain raw or unknown fields when auditability requires them

Objective

Apply enterprise-specific compliance, routing, deduplication, and recovery authorization rules before writing downstream results.

Instructions in Martini

  • Use alert, job, operation, or deterministic composite identifiers for idempotency
  • Flag stale devices and unsuccessful protection states
  • Restrict recovery operations to authorized requests
  • Use overlap windows and reconciliation rules for delayed updates

Common Druva Data Resiliency Cloud data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
OrganizationsScope customer, tenant, or organizational administration and protection data.ServiceNow, governance platforms, reporting platformsMartini retrieves organization context, uses it to route or scope processing, and retains the source identifier in the canonical model.
UsersRepresent protected or administrative users associated with SaaS applications, endpoints, or Druva administration.Identity governance, inventory platforms, reporting systemsMartini pages through Users, maps ownership and protection attributes, and applies validation and incremental synchronization rules.
DevicesRepresent protected endpoint devices and their backup or protection status.ServiceNow, IT inventory, security operations platformsMartini retrieves Devices, associates them with users or departments where available, flags stale or unprotected devices, and sends exceptions downstream.
Backup PoliciesDefine protection schedules, retention, workload coverage, and related backup behavior.Governance platforms, reporting systems, operational dashboardsMartini normalizes policy attributes, compares them with expected controls, and generates compliance or remediation outputs.
WorkloadsRepresent protected workload types or workload instances such as Microsoft 365, Google Workspace, endpoints, VMware, or cloud infrastructure.Reporting platforms, governance tools, security operations systemsMartini uses workload identifiers and status fields to correlate protection results, apply tenant-specific rules, and publish normalized summaries.
Alerts and EventsCarry operational, protection, compliance, or security notifications for selected Druva scenarios.ServiceNow, Splunk, Microsoft Sentinel, JiraMartini receives applicable notifications or retrieves them through polling, validates source identifiers, deduplicates deliveries, enriches context, and routes the result.

Authentication and security considerations

OAuth 2.0-style application authentication

Druva Data Resiliency Cloud APIs use application credentials to obtain bearer access tokens. The exact token endpoint, permissions, scopes, and regional API details can vary by service and tenant.

Least privilege and secret management

  • Store Druva client IDs, client secrets, and related configuration in protected Martini environment secrets.
  • Use separate API clients for development, testing, and production.
  • Grant only the permissions required for protection, reporting, recovery, administration, or compliance workflows.
  • Plan credential rotation without interrupting scheduled or asynchronous workflows.

Recovery and data protection

Restrict recovery operations, avoid placing recovered content or sensitive metadata in logs, and apply retention, deletion, tenant-boundary, and regional data-residency rules to exported Druva data.

Operational considerations for Druva Data Resiliency Cloud integrations

Pagination and rate limits

Treat Druva list endpoints as paginated unless documented otherwise. Confirm quotas and concurrency limits for the relevant API family, use bounded concurrency, and apply exponential backoff for throttling and transient server errors.

Checkpoints and idempotency

Persist a synchronization checkpoint only after the complete page or window succeeds. Use alert IDs, job IDs, operation IDs, recovery request IDs, or deterministic composite keys to make retries safe and prevent duplicate downstream incidents or recovery submissions.

Asynchronous operations

Persist operation identifiers, poll at controlled intervals, and distinguish successful, failed, cancelled, expired, partially completed, and timed-out states. Do not submit a second recovery operation merely because a status poll timed out.

Events and schema changes

Event coverage is scenario-specific. Handle duplicate and out-of-order notifications, reconcile periodically against Druva APIs, validate required fields, and monitor workload-specific schema and API-version changes.

Why use Martini instead of scripts or point-to-point integrations?

Orchestration beyond point-to-point calls

Martini coordinates Druva API calls, event handling, scheduled polling, enrichment, asynchronous job monitoring, and downstream writes in reusable workflows instead of embedding this logic in isolated scripts.

Reliable data movement

Mappings, validation, business rules, checkpoints, idempotency, retries, and error routing can be implemented consistently across Druva integrations with ServiceNow, security platforms, reporting tools, and enterprise applications.

Controlled API access

Martini can expose a governed API façade for recovery requests or status queries, allowing downstream applications to use controlled contracts without handling Druva credentials or API-specific orchestration.

Maintainable delivery

Environment-specific secrets, reusable workflows, monitoring, troubleshooting, and deployment practices make the integration easier to operate as Druva API families, workload models, and enterprise requirements evolve.

Frequently asked questions

How can Druva Data Resiliency Cloud be integrated with enterprise systems?

Druva Data Resiliency Cloud can be integrated through its REST APIs, selected event or notification mechanisms, asynchronous operation endpoints, supported recovery or export functions, and OAuth 2.0-style bearer-token authentication. Scheduled polling is appropriate when a required event is not covered or when reconciliation is needed.

Can Martini integrate with Druva Data Resiliency Cloud?

Yes. Martini can consume Druva REST APIs, store OAuth credentials securely, receive applicable Druva notifications through an exposed API endpoint, schedule incremental synchronization, orchestrate recovery jobs, and map Druva data into operational, governance, security, or reporting systems.

Do I need a connector to integrate Druva Data Resiliency Cloud with Martini?

No. A dedicated Druva connector is not required. Martini can integrate using Druva's documented REST APIs, applicable event or webhook mechanisms, OAuth authentication, supported recovery or export operations, and scheduled workflows.

Is there any extra Lonti cost to integrate Druva Data Resiliency Cloud with Martini?

Lonti does not charge an additional per-connector or per-vendor fee to integrate Druva Data Resiliency Cloud. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Druva, cloud infrastructure, or other third-party systems based on subscription, usage, and deployment model.

Which Druva integration methods should new implementations use?

REST APIs are the primary method for administration, protection data, workload information, reporting, and selected operations. Use Druva event notifications where the required scenario is supported, and use scheduled polling or reconciliation for uncovered events. Long-running recovery or export activities should use documented asynchronous job-status patterns.

Can Martini receive Druva Data Resiliency Cloud events in real time?

Only for scenarios covered by Druva's supported event or notification mechanisms. Coverage is selected rather than universal for every object and state transition. Martini can receive applicable notifications through an API endpoint and use scheduled API reconciliation to identify missed or unsupported changes.

How does synchronization with Druva Data Resiliency Cloud handle large tenants?

Martini can process paginated Druva responses, use server-side time or status filters where available, persist checkpoints, and apply a small overlap window for late-arriving updates. Bounded concurrency, throttling controls, retries for transient responses, and periodic reconciliation help maintain reliable synchronization.

Can Martini expose an API façade for Druva recovery operations?

Yes. Martini can expose a controlled API that validates a recovery request, applies authorization and business rules, submits the corresponding Druva operation, and returns an accepted response for asynchronous processing. A separate workflow can monitor the operation and publish the final status without exposing Druva credentials to callers.

Related Martini documentation

Druva APIs

Triggers

Workflows

Security

Operations

Connect Druva Data Resiliency Cloud with your enterprise systems

Use Martini to build secure, observable workflows around Druva Data Resiliency Cloud APIs, notifications, recovery operations, and scheduled synchronization.

EXPLORE MARTINI
BOOK A DEMO