Use the API to migrate your existing content into your Kentico Kontent project, or update content in unpublished content items. The API cannot be used on published content unless you create new versions of the content items first, either in UI or through the Management API.

When retrieving and updating content via the Management API, you always work with the latest versions of content – the same as you would see in the Kentico Kontent user interface. Learn how to import content via the API by taking the tutorial on Importing to Kentico Kontent.

The base URL for all requests is https://manage.kontent.ai/v1/projects/<YOUR_PROJECT_ID>.

All requests to the API must be made securely with HTTPS with TLS 1.2 and authenticated with a valid API key. Requests to the API are rate limited and uncached.

cURL
curl --request GET \
  --url https://manage.kontent.ai/v1/projects/<YOUR_PROJECT_ID>/items \
  --header 'Authorization: Bearer <YOUR_API_KEY>' \
  --header 'Content-type: application/json'

The Management API does not provide any content filtering options and is not optimized for content delivery. If you need to deliver larger amounts of content, filter it, and leverage content caching, we recommend using the Delivery API instead.

To work with the Management API, send your requests over HTTPS and authenticate using the Authorization header in the following format: Authorization: Bearer <YOUR_API_KEY>.

To get your API key for the Management API, go to Kentico Kontent > Project settings > API keys. The API key provides access to a single Kentico Kontent project. You will need different API keys for each of your projects.

We offer a .NET SDK to help you work with the API. However, no SDK is required to use the API.

The state of the Management API may change in the future, however, the majority won't be breaking changes. To help you create more robust scripts and integrations, we've prepared a list of general changes to the API that we don't consider breaking. We recommend you read through the list to ensure you don't rely on a state that might change in the future.

In general, the non-breaking changes include adding functionality or changes in order of the returned data. More specifically, the following are NOT breaking changes:

• General:
  • Add a new endpoint.
  • Change the API behavior to fix a bug in the service.
  • Change rate limitation.
  • Change error message text.
• Responses:
  • Add a new property to JSON objects.
  • Change the order of JSON object properties.
  • Add a new type of element for content types or snippets.
  • Add a new HTML element to rich text elements.
  • Add a new attribute to HTML element in rich text elements.
  • Add a new value to HTML element attribute in rich text elements.
  • Change the order of HTML element attributes in rich text elements.
  • Represent some characters as HTML entities.
  • Add a new response header.
  • Add a body to a request that contained none.
• Requests:
  • Add a new optional property to JSON objects.
  • Add a new optional attribute to HTML element in rich text elements.
  • Add a new value to the HTML element attribute in rich text elements.
  • Add a new optional request header.
  • Add a new optional query string parameter.
  • Add an optional body to request that contained none.

The Management API returns standard HTTP status codes to indicate success or failure of a request. In general, status codes in the 2xx range indicate a successful request, status codes in the 4xx range indicate errors caused by an incorrect input (for example, providing incorrect API key), and status codes in the 5xx range indicate an error on our side.

For troubleshooting failed requests, the API provides error messages defined in a consumable format to help you identify and fix the issue.

If you cannot identify and resolve an issue with your API call, you can contact us with the response status and the request ID you get in the error response.

By default, the API keys for the Management API are valid for 4,000 days. The scope of the API keys is per project per user. This means you need a separate API key for each of your projects.

The API key inherits the identity of the user who generated it. Operations performed with the key will show in your version history as changes made by the specific user.

If you regenerate the API key before its expiration date, the system will revoke the previous API key after a short while. For requests made with a revoked API key, you'll receive the 403 Unauthorized error response.

JSON
{
    "request_id": "800000c0-0001-fc00-b63f-84710c7967bb",
    "error_code": 7,
    "message": "The provided API key was revoked. You can find a valid API key for this project in the Kentico Kontent app."
}

Rate limits specify the number of requests you or your application can make to the Management API within a specific time window. There are two separate time windows, second and minute, allowing a different number of requests each.

By default, the Management API enforces the following rate limits:

