Content Management API

The Log in to your account request is used to sign in to your Contentstack account and obtain the authtoken.

Note: The authtoken is a mandatory parameter when executing Content Management API calls. However, when executing Content Delivery API calls, use the Content Delivery base URL for your region, and pass the environment-specific delivery token against the access_token key.

In the 'Body' section, enter the user credentials in JSON format. The JSON query will include the email address, the Contentstack user account password, and the two-factor authentication token (if enabled) received in the Authy app or SMS.

For SSO-enabled organizations, the ‘Log in to your account’ request will not return the user authtoken for users. In this case, you can try out the following:

• The owner of an organization can access the SSO-enabled organization through Contentstack credentials and retrieve the user authtoken to make Content Management API requests.
• Disable 'Strict Mode' for an SSO-enabled organization, and users who have the ability to access their organization through Contentstack credentials can retrieve the authtoken to make Content Management API requests.

For more details, refer the REST API Usage - Content Management API section in the Single Sign-On page.

The Log out of your account call is used to sign out the user of Contentstack account.

The Get user call returns comprehensive information of an existing user account. The information returned includes details of the stacks owned by and shared with the specified user account.

The Update User API Request updates the details of an existing user account. Only the information entered here will be updated, the existing data will remain unaffected.

When executing the API call, under the 'Body' section, enter the information of the user that you wish to update. This information should be in JSON format.

Note: To update the role of an existing user, refer the Update Existing User Role API Request.

The Activate a user account call activates the account of a user after signing up. For account activation, you will require the token received in the activation email.

The Request for a password API helps to get a temporary password to log into an account in case a user has forgotten the login password.

Using this temporary password, you can log in to your account and set a new password for your Contentstack account.

In the 'Body' section, provide the user's email address in JSON format.

Note: The “Reset password” token that you receive in your email address is valid only for the next 60 minutes after it’s generated. Post that, it expires and you need to rerun the Reset password API request to generate a new token.

The Reset password API request allows you to reset your Contentstack account password.

Note: Before using this API request, you need to execute the Request for a password API request to receive the reset password token in your registered email address.

When executing the request, in the 'Body' section, you need to provide the token that you receive via email, your new password, and password confirmation in JSON format.

Note: The "Reset password" token is valid only for the next 60 minutes after it’s generated. Post that, it expires and you need to rerun the same request to generate a new token.

The Get all organizations call lists all organizations related to the system user in the order that they were created.

The Get a single organization call gets the comprehensive details of a specific organization related to the system user.

The Get all roles in an organization call gives the details of all the roles that are set to users in an Organization.

When executing the API call, provide the Organization's UID.

The Add users to organization call allows you to send invitations to add users to your organization. Only the owner or the admin of the organization can add users.

When executing the API call, provide the Organization UID.

The Remove users from organization request allows you to remove existing users from your organization.

Note: Only the owner or the admin of the organization can remove users.

When executing the API request, provide the organization UID. In the “Body” section, you need to enter the email IDs of the users you want to remove from the organization as follows:

{
  "emails":[
    "abc@sample.com", "xyz@sample.com"
  ]
}

The Resend pending organization invitation call allows you to resend Organization invitations to users who have not yet accepted the earlier invitation. Only the owner or the admin of the Organization can resend the invitation to add users to an Organization.

When executing the API call, provide the Organization UID.

The Get all organization invitations call gives you a list of all the Organization invitations. Only the owner or the admin of the Organization can resend the invitation to add users to an Organization.

When executing the API call, provide the Organization UID.

The Transfer organization ownership call transfers the ownership of an Organization to another user. When the call is executed, an email invitation for accepting the ownership of a particular Organization is sent to the specified user.

Once the specified user accepts the invitation by clicking on the link provided in the email, the ownership of the Organization gets transferred to the new user. Subsequently, the previous owner will no longer have any permission on the Organization.

When executing the API call, provide the Organization UID.

The Get all stacks in an organization call fetches the list of all stacks in an Organization.

When executing the API call, provide the Organization UID.

The Get organization log details request is used to retrieve the audit log details of an organization.

You can apply queries to filter the results. Refer to the Queries section for more details.

Tip: This request returns only the first 25 audit log items of the specified organization. If you get more than 25 items in your response, refer the Pagination section to retrieve all the log items in paginated form.

The Get organization log item request is used to retrieve a specific item from the audit log of an organization.

The Get a single stack call fetches comprehensive details of a specific stack.

Note: For SSO-enabled organizations, it is mandatory to pass the organization UID in the header.

The Get all stacks call fetches the list of all stacks owned by and shared with a particular user account.

Note: For SSO-enabled organizations, it is mandatory to pass the organization UID in the header.

The Create stack call creates a new stack in your Contentstack account.

In the 'Body' section, provide the schema of the stack in JSON format.

Note: At any given point of time, an organization can create only one stack per minute.

The Update stack call lets you update the name and description of an existing stack.

In the 'Body' section, provide the updated schema of the stack in JSON format.

Warning: The master locale cannot be changed once it is set while stack creation. So, you cannot use this call to change/update the master language.

The Delete stack call is used to delete an existing stack permanently from your Contentstack account.

The Get all users of a stack call fetches the list of all users of a particular stack

The Update User Role API Request updates the roles of an existing user account. This API Request will override the existing roles assigned to a user. For example, we have an existing user with the "Developer" role, and if you execute this API request with "Content Manager" role, the user role will lose "Developer" rights and the user role be updated to just "Content Manager".

When executing the API call, under the 'Body' section, enter the UIDs of roles that you want to assign a user. This information should be in JSON format.

The Transfer stack ownership to other users call sends the specified user an email invitation for accepting the ownership of a particular stack.

Once the specified user accepts the invitation by clicking on the link provided in the email, the ownership of the stack gets transferred to the new user. Subsequently, the previous owner will no longer have any permission on the stack.

In the 'Body' section, you need to provide the email address of the user to whom you wish to transfer the ownership of the stack in JSON format.

Additional Resource: To transfer ownership of a stack to other users via Contentstack's UI, refer to the Transfer Stack Ownership article. 

The Accept stack owned by other user call allows a user to accept the ownership of a particular stack via an email invitation.

The email invitation includes a link (i.e., /stack/accept_ownership/{ownership_token}?api_key={api_key}&uid={user_uid} ) that consists of the ownership token, the API key, and user uid.

Once the user accepts the invitation by clicking on the link, the ownership is transferred to the new user account. Subsequently, the user who transferred the stack will no longer have any permission on the stack.

When executing the API call, in the 'URI Parameters' section, you need to provide the ownership token and the user uid that you received in the invitation mail.

The Get stack settings call retrieves the configuration settings of an existing stack.

The Add stack settings request lets you add additional settings for your existing stack.

You can add specific settings for your stack by passing any of the following parameters within the stack_variables section in the “Request Body”:

• "enforce_unique_urls": true: To ensure that entry URLs are not duplicated across the stack.
• "sys_rte_allowed_tags": "figure, style, script": You can pass a combination of the three values, figure, style, and script, to this parameter (e.g., "sys_rte_allowed_tags": "figure, style, script", "sys_rte_allowed_tags": "figure", etc.):
  
  • figure: To wrap images inside the “Rich Text Editor” field within the <figure> tag.
  • style: To be able to use the <style> tag within the HTML code of a “Rich Text Editor” field.
  • script: To be able to use the <script> tag within the HTML code of a “Rich Text Editor” field.
    

    Note: Contentstack highly recommends that you avoid using the <script> tag within the HTML code of a “Rich Text Editor” field due to its security vulnerabilities.

• "sys_rte_skip_format_on_paste": "GD:font-size": You can use this key to skipping the font size attribute when pasting content from a vendor. In this case, GD stands for the vendor prefix (Google Document), while font size is the attribute to be skipped.

  Note: We are currently only supporting one attribute (GD:font-size) for this key. This is only applicable for the HTML Rich Text Editor. For more information, refer to the API Change Log for this update.

Additionally, you can pass "cs_only_breakline": true under the "rte" parameter to ensure that only a br tag is added inside the “Rich Text Editor” field when the content manager presses “Enter”. When this parameter is set to false, the br tag is replaced with <p></p>.

Here’s a sample of the Request Body:

{
  "stack_settings":{
    "stack_variables":{
      "enforce_unique_urls":true,
      "sys_rte_allowed_tags":"style, figure, script",
      "sys_rte_skip_format_on_paste": "GD:font-size"
    },
    "rte":{
      "cs_only_breakline":true
    }
  }
}

The Reset stack settings call resets your stack to default settings, and additionally, lets you add parameters to or modify the settings of an existing stack.

The Share a stack call shares a stack with the specified user to collaborate on the stack.

In the 'Body' section, you need to provide the email ID of the user with whom you wish to share the stack along with the role uid that you wish to assign the user.

The Unshare a stack call unshares a stack with a user and removes the user account from the list of collaborators. Once this call is executed, the user will not be able to view the stack in their account.

In the 'Body' section, you need to provide the email ID of the user from whom you wish to unshare the stack.

The Get all branches request returns comprehensive information of all the branches available in a particular stack in your account.

Note: You need to use either the stack’s Management Token or the user Authtoken (any one is mandatory), along with the stack API key, to make a valid Content Management API request. Read more about authentication.

You can add queries to extend the functionality of this API call. Under the 'URL Parameters' section, insert a parameter named query and provide a query in JSON format as the value. (Refer Queries)

The Get a single branch request returns information of a specific branch.

The Create a branch request creates a new branch in a particular stack of your organization.

Note: Only stack owners, admins, and developers can create a new branch. You must only use the auth token to create a branch.

In the “Body” section, you need to provide a custom UID for the new branch and also the UID of the source branch from which it will inherit data.

The Delete a branch request deletes an existing branch and all the content within it.

To confirm the deletion of a branch, you need to specify the force=true query parameter.

Note: You need to delete the child branches before deleting the parent branch. If a branch is the source for any other branch, irrespective of whether you pass a force parameter or not, the API will not allow you to delete that branch.
You must only use the auth token to delete a branch.

Additional Resources: Deleting a branch also deletes the alias pointing towards it.

When executing the API call, in the “URL Parameters” section, provide the UID of your branch.

The Get all aliases request returns comprehensive information of all the aliases available in a particular stack in your account.

The Get a single alias request returns information of a specific alias.

The Assign an alias request creates a new alias in a particular stack of your organization. This alias can point to any existing branch (target branch) of your stack.

Note: Only stack owners, admins, and developers can assign a new alias to a branch. You must only use the auth token to assign an alias.

The Delete an alias request deletes an existing alias.

To confirm the deletion of an alias, you need to specify the force=true query parameter.

When executing the API call, in the “URL Parameters” section, provide the UID of your alias.

Note: You must only use the auth token to delete an alias.

The Get all content types call returns comprehensive information of all the content types available in a particular stack in your account.

Note: You need to use either the stack’s Management Token or the user Authtoken (any one is mandatory), along with the stack API key, to make a valid Content Management API request. Read more about authentication.

When executing the API call, you can add queries to extend the functionality of this API call.

Tip: If any of your content types contains a Global field and you wish to fetch the content schema of the Global field, then you need to pass theinclude_global_field_schema:true parameter. This parameter helps return the Global field's schema along with the content type schema.

Under the 'URI Parameters' section, insert a parameter named query and provide a query in JSON format as the value. (To learn more about the queries, refer to the Queries section of the Content Delivery API doc.)

Note: This API request will return a maximum of 100 content types. To retrieve the next batch of content types, make use of the skip parameter (or refer Pagination for more details).

The Get a single content type call returns information of a specific content type.

Note: You need to use either the stack’s Management Token or the user Authtoken (any one is mandatory), along with the stack API key, to make a valid Content Management API request. Read more about authentication.

Enter the version of the content type of which you want to retrieve the details as a query parameter. If no version is specified, you will get the latest version of the content type.

Note: The schema of the content type returned will depend on the provided version. If no version is specified, you will get the latest version of the content type.

To learn more about the queries, refer to the Queries section of the Content Delivery API doc.

Tip: If any of your content types contains a Global field and you wish to fetch the content schema of the Global field, then you need to pass theinclude_global_field_schema:true parameter. This parameter helps return the Global field's schema along with the content type schema.

The Create a content type call creates a new content type in a particular stack of your Contentstack account.

In the “Body” section, you need to provide the complete schema of the content type. You can refer the JSON schema for creating a content type document to know how you can add fields into your content type through API.

Note: You need to use either the stack’s Management Token or the user Authtoken (any one is mandatory), along with the stack API key, to make a valid Content Management API request. Read more about Authentication.

To mark a field as non-unique, you need to set the unique parameter to false. For example, to remove the unique constraint on the default 'title' field, you need to update the JSON schema of the title field as follows:

{
    "display_name": "Title",
    "uid": "title",
    "data_type": "text",
    "mandatory": true,
    "unique": false,
    "field_metadata": {
      "_default": true
    },
    "multiple": false
}

Create Content Type with Select Field

The Create content type with select field request allows you to add a Select field while creating a content type. You can add choices within the Select field either in the form of single values or key-value pairs.

To add single-value choices, under enum, set the advanced parameter to false and define the choice values under the choices parameter.

The schema of the Select field will look as follows:

"enum":{
    "advanced":false,
    "choices":[
        {
            "value":"1"
        },
        {
            "value":"2"
        },
        {
            "value":"3"
        }
    ]
},

To add key-value pairs as choices, under enum, set the advanced parameter to true and define the key-value choices under the choices parameter.

The schema of the Select field that contains key-value pairs will look as follows:

"enum":{
    "advanced":true,
    "choices":[
        {
            "key":"New York",
            "value":"NY"
        },
        {
            "key":"India",
            "value":"IN"
        },
        {
            "key":"Australia",
            "value":"AUS"
        }
    ]
},

Additional Resource: In the “Body” section, you need to provide the updated schema of your content type with the select field schema. You can refer to the Select field JSON schema document to know how you can add/update schema for the Select field in your content type through API.

Create Content Type with JSON RTE

The Create content type with JSON RTE request shows you how to add a JSON RTE field while creating a content type.

In the “Body” section, you need to provide the complete schema of the content type with the JSON RTE schema as follows. You can find more details in the JSON schema of the JSON RTE document.

{
  "data_type":"json",
  "display_name":"JSON RTE",
  "uid":"json_rte",
  "field_metadata":{
    "allow_json_rte":true,
    "rich_text_type":"advanced",
    "description":"",
    "default_value":""
  },
  "reference_to":[
    "content_type_uid"
  ],
  "non_localizable":false,
  "multiple":false,
  "mandatory":false,
  "unique":false
}

Under the reference_to parameter, mention the UIDs of the content types whose entries you wish to embed within the JSON RTE field.

Create content type with custom asset field

The Create content type with custom asset field request is used to create a content type with a custom field that accepts data of type asset.

The Update Content Type call is used to update the schema of an existing content type.

Note: Whenever you update a content type, it will auto-increment the content type version.

When executing the API call, in the “URI Parameters” section, provide the uid of your content type.

In the “Body” section, you need to provide the updated schema of your content type. You can refer the JSON schema for creating a content type document to know how you can add/update fields in your content type through API.

Note: You need to use either the stack’s Management Token or the user Authtoken (any one is mandatory), along with the stack API key, to make a valid Content Management API request. Read more about authentication.

The Set Field Visibility Rule for Content Type API request lets you add Field Visibility Rules to existing content types. These rules allow you to show and hide fields based on the state or value of certain fields.

Field Visibility Rules can be set while creating your content type (via UI, only after you’ve added all the required fields to the content type and saved it) or while editing a content type (both via UI and API).

To set a Field Visibility Rule, you need to add the following code snippet in the Request body of the content type:

{
    ...
    "content_type": {
        "field_rules": [{
            "conditions": [{
                "operand_field": "operand_field_uid",
                "operator": "equals",
                "value": "value_corresponding_to_operator"
            }],
            "match_type": "all",
            "actions": [{
                "action": "show",
                "target_field": "target_field_uid"
            }]
        }]
    }
    ...
}

Let’s look at the keys used in the above code snippet:

• operand_field: Pass the UID of the Operand field (operand_field_uid) i.e., the field on which you want to set the condition.
• operator: Pass the operator that you want to act on the operand field. Here’s the list of operators that are applicable based on the data type of your operand field:
  
  

  Data Types	Operations
  Text	matches, does_not_match, starts_with, ends_with, contains
  Number	equals, not_equals, less_than, greater_than, less_than_or_equals, greater_than_or_equals
  Date	equals, not_equals, before_date, after_date
  Boolean	is, is_not
  Select	is, is_not
  Reference	is, is_not

• value: Pass the value that is corresponding to the operator that you have used. Note that for Date data type, you need to pass the date in ISO format.
• match_type: You need to pass either all or any depending on whether you want all your conditions or any one of your conditions to be met.
• action: You need to pass either show or hide depending on whether you want to show or hide the Target field.
• target_field: Pass the UID of the Target field (target_field_uid) i.e., the field on which you want to perform the action.

For more details, check out the Define Conditions section when adding a Field Visibility Rule.

The Delete Content Type call deletes an existing content type and all the entries within it.

When executing the API call, in the “URI Parameters” section, provide the UID of your content type.

Note: You need to use either the stack’s Management Token or the user Authtoken (any one is mandatory), along with the stack API key, to make a valid Content Management API request. Read more about Authentication.

The Get all references of content type call will fetch all the content types in which a specified content type is referenced.

Note: You need to use either the stack’s Management Token or the user Authtoken (any one is mandatory), along with the stack API key, to make a valid Content Management API request. Read more about authentication.

Additionally. to fetch all Global fields in which the specified content type is referenced, you need to pass include_global_fields as a query parameter. Set this parameter to true to include the Global fields along with the content types.

This call is used to export a specific content type and its schema. The data is exported in JSON format.

However, please note that the entries of the specified content type are not exported through this call.

The schema of the content type returned will depend on the version number provided.

Note: You need to use either the stack’s Management Token or the user Authtoken (any one is mandatory), along with the stack API key, to make a valid Content Management API request. Read more about authentication.

The Import a content type call imports a content type into a stack by uploading JSON file.

Note: You need to use either the stack’s Management Token or the user Authtoken (any one is mandatory), along with the stack API key, to make a valid Content Management API request. Read more about authentication.

Tip: You can try the call manually in any REST API client, such as Postman. You can export the required content type's JSON file, make the necessary changes to the data and then import the content type. While importing, you need to pass a form-data parameter named content_type and select the input type as 'File'. Then, select the JSON file of the content type that you wish to import.

The Get all global fields call returns comprehensive information of all the global fields available in a particular stack in your account.

Note: You need to use either the stack’s Management Token or the user Authtoken (any one is mandatory), along with the stack API key, to make a valid Content Management API request. Read more about authentication.

The Get a single global field request allows you to fetch comprehensive details of a specific global field.

When executing the API call, in the 'URI Parameters' section, provide the unique ID of your global field.

Note: You need to use either the stack’s Management Token or the user Authtoken (any one is mandatory), along with the stack API key, to make a valid Content Management API request. Read more about authentication.

The Create a global field request allows you to create a new global field in a particular stack of your Contentstack account. You can use this global field in any content type within your stack.

Note: Only the stack owner, administrator, and developer can create global fields.

Note: You need to use either the stack’s Management Token or the user Authtoken (any one is mandatory), along with the stack API key, to make a valid Content Management API request. Read more about authentication.

The Update a global field request allows you to update the schema of an existing global field.

When executing the API call, in the 'URI Parameters' section, provide the unique ID of your global field.

Note: You need to use either the stack’s Management Token or the user Authtoken (any one is mandatory), along with the stack API key, to make a valid Content Management API request. Read more about authentication.

The Delete global field request allows you to delete a specific global field.

Warning: If your Global field has been referred within a particular content type, then you will need to pass an additional query parameter force:true to delete the Global field.

When executing the API call, in the 'URI Parameters' section, provide the unique ID of your global field.

Note: You need to use either the stack’s Management Token or the user Authtoken (any one is mandatory), along with the stack API key, to make a valid Content Management API request. Read more about authentication.

The Import a global field call imports a global field into a stack.

Note: You need to use either the stack’s Management Token or the user Authtoken (any one is mandatory), along with the stack API key, to make a valid Content Management API request. Read more about authentication.

To import, you need to provide/upload a JSON file that contains the schema of the global field that you wish to import.

Tip: You can try the call manually in any REST API client, such as Postman, by passing a 'Body' parameter named global_field and selecting the input type as 'File'. Then, select the JSON file of the global field that you wish to import.

This request is used to export a specific global field and its schema. The data is exported in JSON format.

Note: You need to use either the stack’s Management Token or the user Authtoken (any one is mandatory), along with the stack API key, to make a valid Content Management API request. Read more about authentication.

The Get all entries call fetches the list of all the entries of a particular content type. It also returns the content of each entry in JSON format. You can also specify the environment and locale of which you wish to get the entries.

Additionally, if you wish to fetch the metadata attached to each entry, then you need to pass include_metadata as a query parameter. Set this parameter to true to include the entry metadata along with all entries in the response body.

You will find the entry metadata under the _metadata key in the response. It will be associated with a specific extension UID as follows:

"_metadata": {
    "extensions": {
        "{extension_uid}": [{
            "image_copyrights": "Contentstack Branding",
            "scope": "local"
        }]
    }
}

You can add queries to extend the functionality of this API call. Under the URI Parameters section, insert a parameter named query and provide a query in JSON format as the value.

To learn more about the queries, refer to the Queries section of the Content Delivery API doc.

Tip: This request returns only the first 100 entries of the specified content type. If you want to fetch entries other than the first 100 in your response, refer the Pagination section to retrieve all your entries in paginated form. Also, to include the publish details in the response, make use of the include_publish_details parameter and set its value to ‘true’. This query will return the publish details of the entry in every environment along with the version number that is published in each of the environment. In addition to entry publish details, the include_publish_details parameter also fetches the entry metadata publishing details in the response. 

The Get a single entry request fetches a particular entry of a content type.

The content of the entry is returned in JSON format. You can also specify the environment and locale of which you wish to retrieve the entries.

Additionally, if you wish to fetch the metadata attached to each entry, then you need to pass include_metadata as a query parameter. Set this parameter to true to include the entry metadata along with all entries in the response body.

You will find the entry metadata under the _metadata key in the response. It will be associated with a specific extension UID as follows:

"_metadata": {
    "extensions": {
        "{extension_uid}": [{
            "image_copyrights": "Contentstack Branding",
            "scope": "local"
        }]
    }
}

Tip: To include the publish details in the response, make use of the include_publish_details parameter and set its value to ‘true’. This query will return the publish details of the entry in every environment along with the version number that is published in each of the environment. In addition to entry publish details, the include_publish_details parameter also fetches the entry metadata publishing details in the response.

Also, if no version is mentioned, this request will retrieve the latest published version of the entry. To retrieve a specific version, make use of the version parameter.

The Create an entry call creates a new entry for the selected content type.

When executing the API call, in the 'Body' section, you need to provide the content of your entry based on the content type created.

Here are some important scenarios when creating an entry.

Scenario 1: If you have a reference field in your content type, here's the format you need to follow to add the data in the ‘Body’ section

{
    "entry": {
        "title": "Entry title",
        "url": "Entry URL",
        "reference_field_uid": [{
            "uid": "blt111000d1e110b001",
            "_content_type_uid": "referred_content_type_uid"
        }]
    }
}

Scenario 2: If you need to create an entry that contains asset files, you need to provide the asset UID(s) in the ‘Body’ section.

To add a single file, enter a single UID (file_field_uid). For multiple asset files, enter the asset files’ UIDs (file_field_uid_multiple) in an array. You need to use only one of the following formats.

Here's the JSON schema for both the cases:

{
    "entry": {
        "title": "Entry title",
        "url": "Entry URL",
        "file_field_uid": "asset_uid", // ‘File’ field marked ‘Single’
        "file_field_uid_multiple": ["asset_uid1", "asset_uid2, ..."], // ‘File’ field marked ‘Multiple’
    }
}

Scenario 3: If you need to add your asset file within a Rich Text Editor, use the following JSON schema:

{
    "entry": {
        "title": "Entry title",
        "url": "Entry URL",
        "rte_uid": "<p><img src=\"asset_URL\" data-sys-asset-uid=\"asset_UID\" alt=\"alternative_text\"></p>"
    }
}

Create an Entry with JSON RTE

The Create an entry with JSON RTE request lets you create a new entry for a selected content type that contains a JSON RTE field.

When executing the API call, in the 'Body' section, you need to provide the content of your entry based on the content type created.

If you selected the Embed Objects option while creating the content type, you can embed entries within your JSON RTE field. In the 'Body' section, you need to specify the details of the entry you wish to embed.

The schema to embed an entry within the JSON RTE field is as follows:

  {
          "children":[
            {
              "text":"Embedded entry:",
              "bold":true
            },
            {
              "uid":"v4_unique_id",
              "type":"reference",
              "attrs":{
                "class-name":"embedded-entry redactor-component inline-entry",
                "content-type-uid":"content_type_uid",
                "display-type":"inline_or_block",
                "entry-uid":"uid_of_the_entry_you_want_to_embed",
                "locale":"locale_code",
                "type":"entry",
                "dirty":true
              },
              "children":[
                {
                  "text":""
                }
              ]
            },
            {
              "text":"continued text after embedding an entry."
            }
          ],
          "type":"p",
          "uid":"v4_unique_id",
          "attrs":{
            "dirty":true
          }
        }

Note: The children block should be added while creating an entry with a referenced entry and asset to help point the cursor after embedding an entry or asset. The schema of this block is as follows:
"children":[ { "text":"" } ]

The schema to embed assets within the JSON RTE field is as follows:

{
  "children":[
    {
      "text":"Embedded asset:",
      "bold":true
    },
    {
      "uid":"v4_unique_id",
      "type":"reference",
      "attrs":{
        "asset-link":"asset_link",
        "asset-name":"asset_name",
        "asset-type":"image/jpg",
        "asset-uid":"uid_of_the_asset_you_want_to_embed",
        "class-name":"embedded-asset",
        "content-type-uid":"sys_assets", //System generated typename that points to all referenced assets
        "display-type":"display",
        "inline":false,
        "type":"asset",
        "dirty":true
      },
      "children":[
        {
          "text":""
        }
      ]
    },
    {
      "text":"continued text after embedding an asset",
      "bold":true
    }
  ],
  "type":"p",
  "uid":"v4_unique_id",
  "attrs":{
    "dirty":true
  }
}

Note: The UID within the block schema can be generated using any online V4 Unique ID generators. This block UID should be unique across the stack.

Create an Entry with Master Locale

The Create an entry with master locale request lets you create an entry in the master language of your stack if it does not already exist or has been deleted. You can use the UID of a localized entry to convert it into a master language entry.

If the master language is not accessible or does not exist, a custom user role can still create an entry in any of the other available locales. However, the entry in the master language remains non-existent.

In such a scenario, roles with access to the master locale can create an entry in the master language using the UID of the localized entry and the copy_to_master query parameter. The copy_to_master parameter allows you to copy content from the localized entry to the master language entry version of the stack.

When executing the API call, in the ‘Body’ section, you need to provide the content of your entry based on the content type created. You also need to specify the UID of the localized entry for which you want to create an entry in the master locale.

Here’s what your request body should look like:

{
    "entry": {
        "title": "Entry in the master language",
        "url": "/entry-in-the-master-language",
        "tags": [],
        "uid": "localized_entry_uid"
    }
}

Create an entry with custom asset field

The Create an entry with custom asset field request is used to create an entry with a custom field that accepts data of type asset.

The Update an entry call lets you update the content of an existing entry.

Passing the locale parameter will cause the entry to be localized in the specified locale.

Note: The Update an entry call does not allow you to update the workflow stage for an entry. To update the workflow stage for the entry, use the Set Entry Workflow Stage call.

Update an Entry with JSON RTE

The Update an entry with JSON RTE call lets you update the content of an existing entry.

Passing the locale parameter will cause the entry to be localized in the specified locale.

Note: While updating an entry with the JSON RTE field, the same block UID generated while creating an entry must be used.

The schema to update an embedded entry within the JSON RTE field is as follows:

{
  "children":[
    {
      "text":"Embedded entry:",
      "bold":true
    },
    {
      "uid":"v4_unique_id",
      "type":"reference",
      "attrs":{
        "class-name":"embedded-entry redactor-component inline-entry",
        "content-type-uid":"content_type_uid",
        "display-type":"inline_or_block",
        "entry-uid":"uid_of_the_entry_you_want_to_embed",
        "locale":"locale_code",
        "type":"entry",
        "dirty":"true //Set to true if you update the entry",
        "else set to false"
      },
      "children":[
        {
          "text":""
        }
      ]
    },
    {
      "text":"continued text after embedding an entry updated."
    }
  ],
  "type":"p",
  "uid":"v4_unique_id",
  "attrs":{
    "dirty":"true //Set to true if you update the entry",
    "else set to false"
  }
}

The schema to update an embedded asset within the JSON RTE field is as follows:

 
{
  "children":[
    {
      "text":"Embedded asset:",
      "bold":true
    },
    {
      "uid":"v4_unique_id",
      "type":"reference",
      "attrs":{
        "asset-link":"asset_link",
        "asset-name":"asset_name",
        "asset-type":"image/jpg",
        "asset-uid":"uid_of_the_asset_you_want_to_embed",
        "class-name":"embedded-asset",
        "content-type-uid":"sys_assets",
        "display-type":"display",
        "inline":true,
        "type":"asset",
        "dirty":"true //Set to true if you update the entry",
        "else set to false"
      },
      "children":[
        {
          "text":""
        }
      ]
    },
    {
      "text":"continued text after embedding an asset",
      "bold":true
    }
  ],
  "type":"p",
  "uid":"v4_unique_id",
  "attrs":{
    "dirty":"true //Set to true if you update the entry",
    "else set to false"
  }
}

Note: When you update an existing JSON RTE, you need to pass the dirty attribute for each content block. Set the attribute to true.

The PUSH operation allows you to “push” (or append) data into an array without overriding an existing value.

For example, you have an entry with a Number field (named “Multiple Number”), marked as “Multiple” and with the data, “1,” “4,” “5,” and you need to add “2” and “3” to it. In this case, you need to use the PUSH operation as follows:

{
    "entry": {
        "multiple_number": {
            "PUSH": {
                "data": [
                    2,
                    3
                ]
            }
        }
    }
}

Say you need to push specific data (say “abc”) into a field named “Demo Field” which is within a “Group” field marked as “Multiple”. You need to use the “PUSH” operator as follows:

{
    "entry": {
        "multiple_group": {
            "PUSH": {
                "data": {
                    "demo_field": "abc"
                }
            }
        }
    }
}

PULL Operation

The PULL operation allows you to pull data from an array field based on a query passed.

For example, you have an entry with a “Number” field named “Multiple Number” which has the values, “1,” “2,” “3,” “4,” and “5”, and you need to remove “2” and “ 3”. You need to use the PULL operation as follows:

{
    "entry": {
        "multiple_number": {
            "PULL": {
                "query": {
                    "$in": [
                        2,
                        3
                    ]
                }
            }
        }
    }
}

Another example is if you need to pull specific field data from a field (say a “Group” field) marked as “Multiple,” where the field name is “Demo Field” and the specific value to be pulled is “abc”. You need to use the “PULL” operator as follows:

{
    "entry": {
        "multiple_group": {
            "PULL": {
                "query": {
                    "demo_field": {
                        "$in": ["abc"]
                    }
                }
            }
        }
    }
}

Note: Here are certain limitations to the PULL request:
1. Currently, a PULL operation on multiple fields will retrieve the result of only ONE field i.e., if you include multiple fields in your PULL request, you will be able to retrieve the data of only the first mentioned field.
2. PULL query does not work on Nested Group fields.

UPDATE Operation

The UPDATE operation allows you to update data at a specific index. This operation works for both singular fields and fields marked “Multiple”.

For example, you have an entry with a “Number” (named “Multiple Number”) field which has the values, “6,” “2,” “3,” “4,” and “5”, and you need to replace the number at the first index (a[0]) i.e., “6” with “1”. In this case, you need to use the UPDATE operation as follows:

{
    "entry": {
        "multiple_number": {
            "UPDATE": {
                "index": 0,
                "data": 1
            }
        }
    }
}

UPDATE Operation for Group Field

For example, consider a multi-group field - "banner" with 2 instances, and with titles “banner 1” and “banner 2”.  Using the update operation, to replace the title at the second instance (a[1]) i.e., “Banner 2” with “New update” and link title at the second index with "New level 2 update through CMA call". In this case, you need to use the UPDATE operation as follows:

{
    "entry": { 
        "group": {
            "UPDATE": {
                "index": 1,
                "data": {
                    "title": "New update",
                    "link": {
                        "UPDATE": {
                            "data": {
                                "title": "New level 2 update through CMA call"
                            }
                        }
                    }
                }
            }
        }
    }
}

Thus, using the UPDATE operation you can update a single/multi-level group field without sending the whole object array. 

UPDATE Operation for Nested Modular Blocks

For example, consider the following modular blocks nesting scenario:

Within "content_container" modular blocks, there is a "link_module" block. Within the link_module block, there are "link_components" modular blocks. Within the link_components modular blocks, there is a "link_component" block. In such nested modular blocks scenario, single line fields can be updated with the following Update operation:

{
    "entry": {
        "title": "example",
        "content_container": {
            "UPDATE": {
                "index": 1,
                "data": {
                    "link_module": {
                        "module_title": "test link module 2 Updated testing 2 new",
                        "link_components": {
                            "UPDATE": {
                                "index": 1,
                                "data": {
                                    "link_component": {
                                        "teaser": "updated Nested Module teaser using CMA call"
                                    }
                                }
                            }
                        }
                    }
                }
            }
        }
    }
}

Thus, using the UPDATE operation, you can update single/multi-level fields within the nested modular blocks without sending the whole object array.

Atomic Operators for Number Fields

Contentstack provides support for atomic operators that will specifically help you to work with “Number” fields. These atomic operators include ADD and SUB.

ADD Operation

The ADD operation reads the latest value of a “Number” field and increments it by a numeric passed along with the operator. The increment occurs irrespective of what the current value of the field is.

For example, you have a “Number” field and you want to increment the value of the field by one. In this case, you need to use the "ADD":1 operation. This operation reads the latest value of the field, increments it by 1, and replaces the existing value of the field with the new value.

SUB Operation

The SUB operation works the opposite of ADD. It reads the latest value of a “Number” field and decrements it by a numeric value passed along with the operator.

For example, you have a “Number” field and you want to decrease the value of the field by one. In this case, you need to use the "SUB":1 operation. This operation reads the latest value of the field, decrements it by 1, and replaces the existing value of the field with the new value.

The Delete an entry request allows you to delete a specific entry from a content type. This API request also allows you to delete single and/or multiple localized entries.

Note: In the Header, you need to use either the stack Management Token (recommended) or the user Authtoken, along with the stack API key, to make valid Content Management API requests. For more information, refer to Authentication.

This API Request supports the following actions as well:

• Delete specific localized entry: For this request, you need to only specify the locale code of the language in the locale query parameter. If the locale parameter is not been specified, by default, the master language entry will be deleted.
• Delete master language along with all its localized entries: For this request, instead of the locale query parameter, you need to pass the delete_all_localized:true query parameter.
  

  Note: The delete_all_localized parameter will work only if you are deleting localized versions from the master language.

• Delete multiple localized entry: Additionally, you can delete specific localized entries by passing the locale codes in the Request body using the locales key as follows:

  {
    "entry": {
      "locales": ["hi-in", "mr-in", "es"]
    }
  }

The Set Version Name for Entry request allows you to assign a name to a specific version of an entry.

In the request body, you need to specify the version name to be assigned and the locale of the entry.

Tip: You can add an additional parameter force:true to force update the version name of the master entry.

The Get Details of All Versions of an Entry request allows you to retrieve the details of all the versions of an entry.

The version details returned include the actual version number of the entry; the version name along with details such as the assigned version name, the UID of the user who assigned the name, and the time when the version was assigned a name; and the locale of the entry.

Note: If an entry is unlocalized, the version details of entries published in the master locale will be returned.

The Delete Version Name of Entry request allows you to delete the name assigned to a specific version of an entry. This request resets the name of the entry version to the version number.

The Get references of an entry call returns all the entries of content types that are referenced by a particular entry.

The Get languages of an entry call returns the details of all the languages that an entry exists in.

The Localize an entry request allows you to localize an entry i.e., the entry will cease to fetch data from its fallback language and possess independent content specific to the selected locale.

In the "Body" parameter, you need to provide the content of your entry based on the content type.

