Clone a versioned hierarchy instance

Learn more about how to use the Clone hierarchy API to clone a hierarchy instance.

Use the Clone a hierarchy instance to create a new hierarchy by cloning an existing hierarchy instance. All hierarchy connections are cloned automatically. This operation requires the MDM.Data.Hierarchy permission with the CREATE privilege.

HTTP method and endpoint

Use the following HTTP method and endpoint path to submit the request:

POST https://<environment>.reltio.com/reltio/api/{tenantId}/hierarchies/{instanceId}/clone

Request headers

The following request headers must be included.


Header	Value	Required
`Authorization`	`Bearer <token>`	Yes

Request body

The request body is a JSON array of connection definition objects.


Field		Type	Required	Description
`type`	—	String	Yes	The hierarchy type name as defined in the business configuration.
`name`	—	String	Yes	The name of the new hierarchy. It must be unique in the tenant.
`hasVersioning`	—	Boolean	No	Indicates whether the cloned hierarchy is versioned.
`version`	—	Object	Yes, if `hasVersioning=true`	The object that describes the version to create.
	`name`	String	See `version`	The name of the version.
	`status`	String	See `version`	Optional. The status of the version.
	`effectiveStartDate`	String	See `version`	Optional. The start effective date of the version in ISO 8601 date format.
	`effectiveEndDate`	String	See `version`	Optional. The end effective date of the version in ISO 8601 date format.
	`description`	String	See `version`	Optional. The description of the version.
	`context`	String	See `version`	Optional. Additional context for the version.

Example request

Use the following example to see how a complete request is structured with headers.

POST /prd.version1/clone
Authorization: Bearer <token>

{
  "type": "configuration/hierarchyTypes/TypeProduct",
  "name": "Cloned Product Hierarchy",
  "hasVersioning": true,
  "version": {
    "name": "Version 2",
    "status": "ACTIVE",
    "effectiveStartDate": "2024-01-01",
    "effectiveEndDate": "2026-12-31",
    "description": "longDescription",
    "context": "longContextDescription"
  }
}

Response fields

The following table describes the fields returned in the response body, which is an array of hierarchy connection objects.


Field		Type	Description
`type`	—	String	The hierarchy type name as defined in the business configuration.
`name`	—	String	The name of the hierarchy. It must be unique within the tenant.
`hasVersioning`	—	Boolean	Indicates whether the hierarchy is versioned.
`hierarchyId`	—	String	The ID of the created hierarchy.
`instanceId`	—	String	The ID of the created hierarchy instance.
`version`	—	Object	Optional. The created hierarchy version.
	`versionId`	String	The ID of the created version.
	`name`	String	The name of the version. It must be unique within the hierarchy.
	`status`	String	Optional. The status of the version.
	`effectiveStartDate`	String	Optional. The start effective date of the version in ISO 8601 date format.
	`effectiveEndDate`	String	Optional. The end effective date of the version in ISO 8601 date format.
	`description`	String	Optional. The description of the version.
	`context`	String	Optional. Additional context for the version.
`createdBy`	—	String	The username of the user who created the hierarchy.
`createdTime`	—	String	The time when the hierarchy was created, in ISO 8601 date-time format.
`updatedBy`	—	String	The username of the user who last updated the hierarchy.
`updatedTime`	—	String	The time when the hierarchy was last updated, in ISO 8601 date-time format.

Example response

The following example shows the response body.

{
  "type": "configuration/hierarchyTypes/TypeProduct",
  "name": "Cloned Product Hierarchy",
  "hasVersioning": true,
  "hierarchyId": "0ABlc0A",
  "instanceId": "0ABlc0A.0ABlgGQ",
  "version": {
    "versionId": "0ABlgGQ",
    "name": "Version 2",
    "status": "ACTIVE",
    "effectiveStartDate": "2024-01-01",
    "effectiveEndDate": "2026-12-31",
    "description": "longDescription",
    "context": "longContextDescription"
  },
  "createdBy": "email@reltio.com",
  "createdTime": "2025-04-01T13:30:00",
  "updatedBy": "email@reltio.com",
  "updatedTime": "2025-04-01T13:30:00"
}

Error codes and recommended actions

The following table lists the possible error responses returned by this API.


HTTP status	Description	Recommended action
`400 Bad Request`	The request contains invalid or missing parameters.	Review the error message, correct the request as indicated, and submit the request again. For example, if the error identifies a duplicate version name, specify a unique name before resubmitting the request.

Unify and manage your data