Creating new Content Types¶

A new Content Type can be created either by sending a properly formatted POST request to the /api/v1/internal/contenttype endpoint or through the Content Modeler tool provided with the platform.

Creating new Content Types via API¶

The API endpoint /api/v1/internal/contenttype can be used to interact with Content Type Definitions inside the Content Repository. The endpoint documentation is provided in the API docs and describes the following actions:

Creating a new Content Type is simply a POST call with a payload similar to:

Content Type POST payload

    {
        "name": "blogposts",
        "label": "Blog Posts",
        "schemaDefinition": {
            "type": "object",
            "allOf": [
                {
                    "$ref": "#/components/schemas/AbstractContentTypeSchemaDefinition"
                },
                {
                    "type": "object",
                    "properties": {
                        "title": {
                            "type": "string"
                        },
                        "postContent": {
                            "type": "string"
                        }
                    }
                }
            ],
            "required": [
                "title",
                "postContent"
            ],
            "additionalProperties": false
        },
        "metaDefinition": {
            "propertiesConfig": {
                "title": {
                    "label": "Title",
                    "inputType": "text",
                    "unique": true
                },
                "postContent": {
                    "label": "Post content",
                    "inputType": "richtext",
                    "unique": false
                }
            },
            "order": [
                "title",
                "postContent"
            ]
        }
    }

name is the name of the Content Type and name of the endpoints that will be generated to handle requests with Content Objects of that type.

label is only for displaying the name correctly on the CMS panel.

The schemaDefinition part of the JSON payload is based on the bare JSON Schema and is fully compatible. It holds information about properties of the CT (in the properties key), its types and which properties are required (required key). It always should have "type": "object", as it is an object, and "additionalProperties": false to ensure that API users will not post garbage to the objects of this CTD. To ensure that all objects have id property CTD also should have information about the connection with AbstractContentTypeSchemaDefinition using:

"allOf": [
    {
        "$ref": "#/components/schemas/AbstractContentTypeSchemaDefinition"
    }
],

In the case of this example, it will add two properties, title and postContent which are both strings and required.

metaDefinition is used to tell CMS panel how to render a form for the Content Object, it holds information about the order of the properties (order key, which should contain all properties of the object), and about type and validation of the field. It also includes information on relations of the object with other Content Types.

In this case, Blog Post will have title property which will be unique and will render as text input in CMS panel and postContent which can be duplicated and will be presented as CKEditor input in CMS panel. First input in the form in CMS panel will be title input, and second will be postContent.

Full curl request:

curl -X POST "https://api.flotiq.com/api/v1/internal/contenttype" -H 'accept: */*' -H 'X-AUTH-TOKEN: YOUR_API_KEY' -H 'Content-Type: application/json' --data-binary '{"name":"blogposts","label":"Blog Posts","schemaDefinition":{"type":"object","allOf":[{"$ref":"#/components/schemas/AbstractContentTypeSchemaDefinition"},{"type":"object","properties":{"title":{"type":"string"},"postContent":{"type":"string"}}}],"required":["title","postContent"],"additionalProperties":false},"metaDefinition":{"propertiesConfig":{"title":{"label":"Title",inputType":"text","unique":true},"postContent":{"label":"Post content","inputType":"richtext","unique":false}},"order":["title","postContent"]}}'

After such call is made and Content Type is created - the User API is immediately extended to support interaction with this new Content Type:

All Content Types have automatically added properties from AbstractContentTypeSchemaDefinition; they are:

id - string identifier of Content Object, required in all requests, unique within the Content Type,
internal - object necessary to proper work of CMS backend (information about dates of creation and update, the whole object is described in JSON below).

Schema of Abstract Content Type

    "AbstractContentTypeSchemaDefinition": {
        "type": "object",
        "properties": {
            "id": {
                "type": "string"
            },
            "internal": {
                "type": "object",
                "additionalProperties": false,
                "required": [
                    "createdAt", "updatedAt", "deletedAt", "contentType"
                ],
                "properties": {
                    "contentType": {
                        "type": "string"
                    },
                    "createdAt": {
                        "type": "string"
                    },
                    "updatedAt": {
                        "type": "string"
                    },
                    "deletedAt": {
                        "type": "string"
                    }
                }
            }
        },
        "required": [
            "id"
        ]
    },

Property types¶

Property types (as of schemaDefinition properties), recognized by CMS panel:

Property types

type	Description	Additional keys in property	Description
string	Any string data that includes date and files	none allowed
number	Any number, integer, float and double	none allowed
boolean	Represents two values `true` and `false`. Note that truthy and falsy values such as "true", "", 0 or null are not considered boolean values.	none allowed
array	Used for lists or relations.	items	For relations: it has to be an object containing `{"$ref": "#/components/schemas/DataSource"}`, as the items of the array are objects described in DataSource schema. For list items: it should be a valid json schema following the same restrictions as wrapping schema
		minItems	`0` for a not required property, and `1` for required property
object	Used for geo point type	properties	must be `{"lat": {"type": "number"},"lon": {"type": "number"}}`
		additionalProperties	must be `false`
		type	must be `object`
		required	if the field is required it must be `["lat","lon"]`

Meta definition properties types¶

Input types in metaDefinition of properties:

Meta definition

inputType	Possible for schema type	Description	Additional keys in property	Description	Additional keys	Description
text	string	Renders text input in form	unique	*	none allowed
textarea	string	Renders textarea in form	unique	*	none allowed
richtext	string	Renders CKEditor in form	unique	*	none allowed
email	string	Renders email input in form	unique	*	none allowed
number	number	Renders number input in form, min is 0, max is MAX INT	unique	*	none allowed
radio	string	Renders radio input, options are taken from `options` property	unique	*, Can only be `false`	none allowed
			options	Array of string options possible for the radio input	none allowed
checkbox	boolean	Renders single checkbox input returning `true`/`false` value	unique	*, Can only be `false`	none allowed
select	string	Renders single item select input, options are taken from `options` property	unique	*	none allowed
			options	Array of string options possible for the select input	none allowed
object	array	Renders one or multiple forms for nested `meta definition` element	items	`Meta definition` for single list item	same as in wrapping meta definition (`order` and `propertiesConfig`)
datasource	array	Renders picker for choosing the objects of specified or any other Content Type, depending on `validation` property	unique	*	none allowed
			validation	Object contains restrictions for datasource	relationContenttype	Name of the Content Type to which relation should be restricted
					relationMultiple	Boolean value informing if the array should have only one ora can have more elements
geo	object	Renders two fields, one for the latitude, second for the longitude, saves it as an object	unique	*	none allowed

*Information if the value of the property should be unique in all object of the specified type.

Creating Content Types through the Content modeller¶

It is described in the public part of the documentation.

Last update: February 1, 2021

Creating new Content Types¶