Getting Started
Vdisk Devgrps
Alerts Notifylists
Cloud Profiles
Cloud Unit
Data Movement Policy
Data Movement
Data Movement Stats Files
Data Movement Stats Mtrees
Data Movement Stats Recall
Managed Files
Mtrees Id Rlfiles
Mtrees Id Stats
Mtrees Id Stats Capacity
Mtree Id Stats Compressions
Network Nic
Cifs Shares
Ddboost Clients
Ddboost Storage Units
Ddboost Users
Nfs Exports
Nfs Exports Id Clients
Nfs Exports Id Referrals
Vdisk Devices
Vdisk Pools
Vdisk Stimgs
Services Asup
Services License Server
Services Log
Mdtags Services
Services Ntp
Tenant Units
Stats Capacity
Comp Measurements Support Check
Comp Measurements
Stats File Replications
Filesys Stats
Stats Performances Mtrees
Stats Systems File Replications
Support Bundles
System Repl
System Space
Sso Registration

Getting started

Introduction to Dell EMC PowerProtect DD Appliance REST API

Dell EMC PowerProtect DD Series Appliances and older Data Domain systems are disk-based appliances that run PowerProtect DD OS to provide inline deduplication for data protection and disaster recovery (DR) in the enterprise environment.

Note: In this guide, “DD system,” “the protection system,” or “the system” refers to PowerProtect DD Series Appliances that are running DD OS 7.0 or later as well as earlier Data Domain systems.

Basic concepts

REST API endpoint

The PowerProtect DD system REST API endpoint:

  • Earlier than DD OS 7.2:


The API version can be v1.0, v2.0, v3.0, and so on.

  • DD OS 7.2 or later:


The current API version is v1.

The old REST API endpoint is still supported.

Template, query paramters and object IDs

The resource URI can contain template or query parameters.

A template parameter indicates the resource on which the operation is to be performed. Template parameters should be replaced by object IDs, which are unique identifiers that are associated with DD objects. Object IDs are URL-encoded and are returned as part of a RESTful response. API users must use object IDs in GET details, and PUT and DELETE URIs to refer to a specific object.

For example, the SYSTEM-ID template parameter in the following request should be replaced by the URL-encoded ID of the PowerProtect DD system for which you want to fetch a list of users.

GET https://<DD-SYSTEM-IP/FQDN>:3009/rest/v1.0/dd-systems/{SYSTEM-ID}/users

Note: On a PowerProtect DD system, a SYSTEM-ID of 0 can be used to indicate the local PowerProtect DD system ID in place of the actual URL-encoded SYSTEM-ID.

For example, the following request retrieves the list of users on the local PowerProtect DD system:

GET https://<DD-SYSTEM-IP/FQDN>:3009/rest/v1.0/dd-systems/0/users

The ID in the GET https://<DD SYSTEM IP>:3009/rest/v1.0/dd-systems/{SYSTEMID}/users/{ID} request is also a template parameter and represents the URL-encoded unique ID of the user for whom to fetch detailed information.

The following list provides examples of URL-encoded IDs:

  • Data Domain system ID, URL encoded system UUID:
  • MTree ID, URL encoded MTree name:
  • Export ID, URL encoded export path:
  • CIFS share, URL-encoded share name:

Query parameters provide additional criteria to which the response data must conform. Query parameters are part of the URL query string and must contain URL-encoded values. For example, the following query fetches a list of users on a specific PowerProtect DD system starting at page one, and assuming each page has five users:

GET https://<DD-SYSTEM-IP/FQDN>:3009/rest/v1.0/dd-systems/0/users?page=1&size=5

If a request is sent with an incomplete URI, a list of related links may be returned for the client to correct itself. For example, if client sends a GET /rest/v1.0/dd-systems/0/protocols request, it returns the following response:

"details": "success", 
"code": 0, 
"link": [
 "rel": "parent", 
 "href": "/rest/v1.0/dd-systems/0"
 "rel": "nfs", 
 "href": "/rest/v1.0/dd-systems/0/protocols/nfs"
 "rel": "cifs", 
 "href": "/rest/v1.0/dd-systems/0/protocols/cifs"
 "rel": "vdisk", 
 "href": "/rest/v1.0/dd-systems/0/protocols/vdisk"
 "rel": "ddboost", 
 "href": "/rest/v1.0/dd-systems/0/protocols/ddboost"

Data formats

The PowerProtect DD system REST API supports XML and JSON data formats. The client can choose the data format in its request and response. In the HTTP header, use Content-Type header to specify the request format, and use Accept header to specify the expected response format.

Content-Type: application/xml or application/json
Accept: application/xml or application/json

The PowerProtect DD system, as the server, uses the following rules to determine the format of requests and responses:

  • If Content-Type is set, the server expects the input data to be in the specified format. If the Accept header is specified, the server response must be in the specified data type format.
  • If the Content-Type header is specified but the Accept is not, the format of response data is the same as the request data.
  • If neither the Content-Type nor the Accept headers is specified, the default format for both request and response types is assumed to be application/json.

PowerProtect DD concepts

Concept Description
Alert Named as is. Anything that needs your attention.
Audit Log Records critical operations and changes being done to the system.

Best practices

Backward and forward compatibility

As additional features are added to the product, APIs may change. Observe these common practices when dealing with API changes:

  • Deprecated APIs and fields: Do not use them. Deprecated APIs and fields are removed when the infrastructure no longer supports them.
  • Handling requests and responses in JSON: Exercise flexibility and tolerance with unrecognized fields and enumerations. New fields and enumerations might be added in support of new features such as a new asset type or new protection type. If you do not use them, ignore these fields and enumerations when they are not recognized.


Contact support here: