SiteRecoveryManagementClient

★ Only Publicly Available OpenAPI DocumentCloud InfrastructureComputeoauth2126 EndpointsREST

For Agents

Configure replication fabrics, protect VMs, run test and planned failovers, and manage recovery plans on an Azure Recovery Services vault.

Connect the SiteRecoveryManagementClient to your agent

Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the SiteRecoveryManagementClient, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.

Install Jentic One Beta (Self-Hosted)

Jentic One Host machine

# On the machine that will host your Jentic One instance:
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh

Agent machine

# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh
jentic register       # connects your agent to your Jentic One instance

Jentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.

Capabilities

What an agent can do with SiteRecoveryManagementClient API.

Create protection containers and the replication policies applied to them

Discover protectable items in a fabric and enroll them for replication

Run test failovers without affecting the source workload

GET STARTED

Start building with SiteRecoveryManagementClient API

Explore with Jentic

View OpenAPI Document

Jentic publishes the only available OpenAPI document for SiteRecoveryManagementClient, keeping it validated and agent-ready.

Jentic publishes the only available OpenAPI specification for SiteRecoveryManagementClient, keeping it validated and agent-ready. The Azure Site Recovery API exposes the replication surface of the Microsoft.RecoveryServices resource provider so agents can configure fabrics, protection containers, replication policies, recovery plans, network mappings, and individual replicated items. It supports the full disaster-recovery and migration lifecycle — protecting VMs, running planned and unplanned failovers, executing test failovers, committing migrations, and managing alerts and events on a Recovery Services vault.

Use Cases

Patterns agents use SiteRecoveryManagementClient API for, with concrete tasks.

★ Disaster Recovery Drills

Resilience teams run scheduled DR drills without disrupting production. The testMigrate and testFailover endpoints spin up isolated copies of replicated workloads in the target region, give the team time to validate the runbook, and the test cleanup endpoints tear the test environment down — all driven by an agent following a runbook rather than an analyst clicking through the portal.

Call testFailover on a recoveryPlan with the target network, verify the test items come up healthy, then call testFailoverCleanup

Workload Replication Onboarding

Migration teams enroll on-premises or cross-region VMs for replication into Azure. The replicationProtectionContainers/discoverProtectableItem endpoint scans a fabric for items that can be protected, and the replicationProtectedItems endpoints enroll the chosen item into a replication policy, so an agent can onboard a fleet of VMs in a single batched flow.

Call discoverProtectableItem on the protection container, then PUT replicationProtectedItems entries enrolling each discovered VM into the chosen policy

Migration Cutover Automation

Cloud migration teams cut over workloads from on-premises VMware or AWS into Azure as part of a planned migration window. The replicationMigrationItems migrate endpoint promotes the replicated item to the target region and the testMigrate endpoint validates the cutover plan first, so an agent can drive a sequence of migrations against the calendar.

Call testMigrate on each migrationItem to validate, then on the migration window call migrate to commit each item to the target

AI Agent DR Orchestration

An agent built on Jentic drives a DR orchestration runbook end-to-end. It discovers protectable items, applies the relevant replication policy, schedules the test failover, parses replicationEvents to confirm health, and pages an analyst with a structured summary — without anyone opening the Site Recovery blade.

Search Jentic for run azure site recovery test failover, load the schemas for testFailover and replicationEvents, and execute a test failover then summarise the events back to the user

Key Endpoints

126 endpoints — jentic publishes the only available openapi specification for siterecoverymanagementclient, keeping it validated and agent-ready.

METHOD

PATH

DESCRIPTION

GET

/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.RecoveryServices/vaults/{resourceName}/replicationFabrics

List replication fabrics in a vault

PUT

/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.RecoveryServices/vaults/{resourceName}/replicationFabrics/{fabricName}

POST

/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.RecoveryServices/vaults/{resourceName}/replicationFabrics/{fabricName}/replicationProtectionContainers/{protectionContainerName}/discoverProtectableItem