• 10 requests per second
• 400 requests per minute

These limits apply to each API key for the Management API.

When you reach the limit of a specific time window, the API will reject the request and respond with the 429 HTTP error.

JSON
{
    "request_id": "80000004-0002-fd00-b63f-84710c7967bb",
    "error_code": 10000,
    "message": "API rate limit exceeded. Please retry your request later."
}

The error response will include the Retry-After header that tells you how many seconds you need to wait before attempting further requests. Each failed request is perfectly safe to retry.

If you begin to receive 429 HTTP errors, reduce the frequency of your requests.

References identify objects within your project. For example, you can use references to specify content types, content items, languages, and more.

When specifying references to objects, the object can be identified by one of three properties:

1. Its internal ID, such as 18b43cc5-f4fd-0172-842b-3ae2c878cf6f
   • Generated by the system automatically.
   • Unique per object type such as content item, content type, and other.
   • Can be used to specify any object.
2. Its codename, such as object_codename
   • Initially generated from the object's display name.
   • Unique per object type such as content item, content type, and other.
   • Can be used to specify most objects.
3. Its external ID, such as custom-object-identifier
   • Specified manually when creating the object through the Management API. The external ID cannot be changed later.
   • Unique per object type and its subtype such as content type and its content elements, or multiple choice element and its options.
   • Can be used to specify user-created assets, content items, content types, content groups, elements, languages, taxonomy groups, and taxonomy terms.

Rules for codenames

When editing codenames, the new codenames must meet the following conditions:

• Only lowercase letters, numbers, and underscores are permitted.
• Codenames must start with a letter or an underscore and have at least one character.
• Codenames are usually limited to 60 characters, but longer codenames are allowed for multiple choice options and taxonomy terms.
• Codenames of elements within a snippet must be prefixed with the snippet's codename.
• Codenames must be unique per object type. This applies to, for example, every element within a content type, every content type within a project, every content item within a project, and so on.

This means the following applies when codenames are generated automatically:

• All letters are made lowercase.
• All forbidden characters are replaced by _.
• For any names that start with a number, the codename will start with n.
• Codenames that duplicate another codename will have a random string attached to the end.
• Codenames of elements within a snippet will be prefixed with the snippet's codename.
• Codenames will be cut off at the character limit.

The API uses internal IDs for referencing objects. This means that the reference objects in the API responses will always use internal IDs.

By using external IDs to reference other objects in your project, you can import your content in the order you prefer. For example, when importing multiple articles that contain images, you can reference these images with external IDs, such as roaster or coffee-cup, before uploading them. The referenced images will be visible in the UI only after you add them as assets via the Management API. With this approach, you can choose whether you want to create content items first and then upload binary files for assets, or vice versa.

This means you can use external IDs to reference objects that don't yet exist in the project and add the objects via the API later. References to non-existent objects will be stored and retrieved via the Management API as internal IDs.

To check whether your project contains any references to not-yet-created objects, see how to validate project content.

Missing objects in the UI

If you use external IDs to reference non-existent objects in your elements, the referenced objects won't be shown in the UI. This is because the system cannot find those objects. The referenced assets and content items will be displayed after you create them with their specific external IDs via the Management API.

To add the missing objects, see:

• Upsert a content item to create content items specified by external IDs.
• Upsert an asset to create assets specified by external IDs.

To manage content items via the Management API, you need to send requests to URIs based on the following patterns:

• Using internal IDs: <base_URL>/items/<content_item_id>
• Using codenames: <base_URL>/items/codename/<content_item_codename>
• Using external IDs: <base_URL>/items/external-id/<content_item_external_identifier>

To retrieve language variants of a specific content item, you can list the variants by specifying the internal ID, codename, or external ID of the content item.

The content item object contains metadata about your content, such as the name of the content item and when the item was last modified. The content item object does not store the content itself. The content for each language variant of a content item is saved in language variants, with each content item having as many variants as there are active languages in your project.