Note: This request will only create the localized version of your entry and not publish it. To publish your localized entry, you need to use the Publish an entry request and pass the respective locale code in the locale={locale_code} parameter.

Refer the Localization docs for more information.

The Unlocalize an entry request is used to unlocalize an existing entry. Read more about Unlocalization.

The Export an entry call is used to export an entry. The exported entry data is saved in a downloadable JSON file.

The Import an entry call is used to import an entry. To import an entry, you need to upload a JSON file that has entry data in the format that fits the schema of the content type it is being imported to.

The Import an existing entry call will import a new version of an existing entry. You can create multiple versions of an entry.

The Publish an entry request lets you publish an entry either immediately or schedule it for a later date/time.

Note: When you publish an entry, the associated metadata of that entry will also get published. However, when publishing entries in bulk, the associated metadata of the entries will not get published.

In the 'Body' section, you can specify the locales and environments to which you want to publish the entry. When you pass locales in the "Body", the following actions take place:

• If you have not localized your entry in any of your stack locales, the Master Locale entry gets localized in those locales and are published
• If you have localized any or all of your entries in these locales, the existing localized content of those locales will NOT be published. However, if you need to publish them all, you need to perform a Bulk Publish operation.

The locale and environment details should be specified in the ‘entry’ parameter. However, if you do not specify any source locale(s), it will be published in the master locale automatically.

Along with the above details, you also need to mention the master locale and the version number of your entry that you want to publish.

In case of Scheduled Publishing, add the scheduled_at key and provide the date/time in the ISO format as its value. Example: "scheduled_at":"2016-10-07T12:34:36.000Z"

The Publish an Entry With References request allows you to publish an entry along with all its references at the same time.

Note: At a time, you can publish an entry in up to 50 languages and on 10 environments.

In the “Body” section, you need to specify the following parameters:

• entries: Pass the details of the main entry i.e., its entry UID, content type UID, the locale code, and the version that you want to publish.
• locales: Pass the locale codes in which you want to publish your entry and its references. If you do not specify a source locale, the entries will be published in the master locale automatically.
• environments: Pass the UIDs of the environments to which you want to publish the entries.

Here are some additional parameters that you need to pass in the “Request Body”:

• "publish_with_reference": true: Pass this parameter to publish an entry along with its references.
  

  Note: Only one level of referenced entries will be published using this API Request.

• skip_workflow_stage_check: true: Pass this parameter to skip those entries that do not satisfy the workflow stage of their publishing rule(s) and publish the rest of them.
  

  Note: Specifically applicable for Workflow enabled organizations, when this parameter is set to “false” and if any one of the entries fails to satisfy the set conditions, NONE of the entries will be sent for publishing.

• approvals: true: Pass this parameter to publish only those entries that have been approved by the designated approver, and skip the rest that have not yet been approved.
  

  Note: Specifically applicable for Workflow enabled organizations, when this parameter is set to “false” and if any one of the entries is not approved by the Approver, NONE of the entries will be sent for publishing.

Note: In the Header, you need to use either the stack Management Token (recommended) or the user Authtoken, along with the stack API key, to make valid Content Management API requests. For more information, refer to Authentication.

The Unpublish an entry call will unpublish an entry at once, and also, gives you the provision to unpublish an entry automatically at a later date/time.

In the 'Body' section, you can specify the locales and environments from which you want to unpublish the entry. These details should be specified in the ‘entry’ parameter. However, if you do not specify a locale, it will be unpublished from the master locale automatically.

You also need to mention the master locale and the version number of your entry that you want to publish.

In case of Scheduled Unpublishing, add the scheduled_at key and provide the date/time in the ISO format as its value. Example: "scheduled_at":"2016-10-07T12:34:36.000Z"

The Get all assets request returns comprehensive information on all assets available in a stack.

Additionally, if you wish to fetch the metadata attached to each asset, then you need to pass include_metadata as a query parameter. Set this parameter to true to include the asset metadata along with all assets in the response body.

You will find the asset metadata under the _metadata key in the response. It will be associated with a specific extension UID as follows:

    "_metadata":{
    "extensions":{
       "{extension_uid}":[
            {
                "image_copyrights": "Contentstack Branding",
                "scope”: “local”
            }
        ]
    }
}

You can add queries to extend the functionality of this API call. Under the URI Parameters section, insert a parameter named query and provide a query in JSON format as the value.

To learn more about the queries, refer to the Queries section of the Content Delivery API doc.

Tip: To include the publish details in the response, make use of the include_publish_details parameter and set its value to ‘true’. This query will return the publish details of the entry in every environment along with the version number that is published in each of the environment. When you publish an asset, the associated metadata of that asset will also get published.

The Get an asset request returns comprehensive information about a specific version of an asset of a stack.

Additionally, if you wish to fetch the metadata attached to each asset, then you need to pass include_metadata as a query parameter. Set this parameter to true to include the asset metadata along with all assets in the response body.

You will find the asset metadata under the _metadata key in the response. It will be associated with a specific extension UID as follows:

   
 "_metadata":{
    "extensions":{
       "{extension_uid}":[
            {
                "image_copyrights": "Contentstack Branding",
                "scope”: “local”
            }
        ]
    }
}

Tip: To include the publish details in the response, make use of the include_publish_details parameter and set its value to ‘true’. This query will return the publish details of the entry in every environment along with the version number that is published in each of the environment. When you publish an asset, the associated metadata of that asset will also get published. However, when publishing assets in bulk, the associated metadata of the assets will not get published.

The Get assets of a specific folder retrieves all assets of a specific asset folder; however, it doesn't retrieve the details of subfolders within it.

The Get assets and folders of a parent folder retrieves details of both assets and asset subfolders within a specific parent asset folder.

The Upload asset request uploads an asset file to your stack.

To upload assets from your local system to Contentstack and manage their details, you need to use the following "form-data" parameters:

You can try the call manually in any REST API client, such as Postman. Here's a screenshot for reference:

For easier access, here's the cURL for this API Request:

curl -X POST \
  https://api.contentstack.io/v3/assets?include_dimension=true \
  -H 'api_key: {api_key_of_your_stack}' \
  -H 'authtoken: {your_authtoken}' \
  -H 'cache-control: no-cache' \
  -H 'content-type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW' \
  -F 'asset[upload]=@{Filepath e.g., /C:/Users/abc/Desktop/Sample.png}' \
  -F 'asset[parent_uid]={If you need to add this file under an existing asset folder, pass the UID of the parent folder.}' \
  -F 'asset[title]={If needed, enter a title for your uploaded asset.}' \
  -F 'asset[description]={If needed, enter a description for your uploaded asset.}'
  -F 'asset[tags]={If needed, assign a specific tag to your uploaded asset.}'

In the above cURL command, pass the necessary values within the curly brackets. The asset[parent_uid], asset[title], asset[description], asset[tags], and include_dimension=true parameters are optional. You can skip them if not required.

The Replace asset call will replace an existing asset with another file on the stack.

Tip: You can try the call manually in any REST API client, such as Postman.
Under 'Body', pass a body parameter named asset[upload] and select the input type as 'File'. This will enable you to select the file that you wish to import.
You can assign a parent folder to your asset by using the asset[parent_uid] parameter, where you can pass the UID of the parent folder.
Additionally, you can pass optional parameters such as asset[title] and asset[description] which let you enter a title and a description for the uploaded asset, respectively.

The Generate Permanent Asset URL request allows you to generate a permanent URL for an asset. This URL remains constant irrespective of any subsequent updates to the asset.

Warning: You can generate the permanent asset URL and update the asset details only once. Once done, you can no longer make changes to the permanent URL.

In the request body, you need to pass the permanent URL in the following format:

{
    "asset": {
        "permanent_url": "https://images.contentstack.io/v3...{stack_api_key}/{asset_uid}/{unique_identifier}"
         
    }
}

In the above URL, you can pass any unique identifier (slug) that suits your requirement.

Another way to generate a permanent URL for an asset is to pass the URL as a form-data parameter, i.e., asset[permanent_url]. You can provide the permanent URL of your choice (along with a slug) as a value for this parameter, for example:

https://{base_URL}/v3/assets/{stack_api_key}/{asset_uid}/{slug}

The Download an asset with permanent URL request displays an asset in the response. The asset returned in the response can be saved to your local storage system. Make sure to specify the unique identifier (slug) in the request URL.

This request will return the most recent version of the asset, however, to download the latest published version of the asset, pass the environment query parameter with the environment name.

Note: Before executing this API request, ensure to create a permanent URL for the asset you want to download.

The Delete asset call will delete an existing asset from the stack.

The Get information on RTE assets call returns comprehensive information on all assets uploaded through the Rich Text Editor field.

The Set Version Name for Asset request allows you to assign a name to a specific version of an asset.

In the request body, you need to specify the version name to be assigned to the asset version.

The Get Details of All Versions of an Asset request allows you to retrieve the details of all the versions of an asset.

The details returned include the actual version number of the asset; the version name along with details such as the assigned version name, the UID of the user who assigned the name, and the time when the verison was assigned a name; and the count of the versions.

The Delete Version Name of Asset request allows you to delete the name assigned to a specific version of an asset. This request resets the name of the asset version to the version number.

The Get asset references request returns the details of the entries and the content types in which the specified asset is referenced.

The Get either only images or videos request retrieves assets that are either image or video files, based on query request.

You can add queries to extend the functionality of this API call. Under the URI Parameters section, insert a parameter named query and provide a query in JSON format as the value.

To learn more about the queries, refer to the Queries section of the Content Delivery API doc.

The Update asset revision call upgrades a specified version of an asset as the latest version of that asset.

Under 'Body', you need to specify the asset version number that you want to make the latest in raw JSON format, and also provide a "Title" and a "Description" for the asset. Another way to provide a "Title" and a "Description" for the asset is to pass them as optional form-data parameters, i.e., asset[title] and asset[description].

Here's an example of the raw body:

{
    "asset": {
        "title": "Title",
        "description": "Description"
    },
    "version": 3
}

The Update asset request allows you to update the title and description of an asset.

Note: Here are some points to keep in mind:
1. You can also use this request to generate a permanent URL for your asset, which remains constant irrespective of any further updates to the asset.
2. This call updates only the meta data of an asset. To replace an asset, try the Replace asset request under Asset Collection.

Under 'Body', you need to pass the updated details of "Title" and "Description" is in the form of 'raw' body as follows:

{
   "asset":{
      "title":"new title",
       "description":"updated description"
     }
}

Another way to provide a "Title" and a "Description" for the asset is to pass them as optional form-data parameters, i.e., asset[title] and asset[description]. You can assign a parent folder to your asset by using the asset[parent_uid] parameter, where you need to pass the UID of the parent folder.

The Publish an asset call is used to publish a specific version of an asset on the desired environment either immediately or at a later date/time.

Note: When you publish an asset, the associated metadata of that asset will also get published. However, when publishing assets in bulk, the associated metadata of the assets will not get published.

In case of Scheduled Publishing, add the scheduled_at key and provide the date/time in the ISO format as its value. Example: "scheduled_at":"2016-10-07T12:34:36.000Z"

In the 'Body' section, enter the asset details, such as locales and environments, where the assets need to be published. These details should be in JSON format.

The Unpublish an asset call is used to unpublish a specific version of an asset from a desired environment.

In case of Scheduled Unpublishing, add the scheduled_at key and provide the date/time in the ISO format as its value. Example: "scheduled_at":"2016-10-07T12:34:36.000Z"

In the 'Body' section, enter the asset details, such as locales and environments, from where the assets need to be unpublished. These details should be in JSON format.

The Get a single folder call gets the comprehensive details of a specific asset folder by means of folder UID.

When executing the API call to search for a subfolder, you need to provide the parent folder UID.

The Get a single folder by name call retrieves a specific asset folder based on the name provided.

The Get subfolders of a parent folder request retrieves the details of only the subfolders of a specific asset folder. This request does not retrieve asset files.

The Create a folder call is used to create an asset folder and/or add a parent folder to it (if required).

In the ‘Body’ section, you need to provide a name for the new folder.

If you want to place this folder within another folder, provide the UID of the parent folder in the Request body as follows:

{
    "asset": {
        "name": "asset_folder_name",
        "parent_uid": "asset_parent_folder_uid"
    }
}

Note: Here are some points that needs to be considered when executing this API request:

• A maximum of 300 folders can be created.
• The maximum level of folder nesting is 5.
• When nesting folder, you cannot nest a folder within the same folder or within its child folders.

The Update or move folder request can be used either to update the details of a folder or set the parent folder if you want to move a folder under another folder.

When executing the API request, provide the UID of the folder that you want to move/update.

In the ‘Body’ section, you need to provide a new name for your folder, and if you want to move your folder within another folder, then you need provide the UID of the parent folder.

Note: Here are some points that needs to be considered when executing this API request:

• A maximum of 300 folders can be created.
• The maximum level of folder nesting is 5.
• When nesting folder, you cannot nest a folder within the same folder or within its child folders.

The Delete a folder call is used to delete an asset folder along with all the assets within that folder.

When executing the API call, provide the parent folder UID.

The Create a content type with embedded RTE objects request lets you create a content type, which supports embedded objects inside its RTE field.

Note: For Authentication, use either the stack’s Management Token or the user Authtoken (any one is mandatory), along with the stack API key to make a valid Content Management API request.

In the “Body” section, you need to provide the complete schema of the content type (refer JSON schema for creating a content type).

To embed entries within a specific RTE, pass the reference_to parameter with valid content type UIDs to determine entries of which content type(s) can be embedded inside the editor.

Note: The max number of content types that can be referenced within a single Rich Text Editor field is 10.

To embed assets within a specific RTE, you can pass "sysassets" value within the reference_to array along with the content type UIDs.

Here’s a sample schema of a Rich Text Editor field that supports embedded entries and assets:

{
    "data_type":"text",
    "display_name":"Sample RTE",
    "uid":"sample_rich_text_editor",
    "field_metadata":{
        "..."
    },
    "reference_to":[
        "content_type_UID_1",
        "content_type_UID_1",
        "sys_assets"
    ],
    "..."
}

Additional Resource: Refer to the Rich Text Field Schema guide to understand how you can format the content entered in the field.

The Update content type with embedded RTE objects request allows you to update the schema of an existing content type that contains embedded entries and/or assets within its Rich Text Editor field.

Note: Whenever you update a content type, it will auto-increment the content type version.

When executing the API request, in the “URI Parameters” section, provide the unique ID of your content type.

In the “Body” section, you need to provide the updated schema of your content type. You can refer the JSON schema for creating a content type document to know how you can add/update fields in your content type through API.

Note: You need to use either the stack’s Management Token or the user Authtoken (any one is mandatory), along with the stack API key, to make a valid Content Management API request. Read more about authentication.

You can make changes to the schema of the Rich Text Editor field while updating the content type schema. Here is a sample of an updated Rich Text Editor schema:

{
    "data_type":"text",
    "display_name":"Updated RTE",
    "uid":"updated_rich_text_editor",
    "field_metadata":{
        "allow_rich_text":true,
        "description":"",
        "multiline":false,
        "rich_text_type":"advanced"
    },
    "reference_to":[
        "content_type_UID_1",
        "content_type_UID_2",
        "sys_assets"
    ],
    "mandatory":false,
    "unique":false,
    "non_localizable":false
}

The Create an entry with embedded RTE entries request allows you to embed entries inside the Rich Text Editor field while creating a new entry for the selected content type.

Note: Within a single Rich Text Editor field, you can embed a maximum of 100 components, entries and assets combined.

When executing the API request, in the 'Body' section, you need to provide the content of your entry based on the fields present within the content type created.

If your entry contains a Rich Text Editor field, you can embed entry/entries of the same or other content types inside the field as HTML components. These embedded entries can be added inline within the flow of content; as a separate content block; or as a dynamic hyperlink within the rich text.

Note: Only the Rich Text Editor fields of type Custom and Advanced support embedded objects. You cannot embed entries and/or assets inside a Basic editor.

Since we refer to an embedded entry as a separate HTML element, you need to wrap the entry component inside the <div> HTML tag. To refer to the entry of your choice and define what embedded style you prefer, specify the following attributes:

• class: To specify a class name for the HTML element (embedded entry)
• data-sys-entry-uid: To specify the unique ID of the entry that you want to embed inside the editor
• data-sys-entry-locale: To specify the locale code for the language in which the selected entry is localized
• data-sys-content-type-uid: To specify the unique ID of the content type to which the embedded entry belongs
• sys-style-type: You can pass inline, block, or link to specify how you want to embed the entry within the text
• type: To specify the type of object embedded inside the rich text, e.g., entry

Here’s a sample of rich text that contains embedded entries:

"rich_text_editor": "<p>Embedded entry as block:</p><div class=\"embedded-entry\" data-sys-entry-uid=\"bltb6ea3a0ab9699748\" data-sys-entry-locale=\"en-us\" data-sys-content-type-uid=\"sample_content_type\" sys-style-type=\"block\" type=\"entry\"></div><p>Embedded entry inline with text:</p><div class=\"embedded-entry\" data-sys-entry-uid=\"bltc2bcca1a99a89261\" data-sys-entry-locale=\"en-us\" data-sys-content-type-uid=\"sample_content_type\" sys-style-type=\"inline\" type=\"entry\"></div><p>Embedded entry as link:</p><a class='embedded-entry' data-sys-entry-uid='blt36e18c7c05db737b' data-sys-entry-locale='en-us' data-sys-content-type-uid='sample_content_type' sys-style-type='link' type='entry'></a>"

The above Rich Text Editor contains entries embedded as a separate content block; within the flow of text; and as a hyperlink to another Contentstack entry.

Note: Contentstack’s SDKs help consume the response returned when you create an entry containing embedded objects. You can then decide what content (fields of the embedded entry, for instance) should be rendered on the frontend.

The Create an entry with embedded RTE assets request allows you to embed assets inside the Rich Text Editor field while creating a new entry for the selected content type.

Note: Within a single Rich Text Editor field, you can embed a maximum of 100 components, entries and assets combined.

When executing the API request, in the 'Body' section, you need to provide the content of your entry based on the content type created.

If your entry contains a Rich Text Editor field, you can embed assets inside the Rich Textas downloadable or display images within the rich text.

Note: Only the Rich Text Editor fields of type Custom and Advanced support embedded objects. You cannot embed entries and/or assets inside a Basic editor.

Since we refer to an embedded asset as a separate HTML element, you need to wrap the asset component inside the <div> HTML tag. To refer to the asset of your choice and define what embedded style you prefer, specify the following attributes:

• class: To specify a class name for the HTML element (embedded asset)
• data-sys-asset-uid: To specify the unique ID of the asset that you want to embed inside the editor
• sys-style-type: You can pass display or download to specify whether the embedded asset should be downloadable or act as a display image
• type: To specify the type of object embedded inside the rich text, e.g., asset

Tip: An embedded asset works exactly like the Reference field. When you update the details of an embedded asset or replace the source asset with another asset, the Rich Text Editor automatically updates the embedded HTML component with the latest version of that asset.

Here’s a sample of rich text that contains embedded assets:

"rich_text_editor": "<p>Embedded asset as display image:</p><img class=\"embedded-asset\" data-sys-asset-uid=\"blt8d49bb742bcf2c83\" type=\"asset\" sys-style-type=\"display\"></img><p>Embedded asset as downloadable image:</p><img class=\"embedded-asset\" data-sys-asset-uid=\"bltb47f1aa5ae422cd1\" type=\"asset\" sys-style-type=\"download\"></img>"

Note: Contentstack’s SDKs help consume the response returned when you create an entry containing embedded objects. You can then render the embedded assets on the frontend whenever required.

The Update embedded RTE objects request lets you update the embedded entries or assets placed inside the Rich Text Editor field of an entry.

In the 'Body' section, provide the updated Rich Text Editor information in JSON format.

Tip: You can either replace the embedded asset with another or change the style (downloadable or displayable) in which the asset has been embedded inside the editor.

Here’s a sample of updated Rich Text Editor content:

"rich_text_editor": "<p>Updated embedded asset to downloadable image:</p><img class=\"embedded-asset\" data-sys-asset-uid=\"blt120a5a04d91c9466\" type=\"asset\" sys-style-type=\"download\"></img><p>Updated embedded entry inline with text:</p><div class=\"embedded-entry\" data-sys-entry-uid=\"bltb6ea3a0ab9699748\" data-sys-entry-locale=\"en-us\" data-sys-content-type-uid=\"sample_content_type\" sys-style-type=\"inline\" type=\"entry\"></div>"

The Get information on embedded RTE objects request returns comprehensive information on all entries and/or assets embedded within the Rich Text Editor field.

If your entry contains a Rich Text Editor field and you wish to fetch the content schema of the items embedded inside the rich text, then you need to pass the include_embedded_items[]=BASE query parameter.

You can view information about the embedded objects under the _embedded_items parameter in the JSON response body.

Note: Contentstack’s Content Delivery SDKs help consume the embedded entries and assets returned in the API response. You can then render the embedded objects on the frontend however required.

The Publish entries and assets in bulk request allows you to publish multiple entries and assets at the same time.

Note: At a time, you can publish 10 entries in 10 languages and on 10 environments.

In the 'Body' section, you need to specify the locales (mention the locale codes) and environments (mention the names) to which you want to publish the entries or assets. If you do not specify a source locale, the entries or assets will be published in the master locale automatically.

Tip: To schedule the publishing of multiple entries and/or assets, you can make use of the ‘Create a Release’ request. Then, you can deploy this Release and all of the pinned items can be published together either immediately or at a scheduled time to whatever environment you choose.

Within the ‘entries’ parameter, pass these details of each entry – content type UIDs, entry UIDs, locales in which the entries are present, and the version that you want to publish. Within the ‘assets’ parameter, pass these details of each entry – asset UIDs and the version that you want to publish (optional).

If some of the entries added to the bulk publish request do not satisfy the applied publish rules, then all the items will not be published. To publish at least the items that satisfy the publish rules, pass additional query parameters, skip_workflow_stage_check=true and approvals=true.

Let's understand how these two query parameters work while publishing entries.

When you use skip_workflow_stage_check=true as a query parameter, the entries that satisfy the publish rules are sent for publishing, while those entries that have not yet reached the workflow stage defined for the set publish rules will not be sent for publishing. However, if you set this parameter to false and some of the entries included in the bulk publish request have not yet reached the workflow stage defined for the set publish rules, then all the entries selected will not be sent for publishing.

When you use approvals=true as a query parameter, the entries that satisfy the publish rules are sent for publishing, while those entries that have not yet received authorization from the approver assigned to them will not be sent for publishing. However, if you set this parameter to false and some of the entries included in the bulk publish request have not yet received authorization from the approver assigned to them, then all the entries selected will not be sent for publishing.

Note: You need to use either the stack’s Management Token or the user Authtoken (any one is mandatory), along with the stack API key, to make a valid Content Management API request. Read more about authentication.

The Unpublish entries and assets in bulk request allows you to unpublish multiple entries and assets at the same time.

Note: At a time, you can unpublish 10 entries in 10 languages and on 10 environments.

In the 'Body' section, you need to specify the locales (mention the locale codes) and environments (mention the names) to which you want to unpublish the entries or assets. If you do not specify a source locale, the entries or assets will be unpublished in the master locale automatically.

Tip: To schedule the unpublishing of multiple entries and/or assets, you can make use of the ‘Create a Release’ request. Then, you can deploy this Release and all of the pinned items can be unpublished together either immediately or at a scheduled time to whatever environment you choose.

Within the ‘entries’ parameter, pass these details of each entry – content type UIDs, entry UIDs, locales in which the entries are present, and the version that you want to unpublish. Within the ‘assets’ parameter, pass these details of each entry – asset UIDs and the version that you want to unpublish (optional).

If some of the entries added to the bulk unpublish request do not satisfy the applied publish rules, then all the items will not be unpublished. To unpublish at least the items that satisfy the publish rules, pass additional query parameters, skip_workflow_stage_check=true and approvals=true.

Let's understand how these two query parameters work while unpublishing entries.

When you use skip_workflow_stage_check=true as a query parameter, the entries that satisfy the publish rules are sent for unpublishing, while those entries that have not yet reached the workflow stage defined for the set publish rules will not be sent for unpublishing. However, if you set this parameter to false and some of the entries included in the bulk unpublish request have not yet reached the workflow stage defined for the set publish rules, then all the entries selected will not be sent for unpublishing.

When you use approvals=true as a query parameter, the entries that satisfy the publish rules are sent for unpublishing, while those entries that have not yet received authorization from the approver assigned to them will not be sent for unpublishing. However, if you set this parameter to false and some of the entries included in the bulk unpublish request have not yet received authorization from the approver assigned to them, then all the entries selected will not be sent for unpublishing.

Note: You need to use either the stack’s Management Token or the user Authtoken (any one is mandatory), along with the stack API key, to make a valid Content Management API request. Read more about authentication.

The Delete entries and assets in bulk request allows you to delete multiple entries and assets at the same time.

Note: At a time, you can delete 10 entries in a bulk delete request.

In the 'Body' section, you need to specify the content type UIDs, entry UIDs or asset UIDs, and locales of which the entries or assets you want to delete.

Note: You need to use either the stack’s Management Token or the user Authtoken (any one is mandatory), along with the stack API key, to make a valid Content Management API request. Read more about authentication.

The Update workflow details in bulk request allows you to update the workflow details for multiple entries at the same time.

Note: You can change the workflow stage of multiple entries only if all the entries have been assigned the same workflow stage and are associated with the same workflow.

In the 'Body' section, you need to provide the details of the workflow stage. Enter a comment for the assigned user, if needed; provide the due date; set notification settings to ‘true’, so that the specified user will be notified of it; enter the UID of the workflow stage; and finally, enter the user details, such as UID, name, and email address of the user.

Note: At a time, you can update the workflow details for 10 entries in a bulk update workflow details request.

Within the ‘entries’ parameter, pass these details of each entry – content type UIDs, entry UIDs, and locales in which the entries are present.

Note: You need to use either the stack’s Management Token or the user Authtoken (any one is mandatory), along with the stack API key, to make a valid Content Management API request. Read more about authentication.

The Get all custom fields request is used to get the information of all custom fields created in a stack.

The Get a single custom field request gets the comprehensive details of a specific custom field.

The Upload a custom field request is used to upload a custom field to Contentstack.

In the ‘Body’ section, you need to provide the following ‘Body’ parameters under ‘form-data’:

• extension[upload]: Select the HTML file of the custom field that you want to upload
• extension[title]: Enter the title of the custom field that you want to upload
• extension[data_type]: Enter the data type for the input field of the custom field
• extension[tags]: Enter the tags that you want to assign to the custom field
• extension[multiple]: Enter ‘true’ if you want your custom field to store multiple values
• extension[type]: Enter type as ‘field’, since this is a custom field extension.

Tip: You can try the call manually in any REST API client, such as Postman. Under 'Body', for the extension[upload] parameter, select the input type as 'File'. This will enable you to select the file that you wish to import.

The Create a custom field with source URL call is used to create a custom field that is hosted externally.

In the ‘Body’ section, you need to provide details of the custom field, such as its tags, data type, title, external source link, set if the field is to take multiple values or not, and configuration details.

Note: The custom field has various data types you can select from – Text, Number, Date, Boolean, JSON, Reference, File, and Asset.

The Create a custom field with source code request is used to create a custom field in Contentstack by providing the source code of the extensions. This source code will be hosted on Contentstack.

In the ‘Body’ section, you need to provide details of the custom field, such as its tags, data type, title, source code of the extension, set if the field is to take multiple values or not, and configuration details.

Note: The custom field has various data types you can select from – Text, Number, Date, Boolean, JSON, Reference, File, and Asset.

The Update a custom field request is used to update the details of a custom field.

In the ‘Body’ section, you need to provide details of the custom field, such as its tags, data type, title, external source link (or the updated external source code), set if the field is to take multiple values or not, and configuration details.

The Delete custom field request is used to delete a specific custom field.

The Create Content Type with Extension Field request is used to create a content type that includes a custom field.

The Get widgets request is used to get the information of all custom widgets created in a stack.

The Get widgets of a content type request gets the comprehensive details of all widgets that are assigned to a specific content type.

The Upload a widget request is used to upload a new custom widget to a stack.

In the ‘Body’ section, you need to provide the following ‘Body’ parameters under ‘form-data’:

• extension[upload]: Select the HTML file of the widget that you want to upload
• extension[title]: Enter the title of the widget that you want to upload
• extension[tags]: Enter the tags that you want to assign to the widget
• extension[scope]: Enter either {"content_types":["$all"]} or {"content_types":["content_type_uid1”, “content_type_uid2”, “..."]} to apply this widget to all content types or specific content types, respectively
• extension[type]: Enter type as ‘widget’, since this is a custom widget extension

Tip: You can try the call manually in any REST API client, such as Postman. Under 'Body', for the extension[upload] parameter, select the input type as 'File'. This will enable you to select the file that you wish to import.

The Create Widget with source URL call is used to create a widget that is hosted externally.

In the ‘Body’ section, you need to provide details of the widget, such as its tags, title, external source link (src), configuration details, set if the extension is a widget or field, and specify the scope, i.e., the content types to which you want to apply the widget.

The Create widget with source code request is used to create a widget in Contentstack by providing the source code. This source code will be hosted on Contentstack.

In the ‘Body’ section, you need to provide details of the widget, such as its tags, title, source code of the widget, configuration details, set if the extension is a widget or field, and specify the scope i.e., the content types that you want to apply the widget.

The Update a widget request is used to update the details of a widget.

In the ‘Body’ section, you need to provide details of the widget, such as its tags, title, external source link (or the updated external source code), configuration details, set if the extension is a widget or field, and specify the scope i.e., the content types that you want to apply the widget.

The Delete a widget call is used to delete a specific custom widget.

The Get All Dashboard Widgets request is used to get the information of all the enabled custom dashboard extension.

The Upload Dashboard Widget request uploads the widget to the Stack Dashboard.

In the ‘Body’ section, you need to provide the following ‘Body’ parameters under ‘form-data’:

• extension[upload]: Select the HTML file of the widget that you want to upload.
• extension[title]: Enter the title of the widget that you want to upload.
• extension[tags]: Enter the tags that you want to assign to the widget.
• extension[type]: Enter type as ‘dashboard’, since this is a custom widget extension.

The Create a Dashboard Widget with Source URL request is used to upload an extension hosted externally.

In the ‘Body’ section, you need to provide details of the dashboard widget, such as its tags, title, external source link (src), configuration details, and set if the extension is a widget or field.

The Create dashboard widget with source code request is used to create a widget in Contentstack by providing the source code. This source code will be hosted on Contentstack.

In the ‘Body’ section, you need to provide details of the widget, such as its tags, title, source code of the widget, configuration details, and set if the extension is a widget or field.

The Update dashboard widget request is used to update the details of an widget.

In the ‘Body’ section, you need to provide details of the extension, such as its tags, data type, title, and configuration details.

The ‘Delete a dashboard widget’ call is used to delete a specific custom dashboard.

The Get all JSON RTE plugins request is used to get the information of all JSON Rich Text Editor plugins created in a stack.

The Get a single JSON RTE plugin request gets the comprehensive details of a specific JSON Rich Text Editor plugin.

The Create a JSON RTE plugin with source URL request allows you to add an externally hosted JSON RTE plugin to your stack.

In the ‘Body’ section, you need to provide details of the JSON RTE plugin, such as its tags, title, external source link, set if the field is to take multiple values or not, configuration details, and the extension type. Enter the extension type as ‘rte_plugin’, since this is a JSON RTE plugin extension.

Note: You can add a maximum of 50 extensions (including custom fields , custom widgets and JSON RTE plugins) in a stack.

The Update a JSON RTE plugin request allows you to update the details of an existing JSON RTE plugin.

In the ‘Body’ section, you need to provide details of the JSON RTE plugin, such as its tags, title, external source link (or the updated external source code), set if the field is to take multiple values or not, configuration details, and the extension type.

The Delete JSON RTE plugin request allows you to delete a specific JSON RTE plugin.

The Create content type with JSON RTE plugin request allows you to create a content type that includes JSON RTE plugins within the JSON Rich Text Editor.

In the “Body” section, you need to provide the UIDs of the JSON RTE plugins you want to add within the plugins parameter.

The schema for this is as follows:

"plugins":[
          "bag98lo5467qs532l0c",
          "ang22qw1234pl345g8j",
          "pnr65op1258hs807k9l"
        ]

Note: The maximum number of JSON RTE plugins that can be added to a single JSON RTE field in a content type is five.

The Get all asset sidebar extensions request is used to get the information of all the asset sidebar extensions created in a stack.

The Get a single asset sidebar extension request gets the comprehensive details of a specific asset sidebar extension.

The Create an asset sidebar extension with source URL request allows you to add an externally hosted asset sidebar extension to your stack.

In the ‘Body’ section, you need to provide details of the asset sidebar extension, such as the extension type, title, configuration details, external source link, width, and blur effect. Enter the extension type as asset_sidebar_widget, since this is an asset sidebar extension.

The popup panel width should be within the range of 335 to 1024 pixels. Set the blur effect to true if you want to blur the details of the uploaded file by default.

Note: You can add a maximum of 50 extensions (including custom fields , custom widgets, JSON RTE plugins, and asset sidebar extensions) in a stack.

The Update an asset sidebar extension request allows you to update the details of an existing asset sidebar extension.

In the ‘Body’ section, you need to provide details of the asset sidebar extension, such as the extension type, title, configuration details, external source link (or the updated external source code), width, and blur effect.

The popup panel width should be within the range of 335 to 1024 pixels. Set the blur effect to true if you want to blur the details of the uploaded file by default.

The Delete asset sidebar extension request allows you to delete a specific asset sidebar extension.

The Get metadata request fetches the metadata attached to a specific asset or entry of a stack.

In the URL, you need to pass the unique ID of the metadata against the metadata_uid parameter.

Keep the following points in mind when getting metadata:

• To retrieve metadata for a specific entry or asset, you need to have read access to that entry or asset.
• You must pass the include_publish_details query parameter to fetch the metadata publishing details in the response.

The Create metadata request lets you create metadata for a specific asset or entry. Whenever you create metadata for an entry or asset, you need to specify the extension to which it will be connected.

In the ‘Body’ section, you need to provide the following information:

• entity_uid: Specify the unique ID of the entry or asset for which you want to create metadata.
• type: Specify whether you want to create metadata for an entry or asset.

  Note: The default type is an asset if not mentioned.

• _content_type_uid: Specify the content type UID if you are creating metadata for an entry.

  Note: For an asset type, the content type UID will be "sys_assets".

• extension_uid: Specify the UID of the extension for which you want to create the metadata.
• locale: Specify the language in which the entry is localized if the type is an entry.
• metadata key: Specify the additional metadata that you want to attach to an existing asset/entry under a key name that suits your need.

  Note: The maximum size of the metadata allowed per extension is 5 KB (includes metadata defined for all entries and assets connected to a specific extension).

Note: You can provide any key name to store the metadata for your entry or asset except the following prebuilt keys: created_by, updated_by, created_at, updated_at, deleted_at, api_key, scope, locale, type, extension_uid, _version.

The Update metadata request lets you update the metadata for a specific entry or asset.

In the ‘Body’ section, you need to provide the metadata key, that specifies the additional metadata that you want to attach to an existing asset/entry under a key name that suits your need.

Note: The maximum size of the metadata allowed per extension is 5 KB (includes metadata defined for all entries and assets connected to a specific extension).

You can partially update metadata for a defined key without having to specify all the key details every time you update metadata.

Keep the following points in mind when updating metadata:

• To create/update metadata for a specific entry or asset, you need update access to that entry or asset.
• If you update entry or asset metadata once, then you cannot recover the previous version of the metadata.

Note: You can provide any key name to store the metadata for your entry or asset except the following prebuilt keys: created_by, updated_by, created_at, updated_at, deleted_at, api_key, scope, locale, type, extension_uid, _version, publish_details.

The Delete metadata request lets you delete the metadata associated with a specific entry or asset.

In the URL, you need to pass the unique ID of the metadata that you want to delete against the metadata_uid parameter.

Keep the following points in mind when deleting metadata:

• To delete metadata for a specific entry or asset, you need delete access to that entry or asset.
• Once you delete entry or asset metadata, it is permanently deleted and cannot be restored.

The Publish metadata request lets you publish the metadata associated with a specific entry or asset.

In the URL, you need to pass the unique ID of the metadata that you want to publish against the metadata_uid parameter.

Keep the following points in mind when publishing metadata:

• When you publish an entry/asset, the associated metadata of that entry/asset will also get published. However, when publishing entries/assets in bulk, the associated metadata of the assets/entries will not get published.
• You must pass the include_publish_details query parameter to fetch the metadata publishing details in the response.

The Unpublish metadata request lets you unpublish the metadata associated with a specific entry or asset.

In the URL, you need to pass the unique ID of the metadata that you want to unpublish against the metadata_uid parameter.

This call fetches all the existing labels of the stack.

When executing the API call, under the 'Header' section, you need to enter the API key of your stack and the authtoken that you receive after logging into your account.

You can add queries to extend the functionality of this API call. Under the URI Parameters section, insert a parameter named query and provide a query in JSON format as the value.

To learn more about the queries, refer to the Queries section of the Content Delivery API doc.

The Get label call returns information about a particular label of a stack.

When executing the API call, under the 'Header' section, you need to enter the authtoken that you receive after logging into your account.

This call is used to create a label.

When executing the API call, under the 'Header' section, you need to enter the API key of your stack and the authtoken that you receive after logging into your account.

In the 'Body' section, enter the label details, such as the name of the label, the uid of the parent label, and the content types that need to be included in the label. These details need to be provided in JSON format.

The Update label call is used to update an existing label.

When executing the API call, under the 'Header' section, you need to enter the authtoken that you receive after logging into your account.

In the 'Body' section, enter the updated details of your label, which include the name of the label, the uid of the parent label, and the content types that need to be included in the label. These details need to be provided in JSON format.

The Delete label call is used to delete a specific label.

When executing the API call, under the 'Header' section, you need to enter the authtoken that you receive after logging into your account.

The Get all Releases request retrieves a list of all Releases of a stack along with details of each Release.

The Get a single Release request gets the details of a specific Release in a stack.

When executing the API request, provide the Release UID as parameter.

The Create a Release request allows you to create a new Release in your stack. To add entries/assets to a Release, you need to provide the UIDs of the entries/assets in ‘items’ in the request body.

The Update a Release call allows you to update the details of a Release, i.e., the ‘name’ and ‘description’.

When executing this API request, provide the Release UID as parameter. In the 'Body' section, you need to provide the new name and description of the Release that you want to update.

The Delete a Release request allows you to delete a specific Release from a stack.

When executing the API request, provide the Release UID.

The Get all items in a Release request retrieves a list of all items (entries and assets) that are part of a specific Release.

When executing the API request, you need to provide the Release UID.

The Add a single item to a Release request allows you to add an item (entry or asset) to a Release.

When executing the API request, you need to provide the Release UID. In the 'Body' section, you need to provide the details of the item such as the UID, version (of the entry), content type UID (of an entry), the action to be performed (publish/unpublish), and the locale of the item.

The Add multiple items to a Release request allows you to add multiple items (entries and/or assets) to a Release.

When executing the API request, you need to provide the Release UID. In the 'Body' section, you need to provide the details of the items such as their UIDs, versions (in case of entries), content type UIDs (in case of entries), the action to be performed (publish/unpublish), and the locales of the items.

Note: In a single request, you can add maximum 25 items (entries/assets) to a Release.

The Update Release items to their latest versions request let you update all the release items (entries and assets) to their latest versions before deployment.

Note: You need to use either the stack's Management Token or the user Authtoken  (anyone is mandatory), along with the stack API key, to make a valid Content Management API request. Read more about authentication.

In the 'Body' section, you need to specify the following:

{
    "items":[
        "$all"
    ]
}

Note: This API request only allows you to collectively update all items in the release to their latest versions and not update any particular item individually.

In case an un-localized entry in the release has been localized later, this request will update the entry to the latest localized version. For example, if you add an un-localized entry to a release and later localize it to the French (France) language, this API request will update the release with the localized French version of the entry.

Note:  You cannot update the release items under the following scenarios:

If the updated version of an entry has new references, this API request doesn't automatically add the references to the release. You need to add them manually.

You cannot update the items in a release once you deploy it.

If the latest version of an entry is in the in-progress state, this API request doesn't update the entry.

The Remove an item from a Release request removes one or more items (entries and/or assets) from a specific Release.

When executing the API request, provide the Release UID. In the 'Body' section, you need to provide the details of the item such as their UIDs, version (of the entry), content type UID (of an entry), the action to be performed (publish/unpublish), and the locale of the item.

The Delete multiple items from a Release request deletes one or more items (entries and/or assets) from a specific Release.

When executing the API request, provide the Release UID. In the 'Body' section, you need to provide the UIDs of the items along with details such as their locale, versions, the action to be performed on the items (publish/unpublish), and content type UID of entries (if any).

The Deploy a Release request deploys a specific Release to specific environment(s) and locale(s).

When executing the API request, provide the Release UID. In the 'Body' section, you need to provide the details of the Release that you want to deploy. For example, you need to provide the action, environment(s), and the locale(s) on which the Release should be deployed.

The Clone a Release request allows you to clone (make a copy of) a specific Release in a stack.

When executing the API request, provide the Release UID. In the 'Body' section, you need to provide the new name and description of the cloned Release.

The Get all Workflows request retrieves the details of all the Workflows of a stack.

The Get a Single Workflow request retrieves the comprehensive details of a specific Workflow of a stack.

The Create a Workflow request allows you to create a Workflow.

In the 'Body' section, you can provide the details of the workflow that includes name, content types, owners, description, and workflow stages of your Workflow. To define the branch scope, specify the unique IDs of the branches for which the workflow will be applicable in the following schema in the request body:

"branches":[
    "main",
    "development"
]

To control who can edit an entry at different stages of the workflow, you can pass the entry_lock parameter inside each workflow stage.

Note: Workflow superusers, organization owners, and stack owners/admins can edit or delete the entry in any workflow stage, irrespective of the stage access rules set for that stage.

You can assign any one of the following values to this parameter:

• $none: This is the default value for all workflow stages. This value allows all users to have edit access over the entry at any workflow stage until the value for the entry_lock parameter is changed.
• $others: Set the entry_lock parameter to $others to allow only those users who have stage transition rights to edit the entry in the current workflow stage.
• $all: Set the entry_lock parameter to $all to restrict all users from accessing the entry.
  

  Note: Users with stage transition rights, however, will still be able to change the workflow stage of the entry.

Note: The entry is available for editing, by default, in the first stage that you create in your workflow. As a result, the entry_lock parameter is set to $none for the first stage in the workflow.

The Add or Update Workflow request allows you to add a workflow stage or update the details of the existing stages of a workflow.

In the 'Body' section, you can provide the updated details of the name, content types, owners, description, and workflow stages of your Workflow. To define the branch scope, specify the unique IDs of the branches for which the workflow will be applicable in the following schema in the request body:

"branches":[
    "main",
    "development"
]

To control who can edit an entry at different stages of the workflow, you can pass the entry_lock parameter inside each workflow stage.

Note: Workflow superusers, organization owners, and stack owners/admins can edit or delete the entry in any workflow stage, irrespective of the stage access rules set for that stage.

You can assign any one of the following values to this parameter:

• $none: This is the default value for all workflow stages. This value allows all users to have edit access over the entry at any workflow stage until the value for the entry_lock parameter is changed.
• $others: Set the entry_lock parameter to $others to allow only those users who have stage transition rights to edit the entry in the current workflow stage.
• $all: Set the entry_lock parameter to $all to restrict all users from accessing the entry.
  

  Note: Users with stage transition rights, however, will still be able to change the workflow stage of the entry.

Note: The entry is available for editing, by default, in the first stage that you create in your workflow. As a result, the entry_lock parameter is set to $none for the first stage in the workflow.

The Disable Workflow request allows you to disable a workflow.

The Enable Workflow request allows you to enable a workflow.

The Delete Workflow request allows you to delete a workflow.

The Set Entry Workflow Stage request allows you to either set a particular workflow stage of an entry or update the workflow stage details of an entry.

In the 'Body' section, you need to provide the details of the workflow stage. Enter a comment for the assigned user, if needed; provide the due date; set notification settings to ‘true’, so that the specified user will be notified of it; enter the UID of the workflow stage; and finally, enter the user details, such as UID, name, and email address of the user.

Note: To set or update the workflow stage details of an entry, you need to pass the Authtoken in the header. This API request does not support the use of the Management Token.

The Create Publish Rules request allows you to create publish rules for the workflow of a stack.

To define the branch scope, specify the unique IDs of the branches for which the publishing rule will be applicable in the following schema in the request body:

"branches":[
    "main",
    "development"
]

Note: You cannot create publish rules in a stack that supports branches when using the classic Contentstack interface.

The Add or Update Publish Rules request allows you to add a publish rule or update the details of the existing publish rules of a workflow.

To define the branch scope, specify the unique IDs of the branches for which the publishing rule will be applicable in the following schema in the request body:

"branches":[
    "main",
    "development"
]

The Delete Publish Rules request allows you to delete an existing publish rule. 

The Get all Publish Rules request retrieves the details of all the Publish rules of a workflow. 

The Get a Single Publish Rule request retrieves the comprehensive details of a specific publish rule of a Workflow.

The Get Publish Rules by Content Types request allows you to retrieve details of a Publish Rule applied to a specific content type of your stack.

When executing the API request, in the 'Header' section, you need to provide the API Key of your stack and the authtoken that you receive after logging into your account.

This multipurpose request allows you to either send a publish request or accept/reject a received publish request.

When executing the API request, in the 'Header' section, you need to provide the API Key of your stack and the authtoken that you receive after logging into your account.

In the 'Body' section, you need to provide the details of the publish rule, such as its UID, action (‘publish’, ‘unpublish’, or ’both’), status (this could be ‘0’ for Approval Requested, ‘1’ for ‘Approval Accepted’, and ‘-1’ for ‘Approval Rejected’), notification setting, and comment for the approver.

The Get all Tasks request retrieves a list of all tasks assigned to you.

When executing the API request, in the 'Header' section, you need to provide the API Key of your stack and the authtoken that you receive after logging into your account.

This call fetches the list of all languages (along with the language codes) available for a stack.

When executing the API call, under the 'Header' section, you need to enter the authtoken that you receive after logging into your account.

You can add queries to extend the functionality of this API call. Under the URI Parameters section, insert a parameter named query and provide a query in JSON format as the value.

To learn more about the queries, refer to the Queries section of the Content Delivery API doc.

This call lets you add a new language to your stack. You can either add a supported language or a custom language of your choice.

When executing the API call, under the 'Header' section, you need to enter the API key of your stack and the authtoken that you receive after logging into your account.

In the 'Body' section, enter the language name and code in JSON format. You can also specify the fallback language you want to assign to the new language within the same JSON.

Warning: Once generated, you cannot modify a custom language code. However, you can update the language name and fallback language if required.

The Get a language call returns information about a specific language available on the stack.

When executing the API call, under the 'Header' section, you need to enter the authtoken that you receive after logging into your account.

The Update language call will let you update the details (such as display name) and the fallback language of an existing language of your stack.

When executing the API call, under the 'Header' section, you need to enter the authtoken that you receive after logging into your account.

In the 'Body' section, enter the updated details of your language name and fallback language in JSON format.

The Delete language call deletes an existing language from your stack.

When executing the API call, under the 'Header' section, you need to enter the API key of your stack and the authtoken that you receive after logging into your account.

The ‘Set a fallback language’ request allows you to assign a fallback language for an entry in a particular language.

When executing the API call, under the 'Header' section, you need to enter the API key of your stack and the authtoken that you receive after logging in to your account.

In the 'Body' section, enter the language codes in JSON format.

Note: The language set as a fallback language will always inherit data from the master language if it does not have localized content.

The ‘Update fallback language’ request allows you to update the fallback language for an existing language of your stack.

When executing the API call, under the 'Header' section, you need to enter the API key of your stack and the authtoken that you receive after logging in to your account.

In the 'Body' section, enter the updated details of the fallback language in JSON format.

Note: The language set as a fallback language will always inherit data from the master language if it does not have localized content.

The Get all environments call fetches the list of all environments available in a stack.

You can add queries to extend the functionality of this API call. Under the URI Parameters section, insert a parameter named query and provide a query in JSON format as the value.

To learn more about the queries, refer to the Queries section of the Content Delivery API doc.

The Get a single environment call returns more details about the specified environment of a stack.

When executing the API call, under the 'Header' section, you need to enter the authtoken that you receive after logging into your account.

The Add an environment call will add a publishing environment for a stack.

When executing the API call, under the 'Header' section, you need to enter the API key of your stack and the authtoken that you receive after logging into your account.

In the 'Body' section, mention the environment name, the urls (which include the language code and the URL of the server).

The Update environment call will update the details of an existing publishing environment for a stack.

When executing the API call, under the 'Header' section, you need to enter the API key of your stack and the authtoken that you receive after logging into your account.

In the 'Body' section, enter the updated details of the environment. You can modify the environment name, the urls (which include the language code and the URL of the server).

The Delete environment call will delete an existing publishing environment from your stack.

When executing the API call, under the 'Header' section, you need to enter the API key of your stack and the authtoken that you receive after logging into your account.

The Get all delivery tokens request returns the details of all the delivery tokens created in a stack.

The Get a single delivery token request returns the details of all the delivery tokens created in a stack.

The Create delivery token request is used to create a delivery token in the stack.

In the Request Body, you need to pass the details of the delivery token in JSON format. The details include the name, description, and the environment of the delivery token.

Note: It is highly recommended to set only one publishing environment per delivery token.

You need to specify the branch and alias scope for your delivery token through the following schema in the request body:

{
    "module":"branch",
    "branches":[
        "main",
        "development"
    ],
    "acl":{
        "read":true
    }
},
{
    "module":"branch_alias",
    "branch_aliases":[
        "deploy",
        "release"
    ],
    "acl":{
        "read":true
    }
}

The Update delivery token request lets you update the details of a delivery token.

In the Request Body, you need to pass the updated details of the delivery token in JSON format. The details include the updated name, description, and/or the environment of the delivery token.

You need to specify the branch and alias scope for your delivery token through the following schema in the request body:

{
    "module":"branch",
    "branches":[
        "main",
        "development"
    ],
    "acl":{
        "read":true
    }
},
{
    "module":"branch_alias",
    "branch_aliases":[
        "deploy",
        "release"
    ],
    "acl":{
        "read":true
    }
}

The Delete delivery token request deletes a specific delivery token.

The Get all management tokens request returns the details of all the management tokens generated in a stack and NOT the actual management tokens.

The Get a single management token request returns the details of a specific management token generated in a stack and NOT the actual management token.

The Create management token request is used to create a management token in a stack. This token provides you with read-write access to the content of your stack.

Note: A management token can only be generated by the owner or admin of a stack.

In the Request Body, you need to pass the details of the management token in JSON format. The details include the name, description, the stack-level permissions you need to assign to the token, and the expiry date of the token in UTC time (if required). Additionally, you can also choose to get notified (via email) seven days before the token expires.

You need to specify the branch and alias scope for your management token through the following schema in the request body:

{
    "module":"branch",
    "branches":[
        "main",
        "development"
    ],
    "acl":{
        "read":true
    }
},
{
    "module":"branch_alias",
    "branch_aliases":[
        "deploy",
        "release"
    ],
    "acl":{
        "read":true
    }
}

Note: You can generate a maximum of 10 management tokens for a specific stack within your organization.

The Update management token request lets you update the details of a management token. You can change the name and description of the token; update the stack-level permissions assigned to the token; and change the expiry date of the token (if set).

In the Request Body, you need to pass the updated details of the management token in JSON format.

To specify the updated branch and alias scope for your management token, use the following schema in the request body:

{
    "module":"branch",
    "branches":[
        "main",
        "development"
    ],
    "acl":{
        "read":true
    }
},
{
    "module":"branch_alias",
    "branch_aliases":[
        "deploy",
        "release"
    ],
    "acl":{
        "read":true
    }
}

The Delete management token request deletes a specific management token.

The ‘Get all roles’ request returns comprehensive information about all roles created in a stack.

You can add queries to extend the functionality of this API request. Under the URI Parameters section, insert a parameter named query and provide a query in JSON format as the value.

To learn more about the queries, refer to the Queries section of the Content Delivery API doc.

The Get a single role request returns comprehensive information on a specific role.

The Create a role request creates a new role in a stack.

In the 'Body' section, mention the role name, description, users, additional roles, rules (includes the actions that can be performed on entries, fields, and/or assets), and permissions (which include the details of the content types, environments, and languages that are accessible).

Note: You can also restrict access to the master language entry while defining permissions for a new role. Refer to our Manage Language Permissions documentation for more details.

To add customized exceptions for all or specific languages, add an additional locale module in the request body. Under this module, pass the following parameters:

• locales: Specify the unique IDs of the languages for which you want to add exception rules
• sub_acl: Add this under acl. Here, specify the permissions you want to restrict for the languages specified in the above parameter, e.g., "create":true
• restrict: true: Set this parameter to true to enable exception rules for the specified languages

Here’s what your request body should look like:

{
    "module":"locale",
    "locales":[
        "blt008a444c98ab47e8"
    ],
    "acl":{
        "read":true,
        "sub_acl":{
            "read":false,
            "create":false,
            "update":true,
            "delete":false
        }
    },
    "restrict":true
}

Note: Language-related exceptions can be added only for custom roles and the developer and content manager system roles.

When creating a user role, you need to specify the branch and alias scope through the following schema in the request body:

{
    "module":"branch",
    "branches":[
        "main"
    ],
    "acl":{
        "read":true
    }
},
{
    "module":"branch_alias",
    "branch_aliases":[
        "deploy"
    ],
    "acl":{
        "read":true
    }
}

The Update role request lets you modify an existing role of your stack. However, the pre-existing system roles cannot be modified.

In the 'Body' section, include the updated details of the role which include name, description, users, additional roles, rules (includes the actions that can be performed on entries, fields, and/or assets), and permissions (which include the details of the content types, environments, and languages that are accessible).

Note: You can also restrict access to the master language entry while defining permissions for a new role.

To add customized exceptions for all or specific languages, add an additional locale module in the request body. Under this module, pass the following parameters:

• locales: Specify the unique IDs of the languages for which you want to add exception rules
• sub_acl: Add this under acl. Here, specify the permissions you want to restrict for the languages specified in the above parameter, e.g., "create":true
• restrict: true: Set this parameter to true to enable exception rules for the specified languages

Here’s what your request body should look like:

{
    "module":"locale",
    "locales":[
        "blt008a444c98ab47e8"
    ],
    "acl":{
        "read":true,
        "sub_acl":{
            "read":false,
            "create":false,
            "update":true,
            "delete":false
        }
    },
    "restrict":true
}

Note: Language-related exceptions can be added only for custom roles and the developer and content manager system roles.

When updating a user role, you need to specify the branch and alias scope through the following schema in the request body:

{
    "module":"branch",
    "branches":[
        "main"
    ],
    "acl":{
        "read":true
    }
},
{
    "module":"branch_alias",
    "branch_aliases":[
        "deploy"
    ],
    "acl":{
        "read":true
    }
}

The Delete role call deletes an existing role from your stack.

The Get all Webhooks request returns comprehensive information on all the available webhooks in the specified stack.

Tip: Execute this call when you wish to retrieve the UID of a webhook.

When executing the API call, under the 'Header' section, you need to enter the authtoken that you receive after logging into your account.

The Get webhook request returns comprehensive information on a specific webhook.

When executing the API call, under the 'Header' section, you need to enter the authtoken that you receive after logging into your account.

The Create a webhook request allows you to create a new webhook in a specific stack.

In the “Body” section, you need to enter the name of the webhook; the destination details i.e., target urls, basic authentication details, and custom headers; and the channels; and set the disabled and concise_payload parameters as per requirement.

Note: You can also set trigger conditions based on actions performed on entry comments and discussions. Refer to our Comments and Discussions webhook documentation to learn more about the trackable events.

The disabled parameter allows you to enable or disable the webhook. You can set its value to either false to enable the webhook and true to disable the webhook.

The concise_payload parameter allows you to send a concise JSON payload to the target URL when a specific event occurs. To send a comprehensive JSON payload, you can set its value to false. However, to send a concise payload, set the value of the concise_payload parameter to true.

When creating a webhook, you need to specify the branch scope through the following schema in the request body:

"branches":[
    "main"
]

Note: In the Header, you need to use either the stack Management Token (recommended) or the user Authtoken, along with the stack API key, to make valid Content Management API requests. For more information, refer to Authentication.

The Update webhook request allows you to update the details of an existing webhook in the stack.

In the “Body” section, you need to enter new details such as the name of the webhook; the destination details i.e., target urls, basic authentication details, and custom headers; and the channels; or reset the disabled or concise_payload parameters as per requirement.

The disabled parameter allows you to enable or disable the webhook. You can set its value to either false to enable the webhook and true to disable the webhook.

The concise_payload parameter allows you to send a concise JSON payload to the target URL when a specific event occurs. To send a comprehensive JSON payload, you can set its value to false. However, to send a concise payload, set the value of the concise_payload parameter to true.

When updating a webhook, you need to specify the branch scope through the following schema in the request body:

"branches":[
    "main"
]

Note: In the Header, you need to use either the stack Management Token (recommended) or the user Authtoken, along with the stack API key, to make valid Content Management API requests. For more information, refer to Authentication.

The Delete webhook call deletes an existing webhook from a stack.

When executing the API call, under the 'Header' section, you need to enter the API key of your stack and the authtoken that you receive after logging into your account.

The Export a Webhook request exports an existing webhook. The exported webhook data is saved in a downloadable JSON file.

The Import Webhook request imports a webhook. To import a webhook, you need to upload a JSON file with the webhook data.

The Import an Existing Webhook request will allow you to update the details of an existing webhook.

The Get executions of a webhook request allows you to fetch the execution details of a specific webhook, which includes the execution UID. These details are instrumental in retrieving webhook logs and retrying a failed webhook.

Each execution of a webhook is assigned a unique ID that allows you to gather information, such as request-response body, retry attempts, and so on, pertaining to a specific execution of the webhook.

To filter the webhook execution details based on a specific date range, you must pass from and to as query parameters. For both of these parameters, provide a date in ISO format as the value. For instance, to set the start date in the from parameter to December 8, 2017, you can pass the date in ISO format as shown below:

from="2017-12-08T00:00:00.000Z"

To filter the webhook execution details based on whether the webhook successfully ran or failed to execute, pass the query parameter under the URI Parameters section, and provide a query in JSON format as its value. Within the query, you can use the status key to filter the response as per your desired execution status.

The following table shows values you can use for the query parameter:

{
  "status": {
    "$gte": "200",
    "$lte": "399"
  }
}

{
  "status": {
    "$gte": “400",
    "$lte": “599"
  }
}

This API request will return a maximum of 100 records while fetching the execution details for a specific webhook. Previously, there was no limit on the number of records returned. You can use the "skip" parameter to fetch older records. To limit the number of records returned, you can use the “limit” parameter.

This call makes a manual attempt to execute a webhook after the webhook has finished executing its automatic attempts.

When executing the API call, in the 'URI Parameter' section, enter the execution UID that you receive when you execute the 'Get executions of webhooks' call.

This call will return a comprehensive detail of all the webhooks that were executed at a particular execution cycle.

When executing the API call, in the 'URI Parameter' section, enter the execution UID that you receive when you execute the 'Get executions of webhooks' call.

The Get audit log request is used to retrieve the audit log of a stack.

You can apply queries to filter the results. Refer to the Queries section for more details.

The Get audit log item request is used to retrieve a specific item from the audit log of a stack.

The Get publish queue request returns comprehensive information on activities such as publish, unpublish, and delete that have performed on entries and/or assets. This request also includes the details of the release deployments in the response body.

Note: You can retrieve the publish queue details for activities performed on entries and/or assets of your stack in the last 30 days.

You can apply queries to filter the results. Refer to the Queries section for more details.

Note: In the Header, you need to pass either the stack’s Management Token (highly recommended) or the user Authtoken, along with the stack API key, to make valid Content Management API requests. For more information, refer to Authentication.

The Get publish queue activity request returns comprehensive information on a specific publish, unpublish, or delete action that was performed on an entry and/or asset. You can also retrieve details of a specific release deployment.

Note: You can retrieve the publish queue details for activities performed in the last 30 days only.

You can apply queries to filter the results. Refer to the Queries section for more details.

Note: In the Header, you need to pass either the stack’s Management Token (highly recommended) or the user Authtoken, along with the stack API key, to make valid Content Management API requests. For more information, refer to Authentication.

The Cancel Scheduled Action request will allow you to cancel any scheduled publishing or unpublishing activity of entries and/or assets and also cancel the deployment of releases.