Discover items in a fabric that can be protected

POST

Commit a migration to the target region

POST

Run a test migration without committing

GET

/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.RecoveryServices/vaults/{resourceName}/replicationEvents

List replication events for the vault

GET

/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.RecoveryServices/vaults/{resourceName}/replicationFabrics

List replication fabrics in a vault

PUT

/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.RecoveryServices/vaults/{resourceName}/replicationFabrics/{fabricName}

POST

Discover items in a fabric that can be protected

POST

Commit a migration to the target region

Why though Jentic?

Three things that make agents converge on Jentic-routed access.

Credential isolation

Azure AD service principal credentials sit encrypted in the Jentic vault. Agents receive a short-lived bearer token scoped to user_impersonation — raw secrets never enter the agent context, which matters when DR runbooks are executed from chat-driven workflows.

Intent-based discovery

Agents search Jentic by intent such as run azure site recovery test failover or migrate vm to azure and Jentic returns the matching Microsoft.RecoveryServices replication operation with its full input schema.

Time to first call

Direct integration with the Site Recovery ARM endpoints: 3-5 days for AAD setup, async operation polling, recovery plan modeling, and ARM error handling. Through Jentic: under 2 hours — search, load schema, execute.

Related APIs

Alternatives and complements available in the Jentic catalogue.

Complementary

Azure Recovery Services Backup

Backup and restore on the same Recovery Services vault

Use Recovery Services Backup for point-in-time backup; use Site Recovery for replication and failover

Complementary

Recovery Services Vault Management

Manages the parent Recovery Services vault that hosts ASR and backup

Use Recovery Services to provision the vault before configuring Site Recovery on it

Alternative

Azure Migrate

Higher-level migration assessment and orchestration product built on top of Site Recovery

Use Azure Migrate for assessment-driven migrations; use Site Recovery directly for fine-grained replication control

FAQs

Specific to using SiteRecoveryManagementClient API through Jentic.

Why is there no official OpenAPI spec for SiteRecoveryManagementClient?

Microsoft Azure does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call SiteRecoveryManagementClient via structured tooling. It is validated against the live API and kept up to date. Get started at https://app.jentic.com/sign-up.

What authentication does the Site Recovery API use?

It uses Azure AD OAuth 2.0 with the implicit flow against https://login.microsoftonline.com/common/oauth2/authorize and the user_impersonation scope. When called through Jentic, your AAD service principal credentials live in the Jentic vault and the agent receives only a short-lived bearer token scoped to the Recovery Services vault.

Can I run a test failover with this API?

Yes. POST to /.../replicationProtectionContainers/{protectionContainerName}/replicationMigrationItems/{migrationItemName}/testMigrate or the equivalent testFailover endpoint on a recovery plan. The test runs against an isolated network and the matching cleanup endpoint tears it down without affecting production.

How do I migrate a workload to Azure with this API?

Discover the protectable item via /.../discoverProtectableItem, enroll it as a replicationMigrationItem with a policy, validate with testMigrate, then POST migrate on the migrationItem to commit the cutover. Each step is async and returns an asyncOperation URL to poll.

What are the rate limits for this API?

Azure Resource Manager throttles around 12,000 reads and 1,200 writes per hour per principal at subscription scope, surfaced via x-ms-ratelimit-remaining-subscription-reads and x-ms-ratelimit-remaining-subscription-writes headers. Site Recovery operations are predominantly async with poll-based completion via asyncOperation URLs.

How do I orchestrate a DR drill through Jentic?

Search Jentic for run azure site recovery test failover, load the schemas for the testFailover and testFailoverCleanup operations on the recovery plan, and execute them in sequence around the drill window. The Jentic Python SDK ships the search, load, execute pattern after pip install jentic.

Does this API also handle backup?

No — backup lives under the related Recovery Services Backup API surface. Site Recovery handles replication and failover; backup handles point-in-time backup and restore. Both share the same Recovery Services vault as the parent resource.