Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Umbraco Heartcore is a headless Software As A Service (SAAS) offered by Umbraco. The service enables you to create and manage content and media in the Umbraco backoffice and make it available to any platforms, devices, channels and so forth.
All Umbraco Heartcore projects include a Content Delivery Network (CDN) using CloudFlare. This CDN is used for caching content and media fetched through the Content Delivery API. Additionally, the media CDN (media.umbraco.io) allows for resizing and cropping options, which improves both performance and stability.
You can read more about all the features and benefits on the Umbraco Heartcore product page. You can also look at the pricing, plans, and features on the Umbraco Heartcore Pricing page.
There are 3 ways to get your hands on an Umbraco Heartcore project:
Setup a project directly from the Umbraco Cloud Portal - requires that you already have an account
In this section, you will find documentation on how to work with Umbraco Heartcore.
It includes REST API documentation, the basics of how to get started, and how to work with the available Client Libraries. Please note that Umbraco Heartcore is a specific type of project only available via Umbraco Cloud.
Reference documentation for the APIs available, as well as details about common HTTP headers, versioning, REST Standard, and how to work with authentication and authorization.
Reference documentation and tutorials for the GraphQL API.
Learn more about how we handle versioning and updates of Heartcore projects.
Do you have questions that are not covered by this documentation? Please create an issue on our Documentation Issue Tracker or get in touch with Umbraco Support using the chat in the portal or write a mail to support@umbraco.com.
Managing Umbraco Heartcore Users and API keys
In this article you will learn how to add Users to the backoffice and how to manage the API Keys.
A Backoffice user can be added in two ways.
Added from the portal from the Team Management section, or
From the Users Section in the Backoffice
A feature that is unique for Umbraco Heartcore is the option to create an API Key for specific users. The API Key can be created from the API Key section of the User page. This page can be found under the Users Section in the top-left navigation of the backoffice.
By default, the Content Delivery API is public, if you would like to protect it you can do so in the "Settings" section and "Headless" tree.
If your Content Delivery API is protected or you want to use Content Management APIs, your user will need to have an API Key assigned. When you have navigated to the Users section mentioned above you can create the API Key by clicking the "Create API Key" button.
A modal will pop up where you enter the name of the key and set a date for when it should expire. If there is no expire data, the API Key will be valid until you delete it manually.
Once the API Key has been created you will see the actual key and two examples on how to use the key with the Authorization header and an API-Key header.
You are able to see a list of all your created API Keys and all relevant information. You are also able to revoke a generated key.
With the built-in API browser that ships with all Umbraco Heartcore projects, you are able to test how your data is outputted and formatted before connecting to your website or application. You can test the API endpoints and see which JSON is outputted with each call.
This article will cover how to use the API Browser in order to reap all the benefits of the feature. The API Browser can be used for both the Content Delivery API and the Content Management API.
The API Browser is located in the Settings section of the Umbraco backoffice. Expand the Headless dashboard in the Settings tree, and select "API Browser".
Using the API Browser you can browse through the output for the various API endpoints. This is done from a UI, where on the left side you are able to explore the endpoints and on the right side you are able to inspect the output.
In the top-right corner you can switch between browsing in the Content Delivery or the Content Management API.
The first thing you'll notice on the API browser, is an already defined URL. This is to define which area of the API you will be browsing; https://cdn.umbraco.io
for the Content Delivery API and https://api.umbraco.io
for the Content Management API.
You can also use the this field to manually add query strings to the URL and search the API endpoints that way.
The URL will be updated automatically as you browse the API using the links in the bottom of the Explorer section.
In the Custom Request Headers you can define which headers to use when browsing the API endpoints. The umb-project-alias
header will have been added for you already, and in the content section the Accept-Language
is also set by default.
The Properties will show you all the available properties on the object / piece of data that you are calling through the API.
Below the properties, is a section with a list of Links. These are links that you can use to make various GET requests from the endpoint you are already using.
The final section in the explorer is the Embedded resources. Here you can see the properties for each embedded resource on the endpoint you are calling, as well as links to continue browser the API based on each of those resources.
In the right side, you'll find the inspector section. While exploring the API, you will see that information is being posted in the Response header and the Response Body boxes.
The first box, the Response Header, will show you the status of the API endpoint you are currently browsing and tell you which headers is included in the response.
In the Response Body box the raw JSON data will be output based on the API endpoint you're calling.
Documentation for Umbraco Heartcore GraphQL Playground.
With the GraphQL query language, you will be able to limit the amount of data transferred to and from your Heartcore instance and the client by specifying exactly what kind of information you would like to get in your API calls.
You can test and build GraphQL queries directly in the backoffice-integrated GraphQL Playground.
In the Settings section in the Umbraco Backoffice, you will find the Headless tree. From there you can use the GraphQL Playground to test your queries against your project's schema.
The Playground comes with basic features such as real-time error highlighting, syntax highlighting, formatting, query history and more.
Log into the project backoffice
Navigate to the Settings dashboard
Find the Headless tree near the bottom of the navigation list
Click on GraphQL
From there, you can start querying as soon as your content is published.
The GraphQL Playground's build-in documentation and schema browser can be found on the left toolbar
This button will open a panel that grants you a quick overview of how content is structured using the Document Types in your solution.
It also gives an idea of how to access specific properties on each Document Type, nested properties, and properties from compositions.
At the same time, it also explains relationships between specific objects and properties in your solution.
This will be updated automatically as you change the project's schema meaning Document Types, Data Types, Document Type Compositions, and Document Type Elements.
To run a query use the left side of the GraphQL Playground to type in your query - could be something as basic as getting the names of all your content pages:
The Heartcore GraphQL endpoint only supports queries - other operation types, that is mutations and subscriptions, are not supported.
After that, press the "Play" button sitting in the center of the Playground. If the query is constructed correctly, the results will be loaded into the right section.
When you are satisfied with the result, you can copy the client URL (CURL) by clicking the COPY CURL
button located in the top part of the Playground, next to the address bar.
GraphQL Playground supports requests with HTTP headers if an authorization token is needed. The HTTP HEADERS
section can be accessed from the bottom-right corner of the Playground window. By default, it contains the umb-project-alias
header, the alias of your Heartcore project. It is possible to add multiple headers.
It is also possible to define variables for queries - such variables's values can be changed in the bottom-left corner of the Playground window, next to the HTTP HEADERS
section.
If you happen to make an amazing query and afterward erase it by accident, you can re-use it by finding it in the History.
The History pane can be opened by clicking the history button in the toolbar to the left.
The Playground gives you an option to "prettify" your query with a click of a button, which makes it easier for humans to read.
Click the Create Persisted Query
button
Enter a name for the query in the new query editor that appears
Write your query in the editor
Click the Save
button
Find the query you want to update in the persisted queries list
Click on the name of the query
Make your changes in the editor that appears with the query
Click the Save
button
Find the query you want to delete in the persisted queries list
Click on the name of the query
Click the action menu in the top right corner of the editor with the query
Click the Delete
button
Confirm the deletion
In this article, you can learn more about how to work with environments on your Umbraco Heartcore project.
Having multiple environments means that you have a place to test both your content and the content structure before deploying it to the production environments, from where the content is served to your application.
An environment on a Heartcore project can be defined as a workspace and is at the same time a Git repository. When you have more than one environment on your project, these environments will act as branches of the main repository.
Umbraco Heartcore uses a deployment model that relies on Git and other core technology, which gives you the option to move both content and structure files from one environment to another.
Learn more about the deployment model in the.
How many environments you can work with depends on the your Umbraco Heartcore project is running.
When you upgrade your Heartcore project from the Starter to the Standard plan, it will be possible to add a Development environment. Once you've upgraded to the Professional plan, you will be able to add the Staging environment as well.
You can add and remove the environments any time you want, as long as you have multiple environments enabled.
Adding and removing environments is done from the Project page in the Cloud Portal.
Please note you will need to restart environments after they have been set up or removed from your project. This is to ensure that the Umbraco Deploy configuration is updated.
Below is a screenshot of how the project page looks on the standard plan with only the Live environment. There's an option to add a Development environment. How this page looks is dependent on the plan your project is using.
Umbraco Heartcore is a software as a service (SaaS) offering, that eliminates upgrade concerns. All maintenance related to the CMS, its features, and APIs is handled by Umbraco HQ.
Umbraco HQ will regularly be adding new features to the CMS and new capabilities to the REST APIs. Each time new endpoints are added to the REST API the api-version
will be updated to reflect the changes. API releases and versioning is handled following the .
We follow semver in terms of versioning, which means you can be sure that existing APIs will continue to work as expected without breaking. If a breaking change is required then the major version will be incremented, but the previous major version will continue to work.
For API calls, it's advisable to employ the api-version
header to indicate the API version you intend to use. If no version is specified the latest version of the API will be used.
Learn more about which versions of the API is available as well as what version each endpoint uses in the
When using our , the api-version
is handled as part of the library and generally not something you need to worry about.
Be aware that the client library releases will have certain features available. The Forms API is unavailable in the initial release (1.0) of the .NET Core client library, for instance. This was made available in the 1.1 version of the client library.
To learn more about querying, visit our .
The Graphql playground supports . To access Persisted queries you have to go to the and click the persisted queries tab
Tour of Umbraco Heartcore backoffice
In this article you will get an introduction to the different sections in the Umbraco Backoffice.
When you go to the backoffice of your Umbraco Heartcore project you will be asked to log in.
From here you are able to log in with the credentials used when the project was created.
The backoffice is divided into specific sections for example Content, Media and Settings. This will allow you to do work related to a specific section of your project.
The sections menu is located in the top-left corner of the screen.
Every section has a section tree that gives you an overview of the content you have in each section.
Folders and nested content can be expanded by clicking the arrow next to the node. This can also be done by double-clicking on the node.
Every item you have is considered a node. It could be a media item or content in the content section.
Every section in the Umbraco backoffice has one or more dashboard associated with them. The first thing you will see when accessing the backoffice on your Umbraco Heartcore project is the "Getting Started" dashboard. Here you can find links to news and resources useful to your project.
In this section you will find all the content you have on your page. Each item in the tree is called a Content Node. Every node is made up by different fields. Each field is defined by a property.
The content tree holds all the content nodes you have created.
The left holds the content tree that will automatically nest your content if you have created nodes with parent-child relationships.
On the left you can see what properties the highlighted Content Node has. In the above example there is a group called Main which holds a few properties. By clicking on the Info tap you will be able to see some useful information for the specific Content Node.
At the top you can see the automatically generated URL to the specific Content Node. Below you also get a handy history overview that shows who has done what at what time. Lastly you can see some general information such as Status, Creation Date and a direct link to the Document Type. You can edit it without leaving the current view.
Lastly you can either Save, Save and publish, Schedule a publication or unpublish the Content Node. You can change the action by clicking the small up arrow next in the green button in the lower right corner.
Media items are used to store images and videos in the Media section. These items can be referenced from your content. You are also able to create folders in the Media section to keep all your Media Items sorted.
A handy feature is that if you have a Media Picker in your Content Node and you upload an image. This image will automatically be added in the Media Section.
In the settings section you find the before mentioned Document Types, Data Types and Media Types among other settings that will be covered below.
Document Types defines the content nodes the editors can create in the Content section. A Document Type has a set of properties that is made up of specific Data Types like text or a numbers. A property is the fields that holds the content in a content node that can be edited by the content editor.
What differs from Document Types is that Media Types are specifically made for media items in the Media section.
When you have a website with a login you might want to create Member Types. Umbraco comes with a standard Member Type. You can extend of this, but you can also create your own type for more customized members.
Each Document Type property consists of a Data Type which defines what kind of input the property holds. Each Data Type references a Property Editor and can be configured in the Settings section of the Backoffice. A Property Editor can be anything from a basic number to something more complex like an image-cropper. It is possible to have multiple Data Types with different settings that still uses the same Property Editor.
In this section, you can establish two-way relationships for querying both parent-to-children and children-to-parent connections.
The log viewer is a view where you can browse all log entries for your project. You can filter on warnings, errors or critical Log Types to name a few.
In the Languages section you can manage your language variants. Depending on what plan you have chosen you will be able to setup multiple languages on your Heartcore project.
The headless dashboard has some information about your Heartcore project. Depending on what plan you are on, you will have access to more languages and user groups.
The dashboard shows you:
What plan you are on
How many available languages you have
How many user groups you have
In addition you are able to set the Content Delivery API to either Public or Private. If the API is private, you must have an assigned API key to fetch content from it.
From the Headless tree you can browse and explore the REST API endpoints as well as create and manage your Webhooks.
API Browser: In the API Browser you can test your API endpoints. Learn more about this in the API Browser article.
Webhooks: You can create and manage Webhooks for content actions. Learn more about how this is setup in the Webhooks article.
In this section you can manage all the users that are currently working on the project. Users are not to be confused with Members. Members are people who have a login to your website's frontend. Users can be developers, content creators, and so on, who have access to the backoffice.
You can segment your users into different User Groups. You can add Users to existing Groups or create your own custom User Groups. How many of these groups you can create depends on the plan your project is on.
For each user on your project you can generate a unique API key. This key will be used to access the Content Management API, and can be revoked at any time. Learn more about the API Keys in the Backoffice users and API keys article.
The Members section is where you manage your members who are able to log into your projects frontend. You can create Member Groups for management if you have multiple types of memberships.
In this section you can create and manage your Umbraco Forms.
In this article you can learn more about how to use the Forms API for retrieving form definitions and submitting form entries.
We recommend that you have a look at the along side this article if you haven't already seen it. The API reference has useful content around field types and possible errors.
Using the Forms API requires the use of a Bearer Token or an API-Key. A bearer token makes sense when working server side or in some kind of middleware whereas on the client side an API-Key might be a better fit. When using an API-Key on the client side we recommend that you create a "Forms-only" usergroup, so you do not expose any Content Management capabilities on the client side where not intentional.
The availability of Umbraco Forms depends on the plan. See the for an overview of which plans includes Forms.
In the Forms section of the Umbraco backoffice you will find the Forms Builder, which allows you to create forms by adding Fields, Placeholder texts, Validation and Conditions.
The purpose of this article is not to describe the Forms functionality itself, but to show how to use the APIs which are available for Umbraco Heartcore projects.
If you want to learn the basics of 'Creating a form' before going further we recommend that you start with the .
Before you continue with the rest of this article we recommend that you have at least one Form available that can be used for examples below. Here we will use a form with a Name field, an Email field and the Data Consent field, which is standard for all new Forms.
The API for Forms lives under the Content Management API, so a Bearer token or an API-Key is required to call all the Forms related endpoints.
For this example we will call https://api.umbraco.io/forms
which lists all available forms. From here you can find a specific form to retrieve in order to get the definition for that form. This is useful when you want to expose a specific form in a specific part of your presentation layer.
Getting a specific form is done by issuing a GET request to https://api.umbraco.io/forms/{id:guid}
Required headers include umb-project-alias
and Api-Key
or a Bearer Token via an Authorization header.
The JSON output for one specific form would look something like this:
Notice that the layout of properties correspond to the Forms builder in the backoffice. The various properties available for the form itself and for each of the fields is something you can use to build up the look and feel of the form in your presentation layer.
First step is to install it through NuGet:
When using the library you need the Content Management part in order to work with Forms. Create a new instance of the ContentManagementService
and pass in the name of your Umbraco Heartcore project and either username + password of a backoffice user or an API-Key. In the example below we use an API-Key when retrieving all available form definitions:
If you want to retrieve a specific form you can use the GetById
method along with a GUID ID as shown below:
First step is to install it through npm:
First we need to import and create a new instance of the Client
, to use the forms api you need to pass in the project alias and set an API-Key.
To retrieve all forms we need to use the forms service on the management API as shown below.
To retrieve a single form by ID you can use the byId
method with the form ID.
When a form is filled out we need to post the entered values to the entries
endpoint of the Forms API.
In order to submit the entered values you send a POST request to https://api.umbraco.io/forms/{id:guid}/entries
where the ID represents the specific form to post the entry to.
Required headers include umb-project-alias
and Api-Key
or a Bearer Token via an Authorization header. The payload is a key value object with the alias of the fields and the values entered in the form.
Below is an example of the payload body when sending an entry back to the form retrieved in the previous section.
Please keep in mind that the dataConsent
property is required to have the value on
or true
when present on a form - anything else will result in validation error.
If you added validation on the email field to ensure that the entered value is in fact a valid email address, then this validation will also be enforced through the API. Try to send the payload above with a value that is not a valid email address to see the validation response you get back.
Continuing on the previous .NET Core example we can also post entries to a form using the library.
Given that the form contains a Name, Email and Data Content field we can submit a form entry as follows:
Please note that if validation fails an exception is thrown. The validation configured for each of the fields is validated by Umbraco Forms on the server side.
Continuing on the previous NodeJS example we can also post entries to a form using the library.
Given that the form contains a Name, Email and Data Content field we can submit a form entry as follows:
Please note that if validation fails an error is thrown. The validation configured for each of the fields is validated by Umbraco Forms on the server side.
In this article, you will learn more about the Umbraco Cloud Portal and what options are available to you.
After you have logged into the , you are presented with the project list overview.
From here you can see a list of all your projects. If you have multiple projects, you can sort specific projects into groups.
Clicking on a project will take you to the project page where you will get an overview of your environment(s).
From here, you can create multiple environments, so that you can have a Development and eventually also a Staging environment. Depending on what plan you have chosen, you will have access to one or more environments on your project.
If you want to add an environment, all you have to do is click Create Development Environment. Umbraco will create the environment for you.
When you are done, you can go back to the project overview.
In the top-left corner, you will find the invite member option. This will allow you to quickly invite new team members to your project from a modal that pops up. This makes it very fast to invite new team members.
In the left side menu, you can find the different settings and configurations available for your Heartcore project.
As with the invite member option, you can add new team members to your project. It is also possible to change the roles of your team members here, provided that you have sufficient permissions. You can remove team members from this page as well as see any pending invitations you might have sent.
It is also here, that you are able to add or edit the Technical Contact information such as Name, Email, and telephone number.
When you invite a Team Member to your Heartcore project, they will automatically get access to the backoffice of the project as well.
You can add as many members to your project as you want.
Here you are able to set up a webhook that will gather all the information about each deployment. You can integrate webhooks with applications such as Slack. Doing so, you can get Heartcore to post a message in a chosen Slack channel after each deployment.
On the Usage page, you will find an overview that displays your usage and evaluates it against the plan limitations of your project. On the page, you will also find the top 10 for the bandwidth usage of your project. This can give you important insight into where you can optimize resource management.
Here you will be able to upgrade your trial to a plan that fits your needs.
Here you can rename your project. All default umbraco.io hostnames will be updated to match the new name. When renaming a project you will also need to update the Umb-Project-Alias
header when you are sending requests to the API, as changing the name of the project will also change the project alias.
From this page, you can delete your project. When deleting the project your subscription will automatically be cancelled as well. Deleting the project is a permanent action.
Umbraco Heartcore is subject to soft rate limits for requests to the delivery APIs. These limits are based upon the plan tier of the project, as follows:
Requests to the Content Management API are not limited.
Rate limits are individual for each of the GraphQL, Content Delivery, and Preview APIs. For example, a Standard Heartcore project may make up to 50 requests per second each of GraphQL and Content Delivery without being in violation.
When a request is made to the Content Delivery or GraphQL APIs, the result is cached. Subsequent requests to the same endpoint with the same parameters will return the cached result. Cached results expire after a variable period or after publishing relevant content. Requests served from the cache do not count toward the rate limit.
Rate limits to Heartcore APIs are currently soft limits. That is, whenever a given environment receives requests above the limit, it will continue to serve responses normally. Umbraco may contact the owner of projects that exceed their allowed rate limit.
In the future, Heartcore may change to hard enforcement of rate limits. In this eventuality, APIs will return an response with a Retry-After
header when receiving a request above the limit.
In this article you will get an overview of the Preview functionality in Umbraco Heartcore and how to use it with our.
The Preview API is always protected, this means it requires an API Key with Browse Node permission to be able to access it. If you don't already have an API Key ready, head over to to learn how to create one.
You will also need a client consuming the Content Delivery API. If you don't already have one you can use one of the samples included with the Client Libraries.
The Preview feature is currently only available on the .
To make it easier for your editors to access the preview version of you website, you can add a Preview button to content nodes in the backoffice.
This can be done by going to the Settings section, expanding the Headless item and clicking on Preview.
Here you'll get an overview of the preview urls created.
Right now the list is empty, so go ahead and click on Add Preview Url
This will open up a dialog on the right side of the backoffice, from where you can select which Root Content the preview url should be assigned to, and for which language it should be available for.
The Name field is used when there are multiple Preview Urls for a Content item.
Path Type controls how the path should be appended to the url, there are 3 different options.
Append path to url: this will append the path of the Content item to the end of url.
Path in querystring: this will add a querystring parameter to the url containing the path of the Content item.
Id in querystring: this will add a querystring parameter to the url containing the id of the Content item.
Default controls whether this url is the default one when clicking the Preview button.
After you click save you'll return to the overview where the configured urls is shown. From here, you can edit or delete them.
Now if you go back to the Content section and click on the node you selected as the Root node or one of its child items, you should now have a Preview button in the bottom right section of the screen.
If multiple urls have been added for the Content item, there will be an arrow next to the button. When clicked, it will show all the Preview Urls available.
Now that we have setup the backoffice, we need to update our site to use the Preview API.
The Preview API is always protected and requires an API Key to be passed with the request.
If you are using the GraphQL API a preview
argument can be passed to the root query fields.
To test that you get draft content back try changing the name of a Content item in the backoffice and click on Save, the change should now show up on your preview site but not on the live site.
A guide to building an Umbraco Heartcore project
In this article you can learn how to get started with your Umbraco Heartcore project.
It will cover everything you need to know, in order to create your first piece of content in the Umbraco backoffice.
This guide will assume that you have already set up an Umbraco Heartcore project without any content.
When you log in to the Umbraco Backoffice, the first thing you will see is the Content section. This is where you will be creating content for your Umbraco Heartcore project. However, it will not be possible to create any content yet, as we will first need to define the content we are going to be creating.
Content in Umbraco is based on Document Types which will define what type of data we can put into our content. A Document Type consists of a set of Properties - also called fields. A Property is made up of a Data Type which is a custom configuration of a Property Editor. Umbraco comes with a set of Property Editors, including a Text Area, a Date Picker, a picker for media items and many more.
As we go through this tutorial and start building the content for our Umbraco Heartcore project, you will learn more about each of these concepts and how they all work together.
New to Umbraco?
If you are new to Umbraco, we recommend that you take the Backoffice Tour we've created! You can find it by selecting the question mark in the top-right corner.
In this tutorial we will cover the following topic:
Creating a basic Document Type
Adding and defining properties
Creating a Document Type Collection
Setting permissions on Document Types
Creating content
Document Types are managed from the Settings section in the Umbraco backoffice.
In order to get started with our first Document Type, follow these steps:
Right-click on the Document Types folder and choose + Create....
Or select the three ellipses on the right, when hovering the folder.
Choose the first option: Document Type.
Give the new Document Type a name like Home Page.
Save the Document Type by selecting the green Save button in the bottom-right corner.
We have now created our first Document Type. It's currently a blank slate, and in the next section, we will start adding groups and properties. This way we are able to add different types of data to our content.
Before we can start adding properties to the Document Type, we need to add a Group.
Property Groups
Groups are a way to group certain properties together. It can help content editors getting an overview of content nodes with many properties.
Groups also serves as a way to navigate a content node in the Content section.
Select Add Group in the middle of the Document Type editor area.
Give the group a name like Content.
Now, let's add our first property to the Document Type.
Select Add Property.
In the Property Settings dialog, we'll start by giving the Property a name: Heading.
(Optional) Give the Property a description
Select Add Editor
Select Editor
In this dialog you choose which editor to add to the Property. The editor you choose defines the type of data that can be added to the property.
Create New lets you create your own Data Types based on the editors in Umbraco. Use existing provides you with the option to select on the pre-defined Data Types.
Use the search field to find and select the pre-defined Textstring Data Type.
Submit the Property settings
We have now added the first Property to our Document Type.
Following the same steps, let's add a few more properties to the Content group:
Media Picker
This editor lets you upload or select an existing media item from the Media section and add it to your content.
With these properties added our Document Type now looks something like this:
Remember to save the Document Type by selecting the green Save button in the bottom-right corner.
This is a very simplified version of a Document Type, and you are welcome to add more groups and properties.
So far, we've created a single Document Type with some text fields and a media picker. Before we start creating the actual content, we are going to add a few more Document Types, to allow for more variation in our Content section.
We will now expand on our site by adding a Document Type Collection.
Right-click on the Document Types folder and choose + Create....
Or select the three ellipses on the right, when hovering the folder.
Choose the second option: Document Type Collection....
Document Type Collections
When working with content you might want to be able to relate certain types of nodes to each other. This could be articles you would like to nest under a News section, or it could be a Blog where it should be possible to create blog posts.
The Document Type Collection allows you to create 2 Document Types in one go, and at the same time, they will be given a parent/child relationship.
Example: Parent Document Type: News Area Item Document Type: News Article
In the Content section, you will with this setup be able to create a News Area content node, and then create your News Articles under that node.
For our Umbraco Heartcore project, we will want it to be possible to create blog posts under a blog area.
Name the Parent Document Type Blog Area.
Name the Child Document Type Blog Post.
Select Create to setup the two Document Types.
Once the Document Types have been created you will be redirected to the Item Document Type - in our case the Blog Post.
Following the steps outlined earlier in this tutorial, add a Content group and the following properties to both the Blog Post and the Blog Area Document Types.
Blog Post
Blog Area
We should now have the three following Document Types in our Document Types tree:
The final thing we need to do before we start creating content is to check that our Document Types have the correct permissions.
Select the Home Page Document Type in the tree.
Navigate to the Permissions tab in the top-right corner.
We will want to allow that Home Page Document Type can be used to create content at root level, so make sure the Allow as root is checked.
Next to Allowed child node types select Add child, and in the dialog select our Blog Area Document Type.
Doing this, will allow us to create content of the Blog Area type under our Home Page.
Save the Document Type.
With the permissions set, we are now ready to start working on the content for the Umbraco Heartcore project.
In this next step of the tutorial, we will start creating content. The content we're going to create will be defined by the Document Types we've created, and you will see how the choices we've made impact the editing experience one we start working with the content.
Go to the Content section.
Right-click on the Content tree and choose + Create....
Or select the three ellipses on the right, when hovering the Content tree.
We now have the option to create a content item based on our Home Page Document Type.
Select the Home Page.
Give the content item a name: Welcome to Umbraco Heartcore.
Add some text to both the Heading and the Intro text properties.
To choose an image for the PromoImage property, select the plus-sign.
In the dialog, you can do either of the following the choose an image:
Select the Upload button to choose an image from your file explorer or
Drag an image directly into the dialog.
Once you've chosen an image, select it from the dialog and select the green Select button at the bottom of the dialog.
Media items and images
When you add media and images to your content using the default Media Picker Data Type, the items will automatically be added to the media library you can find in the Media section of the backoffice.
Select the Media section in the top navigation bar, and you can browse all the media items that have been uploaded to the project.
When you're happy with the content in the properties, select the Save and publish button in the bottom right.
So far, our Content section should look like this:
Right-click the root node, Welcome to Umbraco Heartcore, and choose Create...
Or select the three ellipses next to the node when hovering.
Select to create a Blog Area.
Give it a name: Blog.
(Optional) Add some text to the BlogDescription property.
To start adding blog posts to our Blog, right-click the Blog node in the Content tree.
Choose to Create... a new item based on the Blog Post Document Type.
Give the blog post a name and add some text to the Subtitle and MainContent properties.
Rich Text Editor
The editor we chose for the MainContent property is a Rich Text Editor.
It gives us a lot of flexibility when writing text, as there are multiple formatting options.
Once you're happy with how your blog post looks, select Save and publish.
To go back to the Blog Area, select the arrow next to the title of the blog post
You will now get an overview of the blog posts you've created. So far we've only created one, and creating more is done by selecting the Create Blog Post button in the top-left corner.
We have now covered the very basics of how to create content in the Umbraco backoffice.
Now you have some content in your Umbraco Heartcore project that you can start using.
You can use the Umbraco Heartcore REST API endpoints to fetch this content to where you need it.
In order to test how the content you've created will be formatted, when fetched through the Umbraco Heartcore REST API endpoints, you can use the API Browser in the Settings section of the backoffice.
If you are a C# developer and work with .NET you can use the in your own codebase to retrieve form definitions.
If you are a JavaScript developer and work with NodeJS you can use the in your own codebase to retrieve form definitions.
Clicking on the 'Go to backoffice' link will open up a new tab with the login screen for the Backoffice. If you would like to learn more, you can read our documentation for the.
The Preview API is available on https://preview.umbraco.io
and its endpoints are identical to the, meaning that you can swap the url out if you don't use one of our Client Libraries.
If you are using theyou set preview: true
, set an apiKey
as shown below, this switches all of the client.delivery
functions to use the Preview API instead of the Content Delivery API.
For the you'll create a new instance of the Umbraco.Headless.Client.Net.Delivery.ContentPreviewService
. It's based on the IContentDeliveryService
interface, which the ContentDeliveryService
also implements.
We've built a few client libraries with samples that you can use for testing. You can find them in the
You can learn more about the API Browser and how to use it in the.
Intro Text
Textarea Data Type
PromoImage
Media Picker Data Type
SubTitle
Textstring Data Type
MainContent
Richtext Editor Data Type
BlogDescription
Textarea Data Type
Starter
25
Standard
50
Professional
75
Enterprise
Starting from 75
Documentation for Heartcore Content Delivery APIs
This is the read-only API for delivering published content and media to any app, website, device or platform.
It’s worth noting that the JSON output for both Content and Media vary depending on how a given ContentType or MediaType is defined.
Specific to Content in the Content Delivery API.
To request content in a specific language, a culture parameter can be specified. When no culture is specified its treated as invariant and the default language will be returned.
Content endpoints for retrieving specific content by ID or URL. It is also possible to retrieve children, descendants and ancestors structured according to the Content tree structure.
Media endpoints for retrieving specific media by id. It is also possible getting children of a media folder structured according to the Media tree structure.
Documentation for Umbraco Heartcore REST APIs
This page contains documentation for the available API endpoints for Umbraco Heartcore. It includes endpoints for the GraphQL API as well as for the REST API which is divided into two main areas: Content Delivery and Content Management.
The GraphQL API can be used to query the read-only Content that you would normally retrieve to show the published content in your apps, websites, or other platforms. The API is available on https://graphql.umbraco.io
. This API is available on Trial projects as well as Starter and Professional Plans.
The Content Delivery API is a read-only Content and Media API that you would normally retrieve to show the published content in your apps, websites or other platforms. The API is available on https://cdn.umbraco.io
.
The Content Management API can be used to Create, Read, Update and Delete Content, Media, Languages, Relations, Members, and the associated types using Umbraco Backoffice user credentials or API Keys. The API is available on https://api.umbraco.io
.
The Preview API is the read-only Content and Media that you would retrieve to show the draft content in your apps, websites, or other platforms. The API is available on https://preview.umbraco.io
. The Preview API is always protected and requires an Api-Key
. The endpoints are the same as the Content Delivery API.
The REST APIs are based on the HAL Standard.
The properties in the REST API, which starts with an underscore, are system level properties. That means that they are standard Umbraco properties, which cannot be changed via the API. This includes properties like _id
, _url
, _createDate
, _updateDate
, _creatorName
, _writerName
, _level
and _hasChildren
. These are all defined by Umbraco when Content is created or updated.
The properties _links
and _embedded
are both part of the HAL specification and are implemented in the REST API accordingly.
In the Settings section in the Umbraco Backoffice, there is a Headless tree. From there you can use the API Browser to interact with both the Content Delivery and Content Management APIs.
It is recommended to use this browser to explore the JSON output for all the different endpoints documented under the Content Delivery and Content Management API sections.
Both the Content Delivery and the Content Management APIs share common points of configuration for access, versioning, culture and authentication/authorization, which are highlighted below.
In order to access the data for your Umbraco Heartcore project you need to provide a project identifier (Project Alias) via a HTTP Header or a Querystring parameter.
The Project Alias is a HTTP friendly version of the Project Name under your Umbraco Cloud account.
API versioning is handled by ASP.NET API Versioning.
All API requests need to specify the API version they target. If no version is specified, the latest version of the API is used, which will break clients when a new version of the API is released.
By default the Content Delivery API is not protected, it can be enabled through the backoffice. The Content Management API is always protected and requires either an API key or a bearer token.
Since both API keys and bearer tokens are created for a specific user their permissions can be set on that user in the backoffice.
API keys can be managed for a user through the backoffice.
When using the Authorization
header the API key must be passed in as the username and the password must be left empty. The value must be base64 encoded e.g. base64(api-key:)
This feature is currently not available when using External Login Providers.
The endpoints implement OAuth 2.0.
A bearer token can be created by posting to https://api.umbraco.io/oauth/token
and supplying a username and password for a backoffice user. This corresponds to a user logging into the backoffice and is thus only meant to be used for the Content Management API.
It can be used by passing it to the Authorization
header.
A member login can be used to access the Content Delivery API if it's protected. Members will only have access to Content Delivery Network (CDN) endpoints and cannot be used to access the Content Management API.
Content can be restricted further by using the Public Access feature in Umbraco to only allow access for specific Members or Member Groups.
Do note that you will need an API key header if the Content Delivery API cdn.umbraco.io
is set to protected via the backoffice.
The endpoints implements OAuth 2.0.
A bearer token can be created by posting to https://cdn.umbraco.io/member/oauth/token
and supplying a username and password for a member.
It can be used by passing it to the Authorization
header.
BASE URL: https://cdn.umbraco.io
If an error occours you will receive a HTTP status code along with an API error code and an error message in the response body.
401
Unauthorized
Authorization has been denied for this request.
404
NotFound
Media with id '{id}' could not be found.
500
InternalServerError
Internal server error.
JSON example:
Get all media at the root of the tree.
URL: /media
Method: GET
Code: 200
Content Example:
Get a single media by its ID.
URL: /media/{id}
Method: GET
Code: 200
Content Example:
Get children of a single media.
URL: /media/{id}/children
Method: GET
Query Strings
Code: 200
Content Example:
This is the read-only API for delivering redirects, caused by moving or renaming content in the Umbraco backoffice, to any app, website, device, or platform.
To request redirects in a specific language, a culture parameter can be specified. When no culture is specified it's treated as invariant and the default language will be returned.
If an error occurs, you will receive a HTTP status code along with an API error code and an error message in the response body.
JSON example:
Get all redirect URLs.
The key is the URL of the content and the values are the URLs redirecting to the content.
URL: /redirect
Method: GET
Query Strings
The maximum page size is 1000.
Code: 200
Content Example:
Get the destination URL and redirect URLs for a given path.
URL: /redirect/redirecturl?url={url}
Method: GET
Code: 200
Content Example:
Webhooks give you the ability to send information about events in Heartcore to external systems. They work by sending an HTTP POST request to a configured endpoint, with information about the event in the request body.
Webhooks can keep other systems in-sync with content from Heartcore without having to poll it for changes.
One common use case is building static websites. By adding a webhook, you can inform your chosen static site builder when content changes so that it can re-generate static assets on demand.
Webhooks are managed from a dashboard in the settings section of the backoffice.
Go to the Settings section.
Expand the Headless folder in the Settings tree.
Select Webhooks.
Click Create Webhook.
The Add webhook menu opens on the right side.
Enter the URL that the webhook should call.
Select the Event for which the webhook should be triggered.
Choose a Content Type you wish the webhook to be triggered on.
Selecting the Content Type is the initial step. This field is not mandatory.
Click Create.
Once the webhook has been created you can manage it from the dashboard.
To temporarily pause/disable the webhook, click on Edit and toggle the Enabled field.
Below is an overview of the webhook configuration options.
Url
The URL that Heartcore will send a POST request to when conditions are met.
Events
Backoffice or Management API action(s) that will cause the webhook request to be sent.
Content Type (optional)
Restrict the webhook to firing only if one of these content or media types were affected by one of the selected events.
Enabled
Toggle the webhook on or off. While disabled, no requests will be sent.
Headers
Configure custom HTTP headers to be sent with the request. May be useful for e.g. identifying the source of a request or for authorization.
When a webhook is triggered, if it fails to be processed by the endpoint Heartcore attempts to re-deliver it up to 9 more times.
The endpoint returned a non HTTP-compliant response
The endpoint returned an HTTP response with any status code other than a successful one (HTTP 200 - 299)
The endpoint failed to respond within a timeout period
Webhooks are guaranteed to be delivered at least once. I.e. even for a webhook that is delivered successfully, in some situations that hook may be re-delivered.
Your webhook endpoints should thus be capable of handling multiple deliveries. Ideally they are idempotent.
If an endpoint is slow or unresponsive, then webhook delivery may be briefly paused to that endpoint. No messages will be dropped (unless the retry count has been exceeded), but messages will be rescheduled for delivery a short time later. This gives the endpoint room to recover from traffic spikes.
Webhooks will be fired from either of the two static IP addresses listed below.
When your endpoint refers to a service behind a firewall, you may need some additional firewall configuration. You should ensure that HTTP traffic from these addresses is allowed to pass through the firewall:
Or if your firewall needs a Classless Inter-Domain Routing (CIDR) Range: 20.86.53.156/31
While structure changes are deployed between environments using the Cloud Portal, content and media transfers and restores are handled through the Umbraco Backoffice.
In order to be able to transfer/restore content and media, you need to make sure that the environments you're transferring between are in sync.
Learn more about how to do that, in the Structure deployments article.
Another difference between the two steps, is that content and media can be restored against the left-to-right flow. This means that when you have a lot of content on a Live environment, it is possible to restore all this content on a Development and/or Staging environment.
The screenshot above is from the Content section on a Development environment. Right-click the Content tree to open the menu as shown in the screenshot.
Queue for transfer gives you the option to queue all content in the Content tree for transfer to the next environment (Staging or Live). It is also possible to right-click single nodes in the content structure in order to only queue some of it for transfer.
Restore gives you the option to restore all content from environments right of the current environment. In some cases you might not want to restore all content as once, in which case you should use the Partial restore option instead. Partial restore can be found by right-clicking a node in the content tree.
Having multiple environments on your Umbraco Heartcore project can be a great asset for testing and having a place where your content editors can work without interfering with anything on the Live environment.
When working with multiple environments, it is important to follow the correct workflow. In this article, you can learn more about the workflow and the best practices for using it.
The workflow uses a classic "left to right" deployment model, meaning that changes are first made on the Development environment and then deployed to the Staging or Live environment. The workflow depends on whether you have a Staging environment which further depends on the plan your project is on.
We recommend that you do not work with Document Types directly on the Live environment. This should, as a rule of thumb always be done on the "lowest most" environment: the Development environment.
The deployment approach is divided into two steps:
Structure changes like Document Types and Data Types are deployed via the project portal page
Content and Media are transferred/restored via the Umbraco Backoffice
Each step is defined in more details in the following articles.
Structure changes like new and/or updated Document Types need to be deployed through environments using the Project View in the Cloud Portal.
In the screenshot above, changes made on a Development environment are ready to be deployed to the Live environment, as indicated by the blue button: "Deploy changes to Live". Had there been a Staging environment on the project, the changes would first be sent to the Staging and then opened up for the option to deploy from Staging to Live.
A deployment from one environment (source) to another (target) goes through the following steps:
The target environment is checked for changes
If changes are found, these are pulled down and merged into the source environment
The changes in the source environment are then pushed to the target environment
This process might take a few minutes, depending on the amount of changes being deployed.
Once your structure has been deployed, it will be possible to transfer your content and media as well. This is done from the Umbraco Backoffice - read more about this in the Content transfer/restore article.
400
AmbiguousCulture
The following cultures were requested: {cultures}. At most, only a single culture may be specified. Please update the intended culture and retry the request.
400
LanguageForCultureNotFound
Could not find a language for culture {culture}.
401
Unauthorized
Authorization has been denied for this request.
500
InternalServerError
Internal server error.
BASE URL: https://cdn.umbraco.io
The depth
querystring parameter controls how many levels of referenced Content or Media items that is included in the result.
Lets say a Content item have a Multi Node Tree Picker
and one of the Content items that can be picked have a Media Picker
. In this case, if the level is set to 1
the returned data will contain the referenced Content items, but their Media property will be null. To include the Media property (which is at level 2) the depth
parameter should be 2
or higher.
The lowest supported depth value is 0
and the highest is 5
.
If an error occours you will receive a HTTP status code along with an API error code and an error message in the response body.
400
AmbiguousCulture
The following cultures were requested: {cultures}. At most, only a single culture may be specified. Please update the intended culture and retry the request.
400
LanguageForCultureNotFound
Could not find a language for culture {culture}.
401
Unauthorized
Authorization has been denied for this request.
404
NotFound
Published content with id '{id}' and culture '{culture}' could not be found.
500
InternalServerError
Internal server error.
JSON example:
Gets all published content at the root of the tree.
URL: /content
Method: GET
Query Strings
Code: 200
Content Example:
Get a single published content by its ID.
URL: /content/{id}
Method: GET
Query Strings
Code: 200
Content Example:
Get a single published content by its URL.
URL: /content/url?url={url}
Method: GET
Query Strings
Code: 200
Content Example:
Get content by its Content Type.
Use the Content Type alias to filter all returned content to that specific type.
Example: GET /content/type?contentType=product
gets all content based on the product
Content Type.
URL: /content/type?contentType={string}
Method: GET
Query Strings
Code: 200
Content Example:
Get ancestors of a single published content.
URL: /content/{id}/ancestors
Method: GET
Query Strings
Code: 200
Content Example:
Get children of a single published content.
URL: /content/{id}/children
Method: GET
Query Strings
Code: 200
Content Example:
Get descendants of a single published content.
URL: /content/{id}/descendants
Method: GET
Query Strings
Code: 200
Content Example:
Get content filtered by property values and optionally content type.
This endpoint can be used for advanced filtering of content based on the value of specific properties. You can choose to filter on one or more properties by their alias
and a value
. The matching criteria include whether the property contains
or is like
the passed-in value.
Say you have a property with an alias
called "title" and you want all content, which contains
the word "world". The payload you post to the /content/filter
endpoint would be as shown below.
Setting the above properties to "hello world" results in content with a "title" property containing either "hello" or "world" as values.
If you want the value of a property to match on both "page" and "pages" then you could use like
with a payload as shown below.
Filtering is performed on individual content items, indicating that content matching is not conducted on related content or media.
URL: /content/filter
Method: POST
Query Strings
This endpoint is available from API-Version: 2.1. Specify the header as shown below when using the REST API.
In this example, we perform a filter with criteria for a "productName"-property containing the value "Jacket" and a "description"-property containing the value "Vivamus". Additionally, the Document Type should have the alias "product."
At least one object with alias
, value
and match
in the properties
array is required. The contentTypeAlias
is optional and the match
property can be either CONTAINS
or LIKE
.
Code: 200
Content Example:
Search for published content by keyword.
URL: /content/search?term={string}
Method: GET
Query Strings
Code: 200
Content Example:
Documentation for Heartcore Content Management APIs
This is the management API for creating, updating and deleting content, media, languages, relations, members and member groups. It also allows you to retrieve content drafts as well as Content Types, Media Types and Member Types.
Common for the Content Management API is that you must be authenticated and authorized when performing any action against the endpoints listed below. This means that you must supply a Bearer Token via an Authorization header or an API Key via an Authorization or Api-Key header.
Content endpoints for retrieving, creating, updating and deleting.
Content Type endpoints for retrieving all available and specific content types. We also expose endpoints for publishing and unpublishing content.
Media endpoints for retrieving, creating, updating and deleting.
Media Type endpoints for retrieving all available and specific media types.
Language endpoints for retrieving, creating, updating and deleting.
Member endpoints for retrieving, creating, updating and deleting. We also expose endpoints for adding a member to member group and removing a member group from a member.
Member Group endpoints for retrieving, creating and deleting.
Member Type endpoints for retrieving all available and specific member types.
Relation endpoints for retrieving, creating and deleting.
Relation Type endpoints for retrieving specific relation types.
Umbraco Forms endpoints for retrieving and submitting forms.
BASE URL: https://api.umbraco.io
Authentication is required for this API. You must supply a Bearer Token via an Authorization header or an API Key via an Authorization or Api-Key header.
If an error occours you will receive a HTTP status code along with an API error code and an error message in the response body.
400
BadRequest
Body cannot be empty.
401
Unauthorized
Authorization has been denied for this request.
403
Forbidden
You are not authorized to access the given resource.
404
NotFound
Language with id '{id}' could not be found.
409
LanguageForCultureAlreadyExist
The language '{isoCode}' already exists.
422
ValidationFailed
Validation error occured when trying to save or update the language.
500
InternalServerError
Internal server error.
JSON example:
Gets all languages available for content creation.
URL: /language
Method: GET
Permissions required : Access to Settings section of the Umbraco Backoffice
Code: 200
Content Example:
Get a specific langauge by its ISO code.
URL: /language/{id}
Method: GET
Permissions required : Access to Settings section of the Umbraco Backoffice
Code: 200
Content Example:
Create a new language for use on content.
The number of languages that can be created is determined by the pricing tier.
URL: /language
Method: POST
Permissions required : Access to Settings section of the Umbraco Backoffice
Code: 201
Content Example:
Updates an existing language.
URL: /language/{id}
Method: PUT
Permissions required : Access to Settings section of the Umbraco Backoffice
Code: 200
Content Example:
Deletes an existing language.
Deleting a language that is in use will result in setting the content based on this language to invariant
.
URL: /language/{id}
Method: DELETE
Permissions required : Access to Settings section of the Umbraco Backoffice
Code: 200
Content Example:
DELETE https://api.umbraco.io/language/da-DK
BASE URL: https://api.umbraco.io
Authentication is required for this API. This means that you must supply a Bearer Token via an Authorization header. Alternatively, you can supply an API Key via an Authorization or Api-Key header.
In addition to the specific permissions listed under each endpoint, all requests requires:
Access to the Content Section of the Umbraco Backoffice and
That the content being accessed is beneath the users start node configured in Umbraco
If an error occours you will receive a HTTP status code along with an API error code and an error message in the response body.
400
BadRequest
Body cannot be empty.
401
Unauthorized
Authorization has been denied for this request.
403
Forbidden
You are not authorized to access the given resource.
404
NotFound
Content with id '{id}' could not be found.
422
ValidationFailed
Validation error occured when trying to save or update the content item.
500
InternalServerError
Internal server error.
JSON example:
Get all content at the root of the tree, which the authorized user has access to according to the 'Start node'-permissions.
URL: /content
Method: GET
Permissions required : Browse Node
Code: 200
Content Example:
Get specific content item by GUID ID. Includes all language variations.
URL: /content/{id}
Method: GET
Permissions required : Browse Node
Code: 200
Content Example:
Get a list of children (content items) by parent GUID ID. Includes all language variations per content item.
URL: /content/{id}/children
Method: GET
Query Strings
Permissions required : Browse Node
Code: 200
Content Example:
Create a new content item with one or more language variations.
All newly created content will be DRAFT
by default. If you want to publish it you will need to issue a publish request as well.
URL: /content
Method: POST
Permissions required : Create
In this example only one language exists, so the properties are marked with $invariant
in the create request. If multiple languages exists the culture for each of the languages would be defined for each of the properties - example: "name": { "en-US": "Another one", "da-DK": "Endnu en" }
.
If a property uses a multinode treepicker editor, the value should be a comma-separated list of Umbraco UDI Identifiers. In the example below, the UDI Identifiers are referencing content items. To learn more see the UDI Identifiers documentation.
Code: 201
Content Example:
Create a new content item with one or more language variations and files.
When content contains an upload field it is possible to send a file along with the request to create new content. This is done by sending a multi-part request with the JSON body and the file.
If the content item doesn't include files then you can send a standard reqeust with a JSON payload to create a new content item.
All newly created content will be DRAFT
by default. If you want to publish it you will need to issue a publish request as well.
URL: /content
Method: POST
Header: Content-Type: multipart/form-data; boundary=MultipartBoundry
Permissions required : Create
The request must contain a field named content
that contains the content JSON.
For the files being uploaded the field names must be in the format propertyName.culture
. An example could be when the content has an upload property with the name fileUpload
and the file is being uploaded to the en-US
lanugage. In that case the field name should be fileUpload.en-US
.
The property must also be includud in the content JSON and the value shoud be the filename.
Code: 201
Content Example:
Updates an existing content item that has one or more language variations.
When content contains an upload field it is possible to send a file along with the request to update content. This is done by sending a multi-part request with the json body and the file, see Create content with files for an example. If the content item doesn't include files then you can send a standard reqeust with a JSON payload to update the content item.
URL: /content/{id}
Method: PUT
Permissions required : Update
In this example only one language exists, so the properties are marked with $invariant
. If multiple languages existed the culture for each of the languages would be defined for each of the properties. Ie.: "name": { "en-US": "Another one", "da-DK": "Endnu en" }
.
If a property uses a multinode treepicker editor, the value should be a comma-separated list of Umbraco UDI Identifiers. In the example below, the UDI Identifiers are referencing content items. To learn more see the UDI Identifiers documentation.
Code: 200
Content Example:
Publish specific content item with all language variations or for a specific language.
URL: /content/{id}/publish
Method: PUT
Query Strings
Permissions required : Publish
Code: 200
Content Example:
Unpublish specific content item with all language variations or for a specific language.
URL: /content/{id}/unpublish
Method: PUT
Query Strings
Permissions required : Unpublish
Code: 200
Content Example:
Delete a specific content item with all its language variations.
URL: /content/{id}
Method: DELETE
Permissions required : Delete
Code: 200
Content Example:
DELETE https://api.umbraco.io/content/041067a0-74f5-4d03-92af-40c3c0aa13e7
BASE URL: https://api.umbraco.io
API version: 2.1
The availability of Umbraco Forms depend on the plan. See the Pricing & Features for an overview of which plans includes Forms.
Auth is required for this API meaning that you must supply a Bearer Token via an Authorization header or an API Key via an Authorization or Api-Key header.
If an error occurs you will receive a HTTP status code along with an API error code and an error message in the response body.
400
BadRequest
Body cannot be empty.
401
Unauthorized
Authorization has been denied for this request.
403
Forbidden
You are not authorized to access the given resource.
404
NotFound
Form with id '{id}' could not be found.
422
ValidationFailed
Validation error.
500
InternalServerError
Internal server error.
JSON example:
The field types gets mapped to a more machine friendly name
Checkbox
checkbox
string("on") / boolean
Date
date
Data Consent
dataConsent
string("on") / boolean
Dropdown
dropdown
string
Hidden
hidden
string
Long Answer
textarea
string
Multiple Choice
checkboxList
string
Password
password
string
Recaptcha2
recaptcha2
string(reCaptcha response)
Short Answer
text
string
Single Choice
radio
string
Title And Description
titleAndDescription
readonly
Gets all forms.
URL: /forms
Method: GET
Permissions required : Access to Forms section of the Umbraco Backoffice
Code: 200
Content Example:
Get a specific form by its ID.
URL: /forms/{id}
Method: GET
Permissions required : Access to Forms section of the Umbraco Backoffice
Code: 200
Content Example:
Submit form entries for a specific Form - this is what you would use when a form is submitted from your presentation layer.
URL: /forms/{id}/entries
Method: POST
Permissions required : Access to Forms section of the Umbraco Backoffice
The JSON property names are the form field alias
Code: 202
Documentation for Umbraco Heartcore GraphQL API
The GraphQL API can be accessed on https://graphql.umbraco.io
, it accepts POST requests with the content type application/json
. The body must be JSON and contain a query
field with the query as a string and an optional variables
field containing the variables.
In order to access the data for your Umbraco Heartcore project you need to provide a project identifier (Project Alias) via an HTTP Header or a Querystring parameter.
The Project Alias is an HTTP friendly version of the Project Name under your Umbraco Cloud account.
By default the GraphQL API is not protected. This can be enabled through the Backoffice, where API keys for each user in the Backoffice is also managed.
To access the GraphQL API the user must have access to the Content
section and have the Browse Node
permission.
The GraphQL API supports fetching draft content, this can be done by passing a preview
argument to the root query fields.
Fetching draft content requires an API Key to be passed with the request.
The persisted queries also support variables
Information on how the GraphQL schema is generated, reserved names and built-in custom types.
A list of all the built-in Umbraco Property Editors and their GraphQL types.
Documentation on how to filter and order collections with the GraphQL API.
BASE URL: https://api.umbraco.io
Authentication is required for this API. You must supply a Bearer Token via an Authorization header or an API Key through an Authorization or Api-Key header.
If an error occours you will receive a HTTP status code along with an API error code and an error message in the response body.
JSON example:
Get a list of all available Content Types.
URL: /content/type
Method: GET
Permissions required : Access to Settings section of the Umbraco Backoffice
Code: 200
Content Example:
Get a specific Content Type by its alias.
URL: /content/type/{alias}
Method: GET
Permissions required : Access to Settings section of the Umbraco Backoffice
Code: 200
Content Example:
BASE URL: https://api.umbraco.io
Auth is required for this API meaning that you must supply a Bearer Token via an Authorization header or an API Key via an Authorization or Api-Key header.
If an error occours you will receive a HTTP status code along with an API error code and an error message in the response body.
JSON example:
Get a list of all available Media Types.
URL: /media/type
Method: GET
Permissions required : Access to Settings section of the Umbraco Backoffice
Code: 200
Content Example:
Get a specific Media Type by its alias.
URL: /media/type/{alias}
Method: GET
Permissions required : Access to Settings section of the Umbraco Backoffice
Code: 200
Content Example:
BASE URL: https://api.umbraco.io
Auth is required for this API meaning that you must supply a Bearer Token via an Authorization header or an API Key via an Authorization or Api-Key header.
If an error occours you will receive a HTTP status code along with an API error code and an error message in the response body.
JSON example:
Get a list of all available member types.
URL: /member/type
Method: GET
Permissions required : Access to Settings section of the Umbraco Backoffice
Code: 200
Content Example:
Get a specific member type by its alias.
URL: /member/type/{alias}
Method: GET
Permissions required : Access to Settings section of the Umbraco Backoffice
Code: 200
Content Example:
BASE URL: https://api.umbraco.io
Authentication is required for this API. You must supply a Bearer Token via an Authorization header or an API Key through an Authorization or Api-Key header.
If an error occours you will receive a HTTP status code along with an API error code and an error message in the response body.
JSON example:
Get a specific member by their username.
URL: /member/{username}
Method: GET
Permissions required : Access to Member section of the Umbraco Backoffice
Code: 200
Content Example:
Create a new member.
To set a password when creating a member a password
field must be included in the posted data. If the password field is omitted no password will be set.
URL: /member/
Method: POST
Permissions required : Access to Member section of the Umbraco Backoffice
Code: 201
Content Example:
Update an existing member.
A member can be unlocked by setting isLockedOut
to false
in the request. Note that a member cannot be locked by setting the value to true
; it will be ignored if the user is not already locked out.
URL: /member/{username}
Method: PUT
Permissions required : Access to Member section of the Umbraco Backoffice
Code: 200
Content Example:
Delete an existing member by their username.
URL: /member/{username}
Method: DELETE
Permissions required : Access to Member section of the Umbraco Backoffice
Code: 200
Content Example:
Change a members password.
URL: /member/{username}/password
Method: POST
Permissions required : Access to Member section of the Umbraco Backoffice
Code: 200
Content Example:
Get a reset password token.
URL: /member/{username}/password/reset-token
Method: GET
Permissions required : Access to Member section of the Umbraco Backoffice
Code: 200
Content Example:
Reset a members password.
URL: /member/{username}/password/reset
Method: POST
Permissions required : Access to Member section of the Umbraco Backoffice
Code: 200
Content Example:
Add an existing member to an existing member group.
URL: /member/{username}/groups/{groupName}
Method: PUT
Permissions required : Access to Member section of the Umbraco Backoffice
Code: 200
Remove a specific member from a specific member group.
URL: /member/{username}/groups/{groupName}
Method: DELETE
Permissions required : Access to Member section of the Umbraco Backoffice
Code: 200
BASE URL: https://api.umbraco.io
Auth is required for this API meaning that you must supply a Bearer Token via an Authorization header or an API Key via an Authorization or Api-Key header.
If an error occours you will receive a HTTP status code along with an API error code and an error message in the response body.
JSON example:
Get a list of all available relation types.
URL: /relation/type
Method: GET
Permissions required : Access to Settings section of the Umbraco Backoffice
Code: 200
Content Example:
Get a specific Relation Type by its alias.
URL: /relation/type/{alias}
Method: GET
Permissions required : Access to Settings section of the Umbraco Backoffice
Code: 200
Content Example:
BASE URL: https://api.umbraco.io
Auth is required for this API meaning that you must supply a Bearer Token via an Authorization header or an API Key via an Authorization or Api-Key header.
If an error occours you will receive a HTTP status code along with an API error code and an error message in the response body.
JSON example:
Get all media at the root of the tree, which the authorized user has access to according to the 'Start node'-permissions.
URL: /media
Method: GET
Permissions required : Access to Media section of the Umbraco Backoffice
Code: 200
Content Example:
Get specific media item by its GUID ID.
URL: /media/{id}
Method: GET
Permissions required : Access to Media section of the Umbraco Backoffice
Code: 200
Content Example:
Get a list of children (media items) by their parent GUID ID.
URL: /media/{id}/children
Method: GET
Query Strings
Permissions required : Access to Media section of the Umbraco Backoffice
Code: 200
Content Example:
Create a new media item and optionally upload a file to the created item.
Media can be created by sending a POST request to the media endpoint. The request body should contain the media item properties and the file to upload. The file is sent as a multi-part request. The first MultipartBoundary
contains the JSON body describing the content for the image. The second MultipartBoundary
contains the file. If the media item does not contain a file you can send a regular JSON request to create the media.
The umbracoFile.src
property in the first MultipartBoundary
's JSON body defines the name of the file to be uploaded. The fileName
in the second MultipartBoundary
must match the umbracoFile.src
property's value.
URL: /media
Method: POST
Header: Content-Type: multipart/form-data; boundary=MultipartBoundry
Permissions required : Access to Media section of the Umbraco Backoffice
Code: 201
Content Example:
Updates an existing media item and optionally uploads a file to the updated item.
Media would typically contain an upload field (the Image
and File
media types has this by default), which means it is possible to send a file along with the request to update an existing media item. This is done by sending a multi-part request with the JSON body and the file. If the media item does not contain a file you can send a regular JSON request to update the media.
URL: /media/{id}
Method: PUT
Header: Content-Type: multipart/form-data; boundary=MultipartBoundry
Permissions required : Access to Media section of the Umbraco Backoffice
Code: 200
Content Example:
Delete a media item. This will also delete any file that is attached to the media item.
URL: /media/{id}
Method: DELETE
Permissions required : Access to Media section of the Umbraco Backoffice
Code: 200
Content Example:
DELETE https://api.umbraco.io/media/b60a1257-4bef-4d5a-aeb6-4af17b6233b2
BASE URL: https://api.umbraco.io
Auth is required for this API meaning that you must supply a Bearer Token via an Authorization header or an API Key via an Authorization or Api-Key header.
If an error occours you will receive a HTTP status code along with an API error code and an error message in the response body.
JSON example:
Get a specific relation by its integer
ID.
URL: /relation/{id}
Method: GET
Permissions required : Access to Settings section of the Umbraco Backoffice
Code: 200
Content Example:
Get a list of relations by their Relation Type alias.
URL: /relation/{alias}
Method: GET
Permissions required : Access to Settings section of the Umbraco Backoffice
Code: 200
Content Example:
Get a list of relations by their parents GUID ID.
URL: /relation/parent/{id}
Method: GET
Permissions required : Access to Settings section of the Umbraco Backoffice
Code: 200
Content Example:
Get a list of relations by their childs GUID ID.
URL: /relation/child/{id}
Method: GET
Permissions required : Access to Settings section of the Umbraco Backoffice
Code: 200
Content Example:
Create a new relation.
URL: /relation/
Method: POST
Permissions required : Access to Settings section of the Umbraco Backoffice
Code: 201
Content Example:
Delete a relation by its integer
ID.
URL: /relation/{id}
Method: DELETE
Permissions required : Access to Settings section of the Umbraco Backoffice
Code: 200
Content Example:
DELETE https://api.umbraco.io/relation/4
BASE URL: https://api.umbraco.io
Auth is required for this API meaning that you must supply a Bearer Token via an Authorization header or an API Key via an Authorization or Api-Key header.
If an error occours you will receive a HTTP status code along with an API error code and an error message in the response body.
JSON example:
Get all Member Groups.
URL: /member/group
Method: GET
Permissions required : Access to Member section of the Umbraco Backoffice
Code: 200
Content Example:
Get a specific Member Group by its name.
URL: /member/group/{name}
Method: GET
Permissions required : Access to Member section of the Umbraco Backoffice
Code: 200
Content Example:
Create a new Member Group.
URL: /member/group
Method: POST
Permissions required : Access to Member section of the Umbraco Backoffice
Code: 201
Content Example:
Delete an existing Member Group.
URL: /member/group/{name}
Method: DELETE
Permissions required : Access to Member section of the Umbraco Backoffice
Code: 200
Content Example:
DELETE https://api.umbraco.io/member/group/Elite%20Shoppers%20Group
date ()
The GraphQL API supports , running a persisted query can be done using the following payload in the Graphql request:
Persisted queries can be created within the backoffice in the
Different media property editors will require different request body formats.The File Upload property editor has the file name as the value "umbracoFile": FILE_NAME
, and the Image Cropper property editor expects a JSON value "umbracoFile": { "src": FILE_NAME }
. To verify the JSON structure you can manually upload the media file via the backoffice and fetch the data. It can then be used for reference. (See how in the tutorial.)
401
Unauthorized
Authorization has been denied for this request.
403
Forbidden
You are not authorized to access the given resource.
404
NotFound
Content Type with alias '{alias}' could not be found.
500
InternalServerError
Internal server error.
401
Unauthorized
Authorization has been denied for this request.
403
Forbidden
You are not authorized to access the given resource.
404
NotFound
Media Type with alias '{alias}' could not be found.
500
InternalServerError
Internal server error.
401
Unauthorized
Authorization has been denied for this request.
403
Forbidden
You are not authorized to access the given resource.
404
NotFound
Member Type with alias '{alias}' could not be found.
500
InternalServerError
Internal server error.
400
BadRequest
Body cannot be empty.
400
CouldNotUnlockUser
Could not unlock the user.
401
Unauthorized
Authorization has been denied for this request.
403
Forbidden
You are not authorized to access the given resource.
404
NotFound
Member with username '{username}' could not be found.
422
ValidationFailed
Validation error occured when trying to save or update the member.
500
InternalServerError
Internal server error.
401
Unauthorized
Authorization has been denied for this request.
403
Forbidden
You are not authorized to access the given resource.
404
NotFound
Relation Type with alias '{alias}' could not be found.
500
InternalServerError
Internal server error.
400
BadRequest
Body cannot be empty.
401
Unauthorized
Authorization has been denied for this request.
403
Forbidden
You are not authorized to access the given resource.
404
NotFound
Media with id '{id}' could not be found.
422
ValidationFailed
Validation error occured when trying to save or update the media item.
500
InternalServerError
Internal server error.
400
BadRequest
Body cannot be empty.
401
Unauthorized
Authorization has been denied for this request.
403
Forbidden
You are not authorized to access the given resource.
404
NotFound
Relation with id '{id}' could not be found.
422
ValidationFailed
Validation error occured when trying to save or update the relation.
500
InternalServerError
Internal server error.
400
BadRequest
Body cannot be empty.
401
Unauthorized
Authorization has been denied for this request.
403
Forbidden
You are not authorized to access the given resource.
404
NotFound
Member Group with name '{name}' could not be found.
422
ValidationFailed
Validation error occured when trying to save or update the member group.
500
InternalServerError
Internal server error.
In order for you to get started with Umbraco Heartcore we have created a set of client libraries for you to use for testing and for getting a seamless start with the product.
The client libraries provide you with a starting point where you do not need to worry about implementing the use of each API endpoint, as these have already been setup. All you need to do is connect the client library to your Umbraco Heartcore project. How this connection is made depends on the client library, but usually requires configuring a couple of parameters.
We recommend testing with these libraries if you are looking to explore the potential of Umbraco Heartcore.
Both client libraries include samples that you can connect to your Heartcore project and start testing in no time.
tip Our client libraries are open source and free to use.
Found a bug? Please let us know by using the Issue Tracker on the GitHub repositories:
A .NET client library based on .NET Standard 2.0 to support application development including Xamarin/UWP applications.
This client library includes three samples:
An ASP.NET Core MVC sample site, with custom routing and controller hijacking.
A console application, with options using the Content Delivery and the Content Management API.
A Blazor Server sample showing how to use the .NET library to present your Umbraco Heartcore content in a Blazor application.
A Node.js client library including a Koa sample that you can hook up to your Umbraco Heartcore project for testing.
Learn how to fetch content and media from your Umbraco Heartcore project using Node.js and the Umbraco.Headless.Client.NodeJs Library.
This article showcases how to fetch content and media from your Umbraco Heartcore project using the official Node.js Client Library. If you are not familiar with Node.js you can take a look at the official Node.js Documentation.
Node.js (version 10 or above) installed on your machine. You can verify the version by running node -v
in your terminal.
Access to an Umbraco Heartcore project.
An API key generated from your Heartcore project. For more information, see the Backoffice Users and API Keys article.
Basic familiarity with terminal commands and Node.js.
Log into your Heartcore project on the Umbraco Cloud Portal.
Navigate to the Content section.
Create a new content item, such as a "Home Page." Fill in the necessary fields and publish it.
Go to the Media section.
Upload an image.
Note the content’s URL and media ID for fetching via the Node.js client.
Open a terminal or command prompt.
Navigate to the directory where you want your project to reside.
Run the following command to create a package.json
file:
There are two ways to install the Umbraco Headless Client Library:
Clone or download the Umbraco.Headless.Client.NodeJs client library from GitHub, or
Run the following command in your terminal:
Create a new file called app.js
using a text editor (such as Notepad++ or Visual Studio Code) in your project directory.
Open the app.js
file.
Use the following code template:
Open a terminal.
Navigate to your project folder.
Run the following command:
The Node.js library provides a variety of methods to fetch and manage data from your Umbraco Heartcore project. These methods allow you to interact with both the Content Delivery API and the Content Management API, depending on your requirements.
To fetch content or media, use the following convention:
In the above examples:
Use root()
to fetch all content or media from the root level.
Use children()
or ancestors()
to navigate the hierarchy and retrieve related content or media items. You can also fetch specific items directly by their ID or URL.
For a full list of available methods, visit the Content Delivery API sample repository on GitHub.
To manage content, media, and other types, use the following convention:
In the above examples:
Use create()
to add new content.
Use all()
to fetch all available content types.
For a full list of available methods, visit the Content Management API sample repository on GitHub.
Documentation for GraphQL filtering in Umbraco Heartcore.
The GraphQL API allows for filtering and ordering root and traversion collections (ancestors, children and descendants).
For information on the different filters available and how the filter and order types are generated see Schema Generation.
To start filtering the content, an where
argument can be passed to the collection query. E.g. to find all products where it's price is higher than 100 we can write the following query.
Filters can be combined with AND
and OR
, e.g. if we want to find all content on level 2
or 3
that is updated after 2020-03-13
we write the following query.
Or if we want to get all of type person which names does not start with t
we can write the following query.
We can combine AND
, OR
and NOT
in a single query e.g. if we wan't to get all content on level 1
or 2
that does not start with b
or j
we can write the following query.
Filtering can also be applied to types returning Content
and Media
, e.g. if we want all content of type Post
where the author name is Rasmus
, we can write the following query.
The collection can also return draft content by passing the preview
argument with a boolean to the query. Draft content is always protected and requires an Api-Key.
Lets say we want to show all our products that haven't been published, we can write the following query.
The collection can also be sorted by passing the orderBy
argument to the query.
If orderBy
is not specified the collections are ordered by path
which is the order they appear in, in the Umbraco Backoffice tree.
Lets say we want to show all our products ordered by price in ascending order, we can write the following query.
We can even add multiple values to the orderBy
argument to order by multiple fields. E.g. if we want to order products by price and then by name, we write the following query.
We can also limit the number of results returned by paging. To achieve this one can use first
and after
to do forward paging and last
and before
to do backward paging.
The cursor can be obtained by including the cursor
field on an edge e.g. to get the first 50
products we can write the following query.
We can then use the cursor
from the last item to get items that appear after that one. We can also request the PageInfo
object which holds information on the start and end cursors and if there are more pages.
first
can only be used in combination withafter
, and last
can only used with before
.
Also hasNextPage
is only populated when doing forward paging andasPreviousPage
is populated when doing backward paging.
Everything shown up until now can be combined in a single query, the following query will get the first 50 products where the price
is greater than 100
and order the result in ascending order by price
and then by name
.
Documentation for Umbraco Heartcore GraphQL property editors and their types
Below is a list of all the supported built-in Umbraco Property Editors and their GraphQL types. The type may depend on the configuration of the specific Property Editor.
Below is a list of property editors which is not supported in GraphQL and will not be present in the generated schema.
In this article, you can read more about the .NET Core Console Application.
We will go through the process of setting the application up and exploring what you can do with the application. We will also discuss how you can connect to your Heartcore project on Umbraco Cloud.
In order to use this console application, you will need to have the .NET Core SDK2.2. Older or newer versions will not work with the application.
Once you have cloned down the Umbraco Headless Client, there are two ways of running the application.
Open up the Umbraco.Headless.Client.Samples.Console.sln
file located at Umbraco.Headless.Client.Net\samples\Umbraco.Headless.Client.Samples.Console
and press F5. This will launch the Console application.
By using the command line, you will need to run the following commands from the Umbraco.Headless.Client.Samples.Console
folder in order to run the application.
In order to use this application to its fullest, you will need a Heartcore Project on Umbraco Cloud. If you do not have a project yet, you can create a trial. It is recommended that you have a project with both content and media items.
If you are connecting to a Heartcore Project with multiple environments you will have to use the alias for the Development environment.
If you do not have a project or trial you can also connect to demo-headless
.
Once you have entered the alias of the project, you are presented with the following options
Option A - E uses the Content Delivery API and can be used for any Heartcore Project, which has public content.
Option F uses the Content Management API.. This means that an API Key is required to run this part of the sample. This is because it will create a new folder in the Media Library and upload an image to a new Media item.
Fetching the data looks like the following.
In the example above we have fetched the Content Tree. Is shows all the Parent and Child Nodes. The Child Node is shown by an indentation.
In the next example, we have fetched the Root media.
It is showing the name of the Media items and a direct link to each of the Media items.
In this article you can learn more about the .NET client library that you can clone and use with your Umbraco Heartcore projects.
It is a library for .NET Core and is based on .NET Standard 2.0. This means that it can be used on the most .NET frameworks, for example UWP, Xamarin.Android, Xamarin.Mac and Desktop .NET 4.6.1.
The .NET library can be found on GitHub: .NET client library for Umbraco Heartcore.
You can also install it through NuGet:
Please be aware that the minimum NuGet client version requirement has been updated to 2.12. This change is made to support multiple .NET Standard targets in the NuGet package.
You will receive a Visual Studio solution file that references the client library (Umbraco.Headless.Client.Net). Additionally, there is a test project (Umbraco.Headless.Client.Net.Tests) utilizing xUnit for unit and integration tests.
Along with the client library you will also find two samples based on the library. We have built an MVC sample and a console sample.
Test your Umbraco Heartcore project against a small MVC site. You can choose to use our sample project and content, or connect to your own project and build your own views and controllers.
Get to know the content management service and how to use it to manage content and media programmatically.
Learn how to access and work with the Content Management API on your Umbraco Heartcore project.
This sample guide will cover how you can access and work with the Content Management API from the client library.
.NET/.NET Core (2.0 or newer) or .NET Framework (4.6.1 or newer)
Add the Umbraco.Headless.Client.Net
package to your project.
dotnet add package Umbraco.Headless.Client.Net
Add environment variables for your project alias and your API key.
Register the ContentManagementService
to your dependency injection container. The registration of the ContentManagementService
is handled by the AddUmbracoHeartcore
extension method.
Inject the ContentManagementService
into your non-static class.
If you don't want to use dependency injection, you can manually create an instance of the ContentManagementService
class. The constructor requires that you know the project alias and your API key.
Now you are ready to start using the ContentManagementService
.
When working with content, the ContentManagementService
can Get, Create, Update, Publish, Unpublish, and Delete content.
The ContentManagementService
has three methods for getting content.
GetRoot()
Gets all content at the root of the tree.
To use this method, call the method on the ContentManagementService
instance:
GetById(Guid id)
Gets a specific content item matching a GUID.
To use this method, call the method on the ContentManagementService
instance and pass in the GUID of the content item you want to get:
GetChildren(Guid id)
Gets all content that is a child of a specific content item.
To use this method, call the method on the ContentManagementService
instance and pass the GUID of the content item to get the children:
The ContentManagementService
has one method for creating content.
Create(Content content)
Creates a new content item based on the passed-in Content
object.
To use this method, call the method on the ContentManagementService
instance and pass in the content item you want to create:
The ContentManagementService
has one method for updating content.
Update(Content content)
Updates an existing content item based on the passed-in Content
object.
To use this method, call the method on the ContentManagementService
instance and pass in the content item you want to update:
The ContentManagementService
has one method for publishing content.
Publish(Guid id, string culture = "*")
Publishes an existing content item based on the passed-in GUID and culture.
To use this method, call the method on the ContentManagementService
instance and pass in the GUID of the content item you want to publish:
Optionally, you can also pass in the culture of the content item you want to publish:
The ContentManagementService
has one method for unpublishing content.
Unpublish(Guid id, string culture = "*")
Unpublishes an existing content item based on the passed-in GUID and culture.
To use this method, call the method on the ContentManagementService
instance and pass in the GUID of the content item you want to unpublish:
Optionally, you can also pass in the culture you want to unpublish the content item in:
The ContentManagementService
has one method for deleting content.
Delete(Guid id)
Deletes an existing content item based on the passed-in GUID.
To use this method, call the method on the ContentManagementService
instance and pass in the GUID of the content item you want to delete:
When working with media, the ContentManagementService
can Get, Create, Update and Delete media.
For Media you create programmatically, you have to use the "raw" property values that Umbraco expects for the specific property editor.
The different scenarios are:
File Upload (A File Upload property editor)
When uploading a file, you must specify the file name for the umbracoFile
property alias.
Image Upload (A Image Cropper property editor)
When uploading an Image (by default, it uses the Image Cropper property editor), you must specify the source's file name for the umbracoFile
property alias.
The ContentManagementService
has three methods for getting media.
GetRoot()
Gets all media at the root of the tree.
To use this method, call the method on the ContentManagementService
instance:
GetById(Guid id)
Gets a specific media item matching a GUID.
To use this method, call the method on the ContentManagementService
instance and pass in the GUID of the media item you want to get:
GetChildren(Guid id)
Gets all media that is a child of a specific media item.
To use this method, call the method on the ContentManagementService
instance and pass in the GUID of the media item to get the children:
The ContentManagementService
has one method for creating media.
Create(Media media)
Creates a new media item based on the passed-in Media
object.
To use this method, call the method on the ContentManagementService
instance and pass in the media item you want to create:
The ContentManagementService
has one method for updating media.
Update(Media media)
Updates an existing media item based on the passed-in Media
object.
To use this method, call the method on the ContentManagementService
instance and pass in the media item you want to update:
The ContentManagementService
has one method for deleting media.
Delete(Guid id)
Deletes an existing media item based on the passed-in GUID.
To use this method, call the method on the ContentManagementService
instance and pass in the GUID of the media item you want to delete:
Learn how to Create content programmatically.
Documentation for Umbraco Heartcore GraphQL schema generation
The GraphQL schema is generated from the Content Types upon creation, and it is generated when a Content Type or a Data Type is changed.
The type name is the Content Type's alias in Pascal Case, e.g. if a Content Type has an alias of product
it's GraphQL type name would be Product
.
The types generated depends on how the Content Types are configured.
If a Content Type is inherited from or used as a Composition it will be generated as an interface
If the Document Type is marked as an Element Type it will implement the Element interface
All other Content Types will implement either the Content or the Media interface, they will also implement all their Composition interfaces.
A Connection and an Edge type will also be generated, these are used when quering Content of a specific type.
All properties on a Content Type is generated as a field on the GraphQL type. See the Property Editors page for which types the editors are returning.
If a property is marked as Allow varying by culture, a culture
argument is added to that field. The argument is optional and will fallback to the parent fields culture or the default culture if none is specified.
The Query
type is the entry to the GraphQL API. By default it contains two fields, one to get a single Content item by ID
or url
and one to get all Content.
For each Document Type that is not used as a Composition or marked as an Element Type, two fields will be generated on the Query
type. One for getting a single Content item by either it's ID
or url
and a field for getting all Content of that specific type.
GraphQL requires that type names are unique. If a Content Type will collide with one of the reserved names the type will be excluded from generation.
The same applies to Properties. If a Property alias is a reserved one it will also be excluded from generation.
List of reserved type names, these cannot be used as an alias
for Content Types.
The GraphQL type name is the Content Type alias
converted to Pascal Case.
BigInt
BlockGrid
BlockGridArea
BlockGridItem
BlockListItem
Byte
Content
Date
DateTime
DateTimeOffset
Decimal
DecimalRange
Element
Guid
HTML
ImageCropAnchor
ImageCropFormat
ImageCropMode
ImageCropper
ImageCropperCrop
ImageCropperCropCoordinates
ImageCropperFocalPoint
ImageCropRatioMode
JSON
Link
LinkType
Long
Media
MediaConnection
MediaEdge
Milliseconds
OurUmbracoGMaps
OurUmbracoGMapsAddress
OurUmbracoGMapsCoordinate
OurUmbracoGMapsMapConfig
OurUmbracoGMapsMapType
PageInfo
PickedColor
Query
SByte
Seconds
Short
UInt
ULong
Uri
UShort
List of reserved Element Type Property names, these cannot be used as a Property alias
on an Element Type.
contentTypeAlias
List of reserved Content Type Property names, these cannot be used as a Property alias
on a Content Type.
ancestors
children
contentTypeAlias
createDate
descendants
id
level
name
parent
content
parentId
sortOrder
updateDate
url
List of reserved Media Type Property names, these cannot be used as a Property alias
on a Media Type.
ancestors
children
createDate
descendants
id
level
mediaTypeAlias
name
parent
sortOrder
updateDate
url
The Umbraco Heartcore GraphQL schema contains some default types, below you can find a list of these types.
The Property Editors page contains a list of all the Property Editors and which GraphQL types they return.
Query
Output
Query
Output
Query
Output
Query
Output:
Query:
Output:
Query:
Output:
Query:
Output:
Query:
Output:
Query:
Output:
Query:
Output:
Query:
Output:
Query:
Output:
Query:
Output:
Query:
Output:
Query:
Output:
Query:
Output:
Query:
Output:
Query:
Output:
Query:
Output:
Query:
Output:
Query:
Output:
Query:
Output:
Query:
Output:
Query:
Output:
Query:
Output:
For all Document Types a FilterInput
type is generated. The name is the type name postfixed by FilterInput
e.g. given a type named Product
the name will be ProductFilterInput
.
To filter the allContent
field, ancestors
, children
and descendants
connections the ContentFilterInput
is used.
All filter inputs for Content Types will also have the default fields.
Filtering is possible only on non-complex Property Editors like Text Area and Label. Filtering on more complex types like Content Picker and Multi-node Tree Picker has to be done client-side.
For fields returning String
the following filter fields are generated.
Given the following type:
The following type will be generated, incl. the fields from the ContentFilterInput
.
For fields returning Int
or Decimal
the following filters are generated.
The type is either Int
or Decimal
depending on the output type.
Given the following type:
The following type will be generated, incl. the fields from the ContentFilterInput
.
For types returning Boolean
the following filters are generated.
Given the following type:
The following type will be generated, incl. the fields from the ContentFilterInput
.
For types returning Content
the ContentFilterInput is used.
For types returning DateTime
the following filters are generated.
Given the following type:
The following type will be generated, incl. the fields from the ContentFilterInput
.
For types returning Media
the MediaFilterInput
is used.
For types returning [Decimal]
, [Int]
or [String]
the following filters are generated.
The type is [Decimal]
, [Int]
or [String]
depending on the output type
Given the following type:
The following type will be generated, incl. the fields from the ContentFilterInput
.
The result can be ordered by specifying a value for the orderBy
argument.
An OrderBy
type is generated for all Document Types. The name is the type name postfixed by OrderByInput
e.g. given a type named Product
the name will be ProductOrderByInput
.
Fields returning DateTime
, Decimal
, Boolean
, Int
or String
can be used to order by.
To filter the allContent
field, ancestors
, children
and descendants
connections the ContentOrderBy
is used.
All order by inputs for Content Types will also have the default fields.
The following type will be generated, incl. the fields from the ContentOrderByInput
.
If you don't specify any order the data returned will be ordered by the path they appear in, in the Umbraco Backoffice tree.
In /samples/Umbraco.Headless.Client.Samples.Web/
you will find a .NET 6.0-based MVC website implementation. It presents one possible approach to creating a website using Umbraco Heartcore for Content Delivery.
The sample is built around a sample project with the alias demo-headless
. You can choose to test the sample with the sample project or connect the sample to your own project.
Before running the sample, you must define which Umbraco Heartcore project you want to fetch content from.
Open the appsettings.json
found in samples/Umbraco.Headless.Client.Samples.Web/Umbraco.Headless.Client.Samples.Web/
Add your project alias or use the default alias of the sample project, demo-headless
The ApiKey
can be left blank when using the demo-headless
sample project. If you are testing with your project and have chosen to protect the content exposed via the Content Delivery API, you will need an API Key. It is an option that has to be actively turned on via the Umbraco Backoffice in the Headless tree in the Settings section. Read more about this feature in the Backoffice users and API Keys article.
The MVC sample can be run in one of two ways:
Using a command-line tool, run the following two commands in the Umbraco.Headless.Client.Samples.Web
folder:
The first command will restore the packages and the second will run the site. Alternatively, you can use the new hot-reload functionality:
To run the project and hot reload or recompile the project whenever changes are detected.
Run the application in Visual Studio or Visual Studio Code by hitting F5
.
Visual Studio Code (VSCode) requires you to have a launch configuration before F5
will work.
The editor will prompt you to add a launch configuration if you have the C#
extension installed in VSCode.
For the following section, a Umbraco Heartcore project with the following content structure will be used:
To connect to your project, you need to change the ProjectAlias
value in the application.json
file as demonstrated in Run the sample on your local machine.
When you have connected the client project to your Umbraco project and run the client project, you will be presented with a default page. The page shows the properties and the data from the content node at the root of your website. This is because no view or controller has yet been defined for your content structure.
We will need to define and build a view and/or an MVC controller for the content types (Document Types) in our client project in order for us to start rendering content.
There are two ways to do this:
Define a view file using the Document Type alias or
Build a controller using the already defined UmbracoController
Each approach is explained in more detail below.
Create a model class for the content type you want to render, e.g., Models/HomePage.cs
. Make sure the model extends the abstract class Content
and that the properties you want to render from the Umbraco content node are defined as public properties with PascalCasing. PascalCasing means that a content node property called personName
will be mapped to the PersonName
property in the model.
Create a homePage.cshtml
file in Views/DefaultUmbraco
- the name of the file should be the alias of the Document Type the root content node is using.
Set HomePage
as the model.
Set layout to null
- this can be used later on when you want to share one layout between more views.
When you build the solution and start it up, this view file will now be used to populate the frontend.
Right-click the Controllers
folder in Visual Studio and select Add > Controller...
Select MVC Controller - Empty
Use the alias of the Document Type used on the root content node for the name of the controller, e.g. HomePageController
Set the controller to use UmbracoController
Set the Index()
action to return UmbracoContext.Content
The controller is now in place but to show our content we also need to define a view.
Create a folder in /Views
using the alias of the Document Type, e.g. /HomePage
.
Create an Index.cshtml
file in the new folder.
Follow steps 2-3 from the Define a view file section.
Build and run the solution.
To render the data from the properties on our content, we need to use the @Model.PropertyName
approach, where the value is the Name of the property you want to display the data from.
An example could be a text string property with the alias heading
. To render the data from this property on the frontend, we will need to use @Model.Heading
.
note To render data from a property, the property must be defined in the view model (@model
), and it must match an alias on the corresponding content node from your Umbraco project.
Below is a complete example of how a view for a root node could look.
HTML is used to build the general structure of the article, while we use Razor to render data from our Umbraco Heartcore project.
Learn how to create a Custom Grid Editor in Umbraco Heartcore.
The grid editor Data Type in Heartcore is deprecated and will be retired in June 2025 or thereafter. For more information read the following blog post.
In this tutorial, we will create a Custom Grid Editor using custom elements and Lit. We will look at how we can define what the API response for our data should look like.
First, we will need to create a Document Type containing the Grid Layout property editor.
Go to the Settings section.
Create a new Document Type called Grid Page.
Add a new property called Grid Content.
Select the Grid layout editor.
Accept the default configuration.
The Document Type should now look like this:
To allow the Document Type to be created in the tree we need to change the permissions:
Select the Permissions tab.
Ensure Allow as root is checked.
To verify the configuration follow these steps:
Go to the Content section.
Create a new page based on the Grid Page Document Type we created.
Give it a name.
Save the page.
Try choosing a layout, add a row and click Add content. Here we will see that we have a couple of editors to choose from.
Try adding one of them to the page to see how they work.
Before we start writing our own Grid Editor, let's have a look at the Headline Grid Editor.
As we can see the page is divided into two sections; one with a Text Editor with the code for the editor and one with a preview of the editor.
Let's take a look at the code.
A custom editor inherits from HTMLElement
and must be the default export.
A couple of private fields are defined. One for storing a reference to the textarea
field and one for the HTML template.
In the constructor we set the inner HTML of our custom element to our template and set the #textarea
field to a reference to the textarea.
The click
method is called when the grid control is clicked. In this case we use it to set focus on the textarea.
A value
property is needed for the value to be stored when a page is saved and to set the value when the editor is loaded.
In this example the value property is setting and returning the value of the textarea.
For this tutorial we will create an image gallery editor using Lit. Lit builds on top of the Web Components standards and helps us avoid a lot of boilerplate code.
Go to the Settings section.
Create a new Grid Editor.
Choose an icon.
Name it Image Gallery.
Change the alias to my-image-gallery
.
The alias is used as the custom element tag name and must be unique. By choosing a prefix that is less likely to used by any other HTML element, in this case my-
, there is less chance for running into conflicts.
In the JS
view we can see there is already some boilerplate code. Let's replace it with the following:
The preview should now look like this:
Let's break down the code.
Here we're importing LitElement
, CSS and HTML from the Lit library.
We're exporting a default class inheriting from LitElement
.
We tell Lit that we have a value
property which we expect to be an Array
.
We define the styles in a static field called styles
. This will make Lit automatically inject a stylesheet into our custom element. The text returned needs to use the css
tag from Lit
. For more info see the Lit styles documentation.
The render method returns the HTML we want to show. It needs to be tagged with html
. For more info see the Lit templates documentation.
Let's save the editor and see how it looks when adding it to the a content item.
We now have the Add image button rendering, but clicking it does nothing. Let's do something about that.
Go back to the Settings section.
Click on the Image Gallery Grid Editor.
We will start by adding the following to the top of the file:
This imports the mediaPicker
function from the backoffice bridge library.
We will add another function before the render
function:
This will open the Media Picker with a configuration that only allows selecting images and showing the detail view, which allows us to enter an alt text, caption and choose a focal point.
The submit callback is called when the Submit is clicked. It will contain an array of the selected items. In this case it will contain a single item, but if we set multiple
to true
multiple items can be returned.
In our callback method we check if this.value
has been initialized. If it has not we initialize a new array. We then push the selected image to the array. Note that we also store the udi
(the id of the media) in a url
property. We will come back to why we do that later.
Since we add to the array and do not set the value
property we need to tell Lit that the property was updated. We do this by calling this.requestUpdate('value')
.
We will also need to add a click
event to the button so it will show the dialog:
Clicking the button in preview mode does nothing. This is because of a limitation when previewing where we do not have access to the full backoffice. Saving and testing on a Content item should work.
Click Save.
Go back to the content page.
Click the Add image
button.
We should now see the image overlay.
Selecting an image does not currently render anything. Let's do something about that. Go back to the grid editor code in the Settings section.
Update the render()
function with the following
We assign the editor value to a local variable items
, if this.value
is null
or undefined
we assign an empty array. Then in the HTML we are now looping over the items and returning an umbh-image
for each item. umbh-image
is a custom element included with the backoffice bridge, it takes an udi
and renders an images based on that.
Go back to the Content section try to add some images to a page using the editor.
We now have an editor that we can add images to which gets rendered in the backoffice. Next step would be to add edit and delete functionality, but we will leave that to the reader.
Up until now we have been using the full URL when importing third party modules into our editors. While this works fine most of the time, we will most likely run into issues when importing libraries that registers custom elements. This is because custom elements needs to be registered using an HTML tag and a tag can only be registered once.
Imagine we have an editor using custom elements from a third party library. We then create another editor using the same library but in a newer version which adds some new functionality to the custom element we use.
One of two things will happen:
The library checks if a custom element with the same name has already been registered and skips registration. This will leave us not knowing which version is used and might break our implementation.
It will try to register the element with the same name but fail because there is already an element registered with the same name.
In either case we will end up with a broken editor experience. This is where module aliases comes in.
Module aliases allows us to define a common name for a module that we can use in our editors instead of the full URL. A module alias can be defined by going to the Headless -> Custom Editor Configuration page in the Settings section.
Here we have defined an alias @headless-backoffice-bridge
pointing to a Content Delivery Network (CDN) URL of the backoffice bridge library.
With this alias added we can update our import in our editor to:
The alias will automatically be replaced with the URL we have defined, similar to how node
does.
By using the same alias in all our editors, we can ensure that only one version of the library is loaded. If we want to upgrade to a newer version, we will only need to update the URL in one place.
Now that we have a working editor, let's add a couple of images to our page. When done, click Save and publish.
Note down the Id from the Info tab. We will need that in a bit.
Go to the Settings section.
Expand the Headless node.
Open the API Browser
Type in https://cdn.umbraco.io/content/<CONTENT_ID>
in the Explorer URL bar, replacing <CONTENT-ID>
with the id we copied before.
Click Go!.
In the output we can see the JSON we have stored in the editor.
Notice our value stored is returned as a string
. This makes it hard to consume, since we will need to parse it as JSON everywhere we use that value. This is where JSON schemas comes in handy.
Let's go back to our Grid Editor implementation and see what we can do.
Looking at the default JSON schema we can see that the type is set to string
. This tells Heartcore that our editor is returning its data as a string
. This is what we saw before in the API response. Since we are storing an array of images, let's change the type
to array
. We also need to specify what the array is containing. We do that by adding an items
property containing a type: object
property.
Change the type
from string
to array
Add an items
property containing a type: object
property.
The schema should now look like this:
Let's go back to the API Browser, type the same URL as before and click Go!.
Inspecting the output, we can already see an improvement. The value is now returned as an array which is already much better.
Remember the url
property stored earlier? Let's make it return a URL instead of a UDI.
Go back to the Grid Editor schema.
Update it to the following:
With the JSON above we are adding a properties
object containing a url
property. This property has its type
set to string
, and most importantly, format
set to uri-reference
. By specifying the format
as uri-reference
Heartcore will try to parse the value as a UDI and if the UDI is for either a document or media, the URL of that item will be returned instead. We can see that if we go back to the API Browser.
We now have an array where each item has the URL to the picked media item.
While it is not necessary to define all properties in the JSON Schema, it is highly recommended as the schema is also used for validating the editor data when saving.
Besides the uri-reference
format there's also rich-text
. This is useful when storing rich text data like the output from the TinyMCE editor. When specifying the rich-text
format, things like {locallink}
and data-uri
will automatically be replaced with the correct URLs.
Related articles
Documentation for Persisted queries in Umbraco Heartcore
Persisted queries allow you to store GraphQL queries on the server. This enables clients to execute them by referencing an alias rather than sending the full query each time. this approach streamlines client-server communication and enhances security.
Reducing the payload size
You minimize the data transmitted over the network by sending only the alias and necessary variables. This reduction in payload size leads to faster request times and is particularly beneficial for mobile applications or environments with limited bandwidth.
Enhanced Security
Persisted queries provide improved security by ensuring that only predefined, server-stored GraphQL queries can be executed, preventing clients from running arbitrary or malicious queries.
To fully benefit from this, the content delivery API must be set to private, and GraphQL must be configured only to allow persisted queries. Without these settings in place, the security advantages of using persisted queries are not realized.
In order to fully benefit from the security enhancement that comes with persisted queries you need to enable the Only allow GraphQL persisted queries
setting. This can be done from the headless options section within the backoffice
Please be aware this will also disable the execution of queries in the playground.
Documentation for Custom Grid Editors in Umbraco Heartcore
The grid editor Data Type in Heartcore is deprecated and will be retired in June 2025 or thereafter. For more information read the following blog post.
A custom Grid Editor in Heartcore is built using custom elements.
Custom Grid Editors can be created under the Grid Editors tree in the Settings section.
The Grid Editor must export a default class inheriting from HTMLElement
For the Grid to be able to save the value the editor must contain a set value(value)
function and for the editor to be able to show the stored value, it must also contain a get value()
function.
The set value()
is called when the editor is loaded and when the value is changed outside of the editor.
The get value()
is called when the grid is saving and when the editor raises an input event.
External libraries can be imported by using the import statement.
For example, if you want to use Lit to create your web component it can be done like this
When importing libraries that registers variables or functions on the global object or custom elements it's advised to create a Module Alias and import that instead. By using Module Alias when importing we can ensure that only one version of a library is imported.
A Module Alias can be configured under Headless -> Custom Editors Configuration in the Settings section.
Use a Module Alias when importing libraries to ensure only a single version of that library is loaded.
Accessing backoffice components like the Media Picker must be done using the Headless Backoffice Bridge.
Using this library reduces breaking changes in the exposed API that would otherwise happen if the backoffice components were accessed directly.
Currently, the library is exposing only a few components but Feature Requests and Pull Requests are more than welcome.
The Headless backoffice Bridge has custom elements so it's advised to import using a Module Alias
A JSON Schema is used to describe how the value is stored and returned by the REST and GraphQL API.
This allows for advanced configurations where, for example, an UDI is converted to a URL.
The default Schema looks like this:
Since it has "type": "string"
the different APIs will return the stored value as a string.
If the editor stores an object
we can use "type": "object"
instead, now the APIs will return the value as a JSON object.
By also adding properties, the API will be more clever about how the data is returned.
For example, an image editor that stores an UDI
in the url
field and the alt text in the altText
field like this
Could have a schema like:
Notice how there's a "format":·"uri-reference"
to the url
property in the schema. Combined with "type": "string"
the APIs knows this is a URI and will try to parse the value stored as an UDI
and if successful, return the URL of the referenced item.
Currently, the following combinations are supported:
type: string
format: uri-reference
value: Content or Media UDI
returned: A URL to the item if exists.\
type: string
format: rich-text
value: Rich Text, for example from the TinyMCE editor
returned: The value where all a
tags with a locallink
href and img
tags with a data-udi
attribute is replaced with the correct links to the items.\
Currently, some functionality and components that do not work well in the preview pane. This includes integrations with the backoffice like Pickers and the Rich Text Editor. However, they still work when inserted on a page.
To make your custom editors less likely to break with future updates, do not use any of the backoffice JavaScript directly. Always use the headless backoffice bridge.
If the library is missing any functionality, raise an issue on the Heartcore issue tracker.
Try to avoid relying on backoffice CSS-classes. Instead, it's recommended creating isolated elements using shadow DOM.
In this tutorial, you will learn how to create content with media using the Management API.
The example will be using the Media Picker V3 property editor.
Determining the right request body for creating content through the Management API can be a bit tricky. One way to figure out the correct request body is to:
Create the content in the backoffice
Use the Management API Browser to get the properties for the content created.
You can then use the properties as a template for your request body when creating content through the Management API.
The following tutorial shows you the detailed process for determining the request body while creating content with a Media Picker V3 property.
To follow this guide using the Media Picker (legacy) property you need to replace the Media Picker V3 property. You need to do this when creating the Document Type and content nodes.
First, we must create a Document Type with a Media Picker V3 property. This will allow us to create content with the Media Picker V3 property.
To create a new Document Type with a Media Picker V3 property, follow these steps:
Go to the settings section in the backoffice and click the Document Types Create...
option, and then select the option to create a new Document Type in the sub-menu.
Fill in the name of the Document Type, create a new group and add a new property of the Media Picker V3 type.
Go to the Permissions page for the Document Type and enable 'Allow as root'.
Save the Document Type.
Now we must upload an image to the media section. This will allow us to select the image in the Media Picker V3 property on the content node we will create later.
To upload an image to the media section, do one of the following:
Do it later when creating the content node and selecting the image for the Media Picker V3 property.
Go to the media section in the backoffice and drag-and-drop an image into the media section.
Go to the media section in the backoffice and upload the image through the File
or Image
option in the Create
dropdown.
Send a request (for example with the Management API) to upload an image from binary data. See the API Documentation for more information on how to do this.
Next, we need to create a new content node of the new Document Type. This will allow us to query the content node using the Management API Browser.
To create a new content node of the new Document Type, follow these steps:
Go to the content section in the backoffice, click the three dots on the right side of the content sidebar, and select the Document Type we created earlier.
Fill in the name of the content node and select a fitting image for the Media Picker V3 property.
If you have not uploaded an image to the media section yet, you can do it when selecting the image for the Media Picker V3 property.
Save and Publish the content node.
To use the Management API, you need an API key. You can get your API key by following these steps:
Go to the Users
section in the backoffice and click the API Keys
tab in the editor window.
Click show on the API key you want to use.
If you do not have an API key yet, you can create one under Users > Your User > API Keys > Create API Key
. See the Getting Started section for more information on how to do this.
To query content using the Management API, you need the ID of the content node. You can get the ID of the content node by following these steps:
Go to the content section in the backoffice.
Click the content node you want to query.
Click the Info
tab in the editor window.
Copy the ID from the General
section in the editor window.
Now we can query the content node using the Management API Browser, the content node ID and our API Key. This will allow us to get the properties for the content node we created.
To query the content node using the Management API Browser, follow these steps:
Go to the settings section in the backoffice, unfold the Headless section, select the API Browser menu item, and click the Content Management tab in the editor window.
Write the request URL to query the newly created content, fill in the API Key as a Custom Request Header, and click the Go!
button.
Copy the properties from the response section in the editor window.
Finally, we need to clean up the properties, so it can be used as a template for our request body.
In this case, we can omit ID's and create/update dates as these are auto-generated at creation time:
Resulting in the following request body:
The media key is the ID of the image in the media section. As such it is the image reference to the image the Media Picker V3 property uses.
See the Media Picker 3 section for more info on the other properties.
If you copy the JSON from the response section to another editor/application make sure the formatting is correct, and no extra characters are added. These characters can be hidden but will cause the request to fail.
Following the steps demonstrated in the previous section, we can now create a new content node with a Media Picker using the Management API.
To create a new content node with a Media Picker, follow these steps:
Go to the Management API Browser, fill in the API Key as a Custom Request Header, and click the Go!
button.
Now click the small orange exclamation mark button next to the content
link in the Links
section. This opens up a modal with the option to make non-GET requests.
Next copy and paste your request body into the request body section in the modal.
Click the Make Request
button.
Now you have created a new content node with a Media Picker property editor that correctly references the image with the ID "766c9c5b-f4eb-4a5c-b94e-06701eafcbab".
After having created the content node it is time to publish it, so it can be viewed on the front-end.
To publish a content node with a Media Picker, follow these steps:
Go to the Management API Browser, fill in the API Key as a Custom Request Header, Write the request URL for the content, and click the Go!
button.
Navigate to and click the small orange exclamation mark button next to the publish
link in the Links
section.
Change the request type to PUT
, and leave the request body empty as an empty object.
Click the Make Request
button.
And you are done! You are now able to upload a media item and create a new content node using the newly uploaded media item in a Media Picker v3 property.
You can use a similar approach for discovering the format of more complex content when you want to create it through the Content Management API.
If you want to create content with media programmatically, you can try out the the .NET Client Library for Umbraco Heartcore. The client library also supports the use of the Management API.
Learn how to query Umbraco Heartcore with GraphQL.
In this tutorial we will be looking at how we can fetch data from Umbraco Heartcore using GraphQL.
We will be using https://demo.heartcore.dev/ as a reference.
At the end of the tutorial we should be able to use the Umbraco Heartcore GraphQL API and be able to fetch all the content needed to render the page in with a single query.
First, we will need to create some Document Types, and as a start, we will create some element types.
Start by creating a folder named Elements under the Document Types folder in the Settings section of the Backoffice.
In that folder create the following Document Types:
Alias: textAndImage
Add a new group called Content with the following properties:
Then under permissions check Element Type
Alias: uniqueSellingPoint
Add a new group called Content with the following properties:
Then under permissions check Element Type
Then create another folder called Compositions and create the following Document Types in that folder:
Alias: elementsComposition
Add a new group called Elements with the following properties:
Then click the Reorder button and change the value for Elements from 0
to 15
Alias: heroComposition
Add a new group called Hero with the following properties:
Alias: uniqueSellingPointsComposition
Add a new group called Unique Selling Points with the following properties:
Then click the Reorder button and change the value for Elements from 0
to 20
At the root create the following Document Types:
Alias: textpage
Click on Compositions and select Elements Composition and Hero Composition
Alias: frontpage
Add a new group called Footer with the following properties:
Then click on Compositions and select Elements Composition, Hero Composition and Unique Selling Points Composition, click on Submit.
On the permissions tab check Allow at root and add Textpage to the Allowed child node types property.
Then go to the Content section and create a new Frontpage with the name Home and create some subpages.
The GraphQL endpoint accepts POST
requests with the content type application/json
, the body should be an object containing as a minimum a query
property, for example
Lets start with a basic query that fetches the name
, url
, and heroTitle
properties from the Frontpage.
Result:
Up until now, we have been working on a single Document Type. In most cases this is fine, but since we want to dynamically fetch content based on the URL we can use the content
field.
The content
field returns the Content interface type that contains the default fields. To allow us to query the fields on the derived types we can use fragments.
A fragment allows us to query data on the underlying concrete type.
This returns the following JSON:
The query is fetching the name
field which exists on the Content
interface, it also fetches the heroTitle
, heroSubtitle
and heroImage
on the Frontpage
type.
There is one problem with our query though. Try changing the url
argument to a subpage and see whats happening.
As you can see we don't get any data back for the hero fields, even though our Document Type has those fields. This is because we are telling GraphQL that we only want them on the Frontpage
type. You might be tempted to fix this by adding another fragment on the Textpage
type which would work, but remember we created a Document Type that only contains hero fields which we have added as a Composition to both the Frontpage
and Textpage
Document Types. We can change the ... on Frontpage
fragment to ... on HeroComposition
and we will now get the expected data back.
Now our query looks like this:
Since Nested Content is an interface named Element
we can query the fields by the specific type using fragments.
Now try to write a query that fetches the title
, text
, link
and image
fields for the Unique Selling Points property.
The only thing we are missing now to be able to render the complete page is the main navigation and the footer.
The main navigation is showing the children of the frontpage, we can fetch them with the following query:
The footer can be fetched using the following query:
We can even combine the two queries into a single query:
In the query above we are also using field aliases, this means that in the response data frontpage
will be named global
and children
will be named mainNavigation
.
You might have noticed that the url
argument is hardcoded in the query. This means that we will always get back the Content for that url. What we want is to pass the argument to the query dynamically.
We can do this by altering the query to include a variable instead of the hardcoded value, this can be done by replacing the argument with $url
and wrapping the query with query($url: String)
.
And then we pass the variable in a separate JSON property called variables
Now that we have all the individual parts we can combine it all into a single query that fetches all the data needed to display the pages on our site:
Variables:
The following changes have been released to all Heartcore sites.
With the grid property editor , it has been decided to hide related functionality in the backoffice for sites that are not using it yet. The modern alternative to Grid Editor is the Block Grid Editor. The migration between Grid and Block Grid won't be fully automated, so this decision was made to encourage use of the most future-proof Data Type.
Sites that already have Grid Data Types in use will continue to offer the full range of grid support. Grid content can also be imported from a zip package, which will also fully enable support for it across the environment.
The Content Management API now exposes additional configuration data about properties via the endpoints. This will allow you to do things like retrieve information about possible prevalues for a dropdown field or radio button list, for example.
Fixes for commonly-reported issues this month include:
The root endpoint of the management API now correctly returns links to other endpoints.
The API explorer in the backoffice is no longer prevented from returning responses from the management API due to a Cross-Origin Resource Sharing (CORS) error.
The alias for dev & staging environments should no longer point at the live content APIs.
The webhook log viewer will now correctly load information about attempted runs.
When previewing content in a multilingual setup, the preview window will no longer indefinitely hang until you save the selected variant.
The following changes have been released to all Heartcore sites.
For a long time, the only way to get redirect information from Heartcore was a single endpoint on the Delivery API. This endpoint returned paginated redirect information for all content items in the tree. If you needed to find the canonical URL for a given path, then this endpoint was your only option. You would need to find your path in the returned items - especially challenging if it was not on the first page of results!
In order to save you the trouble, a brand new endpoint has been added to the Delivery API. It allows you to fetch the canonical URL (and any other redirects) for a given path. For more information, check out the .
The following changes have been released to all Heartcore sites.
The Block Grid Editor from core Umbraco is now available in Heartcore. A modern alternative to the Grid Editor, this type is particularly useful for allowing content authors to build page-like structures.
Unlike the core CMS, Heartcore does not yet support custom stylesheets or views to control block appearance in the backoffice. This is on the roadmap and support will be added later in the year.
A lot of work has been put into increasing the performance of the backoffice in this release. Content authors can expect to see a speed improvement across the board to most backoffice operations.
Previously, deleting a content or media item that was linked to from another item may have resulted in broken links. Now, content authors will be warned when attempting to delete an item which other items are dependent upon. They are also informed which items linked to the deleted one, so that they can change those items if desired.
TinyMCE, the library underpinning the Rich Text Editor (RTE) in Heartcore has been upgraded. This includes a slew of bug fixes and a slick new appearance, but has also allowed us to include some frequently-requested enhancements. Both of these must be enabled in the Data Type before being available to content authors.
Text color - You may now select foreground and background colors for text.
Language selection - You may now choose a language for selected text from a dropdown menu. This will apply a lang
attribute to the underlying markup. Browsers and screen readers that parse the markup will then be able to make smarter decisions about how to present that content to end-users.
In this release we have upgraded a lot of the technologies upon which Heartcore depends, including the core CMS. This means there is huge number of fixes to defective behaviors that we cannot hope to cover entirely here.
Instead, here is a brief list of fixes to some of the most highly-reported issues:
Transferring content between environments should no longer fail if the content contains a URL picker that references another content item.
In a content item with list view enabled, ordering children by the "Is Published" column should correctly sort items.
The preview button should now correctly display for all content items that vary by culture.
Language content management endpoints should now return a 400 Bad Request or 415 Unsupported Media type, instead of a generic 500 error.
Sorting on an optional DateTime field using GraphQL should now return results after the first page.
The following changes have been released to all Heartcore sites.
With the core CMS adding webhook support, the same functionality has been adapted into Heartcore to use the same user interface. You will now get the same consistent editing experience in both Umbraco CMS and Umbraco Heartcore, and it also comes with new features.
You may now select multiple event types (for example, publish / unpublish) or content types for a webhook. No more needing to create dozens of hooks to achieve what can now be done with only one.
You may now specify custom HTTP headers to send to your endpoint whenever the webhook fires.
Aside from the interface, all other aspects of webhooks in Heartcore are unchanged. Webhooks are still fired from the delivery platform with the same IP address range, retry policy, and payload that you are used to.
For more information about webhook functionality, both new and old, check out the .
A recent roll-out has added additional firewall rules for all Heartcore services. While efforts have been made to tune these, there is always a small possibility of false positives. If you believe your legitimate traffic is affected, please raise a support ticket through the portal.
For the rest of this tutorial the GraphQL queries are written in plain text that can be executed with the .
Since the heroImage
is a Media picker we can pass arguments to the url
field telling the server to generate an url with the query string parameters.
See the for more information about how to get started with the Block Grid.
Title
title
Textstring
Use defaults
Text
text
Rich Text Editor
Use defaults
Image
image
Media Picker
Pick multiple items: not checked Pick only images: checked Disable folder select: checked
Show large image
showLargeImage
Checkbox
Use defaults
Image
image
Media Picker
Pick multiple items: not checked Pick only images: checked Disable folder select: checked
Title
title
Textstring
Use defaults
Text
text
Textarea
Use defaults
Link
link
Multi Url Picker
Max number of items: 1
Elements
elements
Nested Content
Document Types: Element Type: Text and image, Group: Content, Template: {{title}} Confirm Deletes: checked Show icons: checked Hide label: checked
Image
heroImage
Media Picker
Pick multiple items: not checked Pick only images: checked Disable folder select: checked
Title
heroTitle
Textstring
Use defaults
Subtitle
heroSubtitle
Textstring
Use defaults
Title
uniqueSellingPointsTitle
Textstring
Document Types: Use defaults
Unique Selling Points
uniqueSellingPoints
Nested Content
Document Types: Element Type: Unique Selling Point, Group: Content, Template: {{title}} Confirm Deletes: checked Show icons: not checked Hide label: checked
Title
footerTitle
Textstring
Use defaults
Links
footerLinks
Multi Url Picker
Use defaults