With a wide variety of functionalities, Kinetise allows building your complete native apps from scratch in hours. Learn how to put together all the advanced and custom features you need, replacing the need for manual coding.
Learn how to put together functionalities with drag&drop interface.
Connecting to already existing backend? Adjust it’s RESTful API first.
Use the full power of KinetiseCMS and enhance it with WebHooks.
Below is a list of sample backend starter kits for you to deploy wherever you want.
Django
Starter
SDK
Build backend for your app.
PHP Starter
SDK
Build backend for your app.
WordPress
Plugin
Display your WordPress content in a mobile app.
Deploy
Cloud Code to Bluemix
Start with CMS Cloud Code template deployed to IBM Bluemix.
See our full glossary of widgets here: Glossary
Actions allow you to convert any action-enabled widget into a Button. Clicking a widget that has one of the following Actions defined will perform the described action:
Opens the specified URL in the app user's default web browser.
Returns the app user to the previously shown screen.
Updates the contents of the current screen, including the contents of any list or other dynamic widgets.
Opens the specified overlay.
Opens the app user's default SMS application, and creates a new message with the specified contact number and message.
Opens the app user's default email application, and creates a new message with the specified address and message.
Opens the app user's default phone application, and calls the specified contact number.
Adds the current details to the calendar.
Opens a fullscreen Map widget with the specified destination and routing options.
Switches between the currently-defined languages.
Increases the size of any Text widget that is affected by the text multiplier.
Decreases the size of any Text widget that is affected by the text multiplier.
Opens a file, such as a PDF, XML or JPG, from the specified URL. The file will be opened by the app user's default app for that file format.
Lets you store the content of a specific screen and/or widget on the app user's device so that it can be accessed when a data connection is unavailable.
Select the desired screen (and widget, if required) from the available drop-down menus, then click Add Resource. Add multiple resources to the list as required.
Opens the app user's default QR code scanning application.
Redirects the app user to the Splash screen.
Redirects the app user to the Main screen.
Opens the New Screen dialog, and creates a link to the new screen.
Some widgets, especially collection-type widgets, have additional settings that can be enabled or disabled using the Advanced Options settings:
For apps that connect to a webservice, you can display a error message if there is a problem downloading data.
If your list-based app cannot retrieve any relevant data (i.e there are no items in the feed that match the specified settings), then you can display a specific No Data item, rather than an error message.
With this option enabled, the List will display a spinning icon while it retrieves data.
The Basic App Settings, or BAS, lets you configure all the settings that apply to your complete app, such as the name, icon, and any auto-generated elements such as the Header or Auto Menu.
Click the Settings tab on the left edge of the Editor to display BAS.
The BAS screen is divided into the following tabs:
The App tab of the BAS lets you configure how the app will be displayed on the user's phone, as well as in the App Stores when the app is published. From here you can specify the following settings:
Enter a Name for your app. This name will be used on the user's phone and in the App Store, as well as on your Dashboard.
The Icon will be displayed on the user's phone menu when they install your app. Click Replace Icon to upload a new image from your computer.
This defines the application's language when submitting the app to App Stores. The default language is English.
You can create additional languages by choosing a language code from the Add Language dropdown menu, then clicking ADD. The specific language elements used in your app can be managed on the Dictionary tab of BAS.
Delete unwanted languages by clicking X on the desired language. You must have at least language specified for your app at all times.
Clicking the Publish Settings button will begin the publication process. Once the native versions of your app have been built, they are submitted to the appropriate app stores using the settings you have defined in BAS.
The Skin tab of the BAS lets you configure the default settings when creating new screens in your app. You can also apply the current skin settings to existing screens.
Lets you set the background color for all screens currently using the application skin. Click the color box to open the color picker.
Lets you define the background image for all screens currently using the application skin. Click Upload to add an image from your computer, or click Bank to access the Image Bank.
You can define which screens currently use the application skin by selecting them in the Screen List. Note: enabling the skin will remove any existing background settings for that screen.
The Header tab of the BAS lets you select which screens in your app will use the application Header. Any changes you make to the header on any screen are applied to all other screens with the header enabled. Use this to make a consistent look and feel throughout your app screens. The Header is a separate item listed in the Tree.
A global setting that enables or disables the Automated Header. When disabling this setting, you are given two choices:
When enabling the Header Template, no screen will currently use the Header Template. You must then select each screen that should use the Header template.
Selecting a screen in this list creates a Header container on the screen based on the current Header Template. This replaces any existing Header on the screen. When deselecting a screen from this list, you can choose to disable the Header so that it no longer updates automatically, or to remove the Header container completely.
Lets you add a back button to the header of the selected screen. Use this feature for child screens, especially Detail screens
The Auto menu tab of the BAS lets you select which screens in your app will use the Automated Menu. The Auto Menu creates a series of buttons, giving you quick access to the key screens in your app. These buttons can be displayed as either a row at the base of each screen, or as an Overlay. The Auto Menu is a separate item listed in the Tree.
A global setting that specifies how the Auto Menu appears; in the Screen Footer and/or as a screen Overlay.
When disabling this setting, you are given two choices:
When enabling the Auto Menu Template, no screen will currently use the Auto Menu. You must then select each screen that should use the Auto Menu from the screen list.
Selecting a screen in this list creates a Auto Menu container on the screen. This replaces any existing Auto Menu on the screen that may have been created previously. When deselecting a screen from this list, you can choose to disable the Auto Menu so that it no longer updates automatically, or to remove the Auto Menu container completely.
Lets you add a button to the Auto Menu that links to the selected screen. Deselecting a screen will remove that screen's button from all screens with Auto Menu enabled.
The Dictionary tab of the BAS lets you specify language labels for popups in your app. This allows you to display, among others, local dates in the Date widget, custom messages for Login widgets, and specialized notices when posting to Facebook.
Displays the current application language. You can change this language and add new ones on the App tab.
Saves any changes you have made to the current Dictionary entries. This is only enabled once you have made a change.
Cancels any changes you have made to the current Dictionary entries, restoring the Dictionary to its previous state. This is only enabled once you have made a change.
The External Service tab of the BAS lets you configure connections and keys for all external integrations app is using. From here you can setup:
The Browser widget opens a dedicated web browser within the application, allowing the app user to access internet pages. This browser is independent to the phone's default browser application.
To display a web page, simply enter its address in the URL field and click OK.
The URL does not need to contain http:// or www.
When working on your application you can choose to Build it and have it available for testing or production use at any time. To do so, click the Build button on the Toolbar.
The popup contains three options:
The Checkbox widget is a type of Form Widget. It provides a simple On/Off option to your forms. Depending on the statement written in the Label, app users can tap the image to agree or disagree, select or deselect, and opt in or out of an app feature.
The Label field displays a message next to the Checkbox Image. You can customize this message by changing the contents of the Label field. Your message can contain up to 5000 characters.
The Init value sets the default value for the checkbox: true (ticked) or false (unticked).
The Checkbox Label options determine how the widget text is displayed on screen. The following options are available:
Like any button, the Checkbox image consists of two parts: an image and an active image. The image represents the default state of the button (unselected), while the active image displays when that particular choice is selected.
You can change these images at any time. Click Replace to upload an image from your computer, or Bank to choose an image from the Kinetise Image Bank.
The Cloud is a window on the right side of the Kinetise Editor. It allows you to configure the Settings and Common Settings for the currently selected widget.
The Cloud is divided into two screens; Settings and Common. You can switch between these screens by clicking the tabs at the top of the Cloud.
The Settings tab will display the unique settings for the currently selected widget. The options available depend on what kind of widget is selected: a Text widget will have different settings to an Image widget. For a more detailed explanation of each setting, see the Settings chapter for each widget.
The Common tab will display those settings that are common to all widgets; these settings primarily control the look and feel of the widget. Click here for more info on the Common settings.
The Code Scanner widget is a type of Form Widget. It lets the app user scan a QR code using their phone's camera.
Like any button, the Code Scanner button consists of two parts: an image and an active image. The image represents the default state of the button (unselected), while the active image displays when that particular choice is selected.
You can change these images at any time. Click Replace to upload an image from your computer, or Bank to choose an image from the Kinetise Image Bank.
The Color Picker lets you choose a custom color for your screen elements. These can include backgrounds and borders for Widgets, as well as backgrounds for Screens.
A: Color field B: Color slider C: Adjusted color D: Original color E: Color values F: Color palette G: Add to palette button
You can select any color from the Color field, and change the colors displayed in the field by using the color slider. Clicking on a color will display it on the Adjusted color box, alongside the Original color, and will immediately change the color of the current screen element. The RGB, hex and HSB settings for the current color will also show in the color value boxes. If you wish to revert to the original color, simply click the Original color box.
If you know the RGB, hex or HSB values of a desired color, these can be entered manually in the appropriate fields.
The Common Settings are a list of customizable options for every Widget. They are accessed from the Common tab of the Cloud.
Common Settings can be pasted between widgets of different types using the Copy Settings function.
The height and width of each widget is customizable. When defining the size, you can choose from the following units:
The Alignment controls position the widget relative to the borders of the screen, or the borders of the Container widget they are placed inside. Because all widgets automatically align to the top of the screen, the vertical alignment controls are only available if the widget is placed inside a Vertical Container.
Each Widget can have a custom background. This can be a solid color, an image, or both.
You can upload images from your computer using the Upload button. Alternatively, choose an existing from the Image Bank.
Widgets can have a border. Border thickness is specified in KPX, and color is selected using the color picker.
Margins create space around your widget. This will move the selected widget away from the edges of the screen, and away from other screen elements.
You can individually specify the top, bottom, left and right margins for each widget. Margin size is set in KPX, and is 0 by default.
Padding creates space inside your widget. This will push the edges of your widget outwards, toward other screen elements.
You can individually specify the top, bottom, left and right paddings for each widget. Padding size is set in KPX, and is 0 by default.
Radiuses create rounded corners for your widget. Each corner can be individually rounded by specifying the radius of the rounded corner in KPX (0 by default).
If the widget has a Border, this will be rounded to follow the radius.
The List is a collection-type widget, meaning it displays collection of data retrieved from another source, such as a server or RSS feed.
The List Widget is broken down into three levels: the List widget, List Items, and child widgets inside each List Item (typically Text and Image widgets). These layers can be seen on the Tree.
There are also a wide variety of settings to control the Query settings, Cache policy and item templates.
The advanced attributes let you control how the widget sends and retrieves queries to the specified web service, and how to identify the resulting list items.
Click Edit to access the list query settings. In the new window you can specify POST and GET settings for parameters and headers within your list.
The Item Identifier lets you specify a unique ID for each item in the list. Select a node from the drop-down menu, and the content of that node will then serve as the unique ID for each item in the list.
Each List Item represents one unique entry in the retrieved list.
When you add a List widget to your app screen, you are able to edit the top List Item in the list. Any changes you make to this List Item are applied automatically to all other Items in the list.
You can control the number of displayed items using the Count setting. The number of items specified will be automatically loaded.
To display additional items, click the Show More button.
Use Multi Item Templates to customize List Items individually, according to pre-defined rules. Use them to change the visual appearance of specific items, or to filter your list. Click here for more information.
The Cache Options determine how often the widget downloads data from the source, and whether to load data from the source or local cache.
The available methods are:
The Show More button will load further Items from the list, if available. These items are added to the bottom of the List widget, and the contents will automatically scroll down to display the newly-loaded content.
To enable or disable the on-screen Show More button, click the Show More checkbox:
Each List Item can be converted into a clickable button by selecting an Action from the dropdown menu:
A full description of the available Actions is available here.
You can enable the following Advanced options for the List widget:
The Date widget places a clock and calendar on the app screen. The widget can be configured to display either the time, the date, or both, in a variety of time/date formats.
You can choose between two sources for the current date and time; either the current time settings on the user's phone, or an internet time server provided by Kinetise. Click the desired icon to make your selection
A number of data and time formats are available for the Date widget. Simply click the drop-down menu and select the desired format.
Option |
Format |
Example |
hh:nn |
hour:minutes |
14:15 |
hh:nn:ss |
hour:minutes:seconds |
14:15:32 |
dddd, h:n:s |
day, hour:minutes:seconds |
Wednesday, 14:15:32 |
hh12:nn:ss AMPM |
hour:minutes:seconds AM or PM |
2:15:32 PM |
dd mmmm yy |
day month year |
31 December 2014 |
dd-mm-yyyy |
day-month-year |
31-12-2014 |
dd-mm-yyyy hh:nn:ss |
day-month-year hour:minutes:seconds |
31-12-2014 14:15:32 |
ddd dd mmm yyyy hh:nn:ss |
Day day month year hour:minutes:seconds |
Wed, 31 Dec 2014 14:15:32 |
Ticking determines whether the clock updates each second. To disable ticking, untick the checkbox (enabled by default).
The following options control the appearance of the Date widget contents:
The Date Picker widget is a type of Form Widget. It displays a native dialog allowing user to select date and/or time.
The Date Mode can be one of the following options: only date, only time, both date and time.
Depending on the mode, different picker dialog will be rendered.
Defines how chosen data/time will be presented on Date Picker widget after selection. A number of data and time formats are available. Simply click the drop-down menu and select the desired format.
Defines the oldest date/time than can be chosen in the date picker.
Defines the most recent date/time than can be chosen in the date picker.
The Watermark allows you to add a message to display in the Text Input before the app user adds any text.
The Text Properties determine how the widget text is displayed on screen. The following options are available:
Like any button, the Date Picker widget consists of two parts: an image and an active image. The image represents the default state of the button (unselected), while the active image displays when that particular choice is selected.
You can change these images at any time. Click Replace to upload an image from your computer, or Bank to choose an image from the Kinetise Image Bank.
Detail screens are Dynamic screens, which change their content based on their parent screen. Use them to display individual Items from a collection-type widget, such as the List or Map.
With a single Detail screen you can display the contents of each List Item. For more information, check out our Tutorials.
To create a Detail Screen, place a collection-type widget on a screen in your app. Select the widget, then select New Detail Screen from the Action menu.
Enter a name for your Detail screen, then click Add. Your Detail screen is now ready to use. Tap the List Item to display the Detail Screen.
The Drop Down widget is a type of Form Widget. It displays a selection of items in a list for the user to choose.
The Drop Down Items options in the widget settings allow you to add and edit the current menu choices. You can add as many choices as you need, but the list must always contain at least two options. To add another option, enter the option name into the Value box, then click Add.
Options can be deleted at any time by clicking the trashcan icon next to that option's name.
The Watermark allows you to add a message to display in the Text Input before the app user adds any text.
The Text Properties determine how the widget text is displayed on screen. The following options are available:
Like any button, the Drop Down widget consists of two parts: an image and an active image. The image represents the default state of the button (unselected), while the active image displays when that particular choice is selected.
You can change these images at any time. Click Replace to upload an image from your computer, or Bank to choose an image from the Kinetise Image Bank.
Collection-type widgets are powerful widgets which can serve structured data. This allows you to update the content of your app without having to publish your app again. There are four collection-type widgets in Kinetise: the List,Gallery,Video Channel and Map.
Collection-Type widgets can link to an RSS- or Atom-compatible feed, or an Alter API-compatible web service. From a valid web link, the Collection-Type widgets are able to retrieve text, pictures, content and metadata from the feed, and publish it inside the widget.
Collection-type widgets contain Items, which are containers containing other widgets. The first item can be edited, and these changes are applied to all subsequent items.
Multi Item Templates let you customize Items individually, according to pre-defined rules. Use them to change the visual appearance of specific items, or to filter your list. Multi Item Templates are only available for List Items.
The Form widget allows the app user to send information from the app back to the app creator. This can be sent either as an email or via the AlterAPI.
The Form widget is a type of Vertical Container. It holds a Text Input and the Send button. It can also hold additional widgets, especially other types of Form Widgets in order to make complex forms. Each widget inside the Form, including its unique ID, is listed in the settings.
The Send button is an integral part of the Form widget, and cannot be removed. It is an Image widget, and can be customized in the same way as any other Image widget.
When the app user taps the Send button, the app will transfer the contents of the Form Widget (and its child widgets) in one of two ways:
If you do not have an AlterAPI server set up, or it is not defined in the Basic App Settings, then select the email option. The contents of each form widget, as well as that widget's ID, will be sent to the specified email address.
If you have defined an AlterAPI server, then select the webservice option and enter the web address of the server in the appropriate field.
For more information on setting up an AlterAPI server, see the Backend Developers page.
The following widgets must be placed inside the Form Widget in order to work:
You can enable the following advancced options for the Form widget:
The Gallery is a collection-type widget, meaning it can display Images that it retrieves from another source, such as a server or RSS feed. It can display:
You can control the number of displayed items using the Count setting. The number of items specified will be automatically loaded.
To display additional items, click the Show More button.
The Show More button will load further Images, if available. These items are added to the bottom of the Gallery widget, and the contents will automatically scroll down to display the newly-loaded content.
To enable or disable the on-screen Show More button, click the Show More checkbox:
Tap to View will display Images as full-screen on the device, allowing the user to swipe left or right through the gallery.
The Cache Options determine how often the widget downloads data from the source, and whether to load data from the source or local cache.
The available methods are:
You can enable the following Additional attributes for the Gallery widget:
The Horizontal Container widget is a type of Container. It lets you place multiple Widgets in a horizontal row across the screen. To place widgets in vertical columns, you need a Vertical Container.
You can convert a Horizontal Container to a Vertical Container at any time using the Layout controls. Switching the layout will automatically realign any widgets inside the container.
You can divide the container at any time using the Split Container controls.
Note that splitting a Horizontal Container into columns will convert each container in Vertical containers. Similarly, splitting a Vertical Container into rows will convert each container in Horizontal containers.
The Image Bank provides instant access to a library of images for you to use in your application. Images are organized into categories, which you can select from the list on the left. Click an image in the Bank to select it. The image will display in the Preview window.
The Color Picker is built into the Image Bank, allowing you to set the color for the currently selected item. The Image Bank will always display the last-used colour when opening (black by default).
The Opacity slider is placed at the bottom of the Preview window, and allows you to set the transparency of the image. Set the slider to 0 to make the image invisible, or to 100 for solid color.
The Image widget lets you display images on the screen. You can display either Static images, from your hard drive or the Image Bank, orDynamic images which are retrieved from an online source. To enable Dynamic mode, place the image widget inside the item-template of a feed-type widget, or on a detail screen.
You can turn Text widgets into clickable objects (i.e. buttons), by selecting an Action from the dropdown menu:
A full description of the available Actions is available here.
You can add text labels to display on top of your image. To enable labels, tick the Text on Image checkbox.
Welcome to the Kinetise Editor! From here you have access to all the tools you need to build great apps.
Click an item below for more information:
The Login widgets allow your users to log in to the app, and therefore receive personalized content. Login widgets must be placed on the Splash Screen.
To log a user out of the app, use a Log Out widget.
For more detailed information on User Authentication, refer to the Backend Developers documentation.
There are four types of Login widget available:
The Login via Facebook widget provides user authentication using Facebook Connect. When a user successfully logs in, the webservice returns an access token to the app. This access token can then be used by the backend to identify the user for other services, such as Form submission.
The Login via LinkedIn widget provides user authentication using Sign In with LinkedIn. When a user successfully logs in, the webservice returns an access token to the app. This access token can then be used by the backend to identify the user for other services, such as Form submission.
The Login via Salesforce widget provides user authentication using Sign In with Salesforce. When a user successfully logs in, the webservice returns an access token to the app. This access token can then be used by the backend to identify the user for other services, such as Form submission.
If you have configured your own AlterAPI-compliant webservice, users can log in directly to your application. The widget is based on a Form widget, with pre-configured Text Input fields. Configure the widget by entering the URL of your own login service, and select the appropriate Password Hash type.
The Login via Basic Auth widget connects to an HTTP source, that is protected with Basic Access Authorization. This method can be used to restrict app access only to registered users, but will not affect any personalized connect as no AlterAPI session ID is used. This login method cannot be offered if any other Login widget is used in the app.
Like any button, each Login widget consists of two parts: an image and an active image. The image represents the default state of the button (unselected), while the active image displays when that particular choice is selected.
You can change these images at any time. Click Replace to upload an image from your computer, or Bank to choose an image from the Kinetise Image Bank.
You can enable the following Additional attributes for the Login widget:
The Log Out widget does exactly what it says; it logs out a user from the application. Depending on the type of Log In widget used, the widget will send a logout request to the appropriate webservice, and end the user’s current session.
For more detailed information on User Authentication, refer to the Backend Developers documentation.
Like any button, the Logout widget consists of two parts: an strong>image and an active image. The image represents the default state of the button (unselected), while the active image displays when that particular choice is selected.
You can change these images at any time. Click Replace to upload an image from your computer, or Bank to choose an image from the Kinetise Image Bank.
The Map displays a Google Map on the app screen. This map includes all the standard Google Map features including Zoom control, StreetView and Map or Satellite views. The Map is a colletion-type widget, and can display data from an online source inside the Map Popup.
You can add locations to display on your map. Each location will be shown with an Icon, and can display additional information such as a name and description using a Popup.
Locations can be added in three ways:
Icons represent locations on your Map. To add an icon, upload an image from your hard drive or theImage Bank, then enter an icon name and click Add.
In order to use Google Maps within your app, two API keys must be added to the widget. These API keys are free to use, but require you to register with Google . Full guides on obtaining Google Maps API keys are available here:
The Map Popup is a Container that can display any number of child widgets on top of the Map widget. By default the Popup contains Image and Text widgets to display the title and description for each Location, as well as a Close button. All existing widgets inside the Map Popup are customizable, and can be changed or removed if required.
The Cache Policy settings determine how often the widget downloads data from the source, and whether to load data from the source or local cache.
The available options are:
Overlays are screen layers that sit on top of existing screens. Use them to create drop-down menus, pop-out screens or other animated layers on top of your current screen content. Overlays can be selected, modified and deleted using the Screen List on the right side of the Editor.
You can create a new overlay in two ways:
From here, you can configure the following options:
The Location determines which edge of the screen the overlay will align to. In case of animations, the overlay will also appear from that screen edge. If Top or Bottom are selected, the Overlay will also push the Header or NaviPanel respectively.
The Animation options let you configure how the Overlay appears on the screen. You can use one or all of the following animation options:
The Payment widget provides a payment option to your app by linking to a payment webservice. Once the webservice has processed the app user’s payment, it will send a Success or Failure response to your app.
Depending on the response from the payment webservice, the Redirections will load different screens in your app. Choose a Success and a Failure screen to display from the available menus.
Like any button, the Payment widget consists of two parts: an image and an active image. The image represents the default state of the button (unselected), while the active image displays when that particular choice is selected.
You can change these images at any time. Click Replace to upload an image from your computer, or Bank to choose an image from the Kinetise Image Bank.
You can enable the following Additional attributes for the Payment widget:
The Radio Group widget is a type of Form Widget. It lets the user choose one option from a list of available options. The number and name of these options, as well as their buttons, can be fully customized in the widget settings.
The Radio Buttons options in the widget settings allow you to add and edit the current radio button choices. You can add as many radio buttons as you need, but the list must always contain at least two options. To add another option, enter the option name into the Radio Button Label box, then click Add.
Options can be deleted at any time by clicking the trashcan icon next to that option's name.
The Radio Button Label options determine how the widget text is displayed on screen. The following options are available:
Like any button, the Radio Button image consists of two parts: an image and an active image. The image represents the default state of the button (unselected), while the active image displays when that particular choice is selected.
You can change these images at any time. Click Replace to upload an image from your computer, or Bank to choose an image from the Kinetise Image Bank.
Screens are the individual pages within your app. All your screens are shown in the Screen List on the left side of the Editor. Every app includes a Splash screen, which cannot be removed. You can also create Detail screens in order to display dynamic information from collection-type widgets. Use Buttons to navigate between your screens.
The following screen types are available:
The standard screen used when building your app. You must have at least one Screen in your app, and this is named Main Screen by default. The default blank screen is based on a Vertical Container, listed as Body in the Tree, and cannot be deleted.
The Splash screen is the first screen to display when the application loads, and cannot be removed. All Login widgets must be placed here. Click here for more information on configuring the Splash screen.
Detail screens are special screens that update their content based on list items. Click here for more information on configuring Detail screens.
Overlays are a type of animation that sit on top of an existing screen. Click here for more information on configuring overlays.
The Screen Properties allow you to configure the appearance and behaviour of your screens. Click the Pencil icon next to the screen name to display the Screen properties:
Defines the unique identity of the screen within your app. This ID is used whenever you create buttons or other links to your screen.
Defines the background of the screen (shown underneath the main screen Body). You can choose to display a solid color via the Color Picker, your own image or one from the Image Bank, or even a video background.
Selects whether the Header and NaviPanel are displayed on the current screen. You can configure the Header and NaviPanel via the Basic App Settings.
Timeout lets you redirect a page automatically after a certain time. Choose a duration and a target screen, and that screen will automatically display when the time has elapsed.
The Rotation option selects whether the screen will rotate depending on the orientation of the app-user's phone. Screens will rotate by default.
You can create new screens at any time by clicking Add Screen/Overlay. The New Screen dialog will display, where you can choose to create a new Screen, or a new Overlay for an existing screen.
When creating a new screen, you choose to to automatically include a number of Container widgets to the screen. Alternative layouts provide various configurations of containers to build common menu or screen layouts. For more layout options, choose a blank screen and then use the Layout widget to build complex screen layouts.
When creating a new screen you can configure the following options:
You can modify these options at any time via the Basic App Settings.
The Search widget is similar to Text Input Widget, but input entered is not used to submit Form, but to retrieve filtered results for any Collection-Type widget. Search widget must be matched with a single Collection-type Widget that will use entered phrase in its query for data.
Click SELECT WIDGET FOR SERACH RESULTS to configure details of search logic. Popup will appear that allows to choose:
The Watermark allows you to add a message to display in the Search before the app user adds any text.
The Text Properties determine how the widget text is displayed on screen. The following options are available:
The Share widget adds a button to the current app screen. Clicking the button will open a native sharing dialog where end-user selects application to be used for sharing. Application can share textual message (even URL) and/or an image.
The posted message (or URL) and image is customizable using the widget's Settings, inside Events tab.
In Events tab you can configure the sharing action. You can select which content (textual and/or image) will be shared. Text and Image are selected in the same manner as in any other widget and allow to use both static and dynamic value.
The Signature widget is a type of Form Widget. It allows user to draw a signature using his finger. Image that was drawn is submitted as a part of Form submission.
Width and color of stroke line appearing under the finger can be defined.
The Splash screen is the primary screen that displays when the user loads your app. Use it to display your logo, the App name and any login widgets, if required.
The Take Photo widget is a type ofForm Widget. It lets the app user take a photo using their phone's camera. Alternatively, it can allow the user to upload an image from the phone's memory. The user is presented with this choice when clicking the widget.
Like any button, the Take Photo button consists of two parts: an image and an active image. The image represents the default state of the button (unselected), while the active image displays when that particular choice is selected.
You can change these images at any time. Click Replace to upload an image from your computer, or Bank to choose an image from the Kinetise Image Bank.
The Text Input widget is a type of Form Widget. It lets the app user enter plain text into the form. You can configure the input to Single Line, Multi Line or Hidden Text. When choosing the Multi Line option, you can define how many lines of text can be entered, from 0 to 1000.
The Watermark allows you to add a message to display in the Text Input before the app user adds any text.
The Text Properties determine how the widget text is displayed on screen. The following options are available:
The text widget lets you display text on the screen. The widget can display either Static text, which you enter yourself, orDynamic text which is retrieved from an online source. To enable Dynamic mode, place the text widget inside the item-template of a collection-type widget, or on a detail screen.
You can turn Text widgets into clickable objects (i.e. links), by selecting an Action from the dropdown menu:
You can fix the size of your Text using the Text Size options. Alternatively, you can make the text resizeable for your app users by enabling the Text Multiplier.
To enable this feature, tick the Affected by Text Multiplier checkbox for each Text widget.
Next, add two on-screen buttons and set their actions to Increase Text and Decrease Text. Tapping these buttons will change the size off all Text widgets with Text Multiplier enabled.
The Thumbnail Container widget is a type of Container. It lets you place multiple Widgets in rows across the screen. The widget automatically adds extra rows to display all child widgets, based on container and screen size as well as screen rotation.
The Thumbnail widget can be created using either a Horizontal or Vertical Container.
You can convert a Horizontal or Vertical Container to Thumbnail container using the Thumbnail option in the Layout property. To enable this feature, first select an option in the Inner Align property.
The Tile Buttons are a quick access menu that allows you to clone Widgets, edit their common settings, or delete widgets from your app.
The Tile Buttons are shown automatically by moving your mouse over the top right corner of a widget. They can also be accessed by clicking a widget in the Tree, or at the bottom of the Settings tab in the Cloud.
The Clone button creates a copy of the currently selected widget. After clicking Clone, the Clone Widget will appear on the Toolbar. You can then drag copies of the original widget from there to your app screen.
Clicking Clone on a different widget will replace the contents of the Clone Widget.
Clicking Delete will permanently remove the current widget from your app. You can undo this action by clicking Undo on the Toolbar.
Clicking Settings displays the current widget's Settings tab in the Cloud.
The Toggle Button widget is a type of Form Widget. When the user switches the button, the button value is sent to the webservice specified in the widget's URL field. For information on setting up your own webservice, see the Backend Developers page.
The Label field displays a message next to the Checkbox Image. You can customize this message by changing the contents of the Label field. Your message can contain up to 5000 characters.
The Init value sets the default value for the checkbox: true (On) or false (Off).
The Toggle Button Label options determine how the widget text is displayed on screen. The following options are available:
Like any button, the Toggle Button image consists of two parts: an image and an active image. The image represents the default state of the button (unselected), while the active image displays when that particular choice is selected.
You can change these images at any time. Click Replace to upload an image from your computer, or Bank to choose an image from the Kinetise Image Bank.
You can enable the following advanced options for the Toggle widget:
The Toolbar forms the bottom part of the Kinetise Editor, and provides a variety of tools for you to start building your app screen.
The following widgets are currently available on the Toolbar. Click each widget for more info.
The Mode controls let you switch between editing and testing your app. Click Editor mode to make changes to your screens and widgets, or click Emulator mode to check how your app looks and feels from the user's perspective.
The Undo and Redo buttons are there in case you make mistakes or change your made when editing your application. Click Undo to roll back the last changes you made, then click Redo to reapply the last actions.
Only available for registered users
The Save button lets you save the current state of your app design. Your app will then be available in the Temporary Apps section of your Dashboard.
The Reload button will refresh the Kinetise Editor and all the contents of your app screens. This is useful when working with collection-type widgets or with Online content, as it allows you to refresh your content to make sure your latest changes work correctly.
Only available for registered users
When you're ready to compile native versions of your app, click Build. Kinetise will then prepare the native versions of your app from your single design. When ready, you'll be shown a QR code and a weblink so that you can download the app straight to your phone.
The Tree displays all elements currently placed on the Screen.
Widgets placed directly on the screen are listed inside the Body section of the Tree. Any Containers and their child widgets are then nested inside the Body section. Other sections include the Header and NaviPanel, if enabled on the screen.
The Tree allows you to see the structure of your screen, including any widgets that may not be visible on the screen itself. From here, you can use the Tile Buttons to select, clone or delete widgets.
The Vertical Container widget is a type of Container. It lets you place multiple Widgets in a vertical column across the screen. To place widgets in horizontal rows, you need a Horizontal Container.
You can convert a Vertical Container to a Horizontal Container at any time using the Layout controls. Switching the layout will automatically realign any widgets inside the container.
You can divide the container at any time using the Split Container controls.
Note that splitting a Vertical Container into rows will convert each container in Horizontal containers. Similarly, splitting a Horizontal Container into columns will convert each container in Vertical containers.
The Video widget lets you add videos to your app.
The Video widget is also an essential part of the Video Channel widget.
The Video widget lets you play videos using either Kinetise's Embedded player, or the host website's own External player.
The Embedded player places on-screen controls
The External player loads the video inside the web host's player, such as Youtube. The visible controls depend on which website is hosting the video.
You can configure videos to play automatically as soon as the app screen loads. To do so, select the Embedded player and tick the Autoplay checkbox.
Video Channel is a collection-type widget, meaning it can display Videos that it retrieves from another source. It can display a list of Online videos from a Youtube channel, or aDynamic list from an Alter API-compatible source. To enable Dynamic mode, place the image widget inside the item-template of a collection-type widget, or on a detail screen.
You can control the number of displayed items using the Count setting. The number of items specified will be automatically loaded.
To display additional items, click the Show More button.
The Show More button will load further Videos from the video channel, if available. These items are added to the bottom of the Video Channel widget, and the contents will automatically scroll down to display the newly-loaded content.
To enable or disable the on-screen Show More button, click the Show More checkbox:
The Cache Options determine how often the widget downloads data from the source, and whether to load data from the source or local cache.
The available methods are:
You can enable the following Additional attributes for the Map widget:
Kinetise CMS (Content Management System) is a feature allowing to quickly setup and manage data for a mobile application built in Kinetise. Kinetise CMS allows to manage app users and any number of custom data tables which apps can read and write to. In Kinetise CMS you can use Standard endpoints to access and modify data from Kinetised application. Besides that, Kinetise CMS allows more advanced use cases as possibility to Import CSV files, define Custom endpoints, setup Cloud code and access CMS API.
Standard endpoints are automatically generated by Kinetise CMS for each data table and can be instantly used in Kinetise. Beside default functionality, standard endpoints provide a wide range of additional functionalities. This document describes these features.
The URL to get a feed endpoint uses the following structure: https://api-cms.kinetise.com/api/kinetise/v2/projects/{projectId}/tables/{tableId}/rows/get-table.
By default, it returns all records from the table in the same order as they are visible in CMS GUI.
Parameter name | Parameter type | Description | ||||||||
---|---|---|---|---|---|---|---|---|---|---|
<exact_column_name> | Params |
Filter rows by exact column value. Only these rows will be retrieved of which <exact_column_name> matches parameter value.
Example:
Let’s assume we have a
To download only items from the
|
||||||||
_sort | Params |
Sorts rows. The value of this parameter should be equal to the column name that sorting is based on. Let’s assume the following
To sort news by
It is possible to sort rows in descending order by prefixing the column name with a minus (-) character:
|
||||||||
_author | Params |
Filter rows to contain only entries created by the currently logged in user. Value of the parameter must be a current session ID value (selectable in Kinetise Editor from "dynamic params" list).
|
||||||||
_search | Params |
Filter rows to contain only entries for which any of the textual columns contains the search phrase provided as a value of the the parameter. Can be easily used with default settings of Search Widget.
|
||||||||
_dropdown | Params |
Serializes a relationship column to a Dropdown Widget-capable format. The value should be the name of the relationship-type column. Let’s assume we have the following tables: news :
news_dropdown :
If the related entries come from a table with
|
||||||||
pageSize pageStartID |
Params |
Returns a subset (page) of rows. Use to achieve data pagination.
Let’s assume the following call was made:
This would download a maximum of 10 entries with IDs greater than 50. |
The URL to create row endpoint resembles the following: https://api-cms.kinetise.com/api/kinetise/v2/projects/{projectId}/tables/{tableId}/rows/create-row. Since it is used with a POST request, it can accept both query parameters and so-called body parameters, which are attached to the POST body.
Parameter name | Parameter type | Description |
---|---|---|
<exact_column_name> latitude longitude |
Body |
Each entry in the request Body will insert or update a value in the matching column. By default, request body contains values from all Form-type Widgets with keys (column names) equal to Form ID set in Kinetise Editor. It is possible to add more entries to the Body params to pass additional (not Form-originated) information.
|
<sessionId> | Params |
Sets a row’s author (created by) field to the currently logged in Kinetise user. Value of the parameter must be a current session ID value (selectable in Kinetise Editor from "dynamic params" list).
|
The URL to get feed endpoint resembles the following: https://api-cms.kinetise.com/api/kinetise/v2/projects/{projectId}/users/get-users.
Parameter name | Parameter type | Description |
---|---|---|
pageSize pageStartID |
Params |
Returns a subset (page) of rows. Works same as for General Tables Get Feed endpoint. |
sessionId | Params |
Download details of the currently logged-in user. Value of the parameter must be a current session ID value (selectable in Kinetise Editor from "dynamic params" list).
|
Kinetise CMS can import CSV files in a special format. It describes not only data, but also data structure. CSV exported from an empty table can be used as a reference.
To be imported into Kinetise CMS CSV file has to:
;
character as a delimiter. Currently we don’t support other delimiters.0
if none),0
if required or 1
if not).text
- simple string.number
- simple string.boolean
- either 0
string (false) or 1
string (true).datetime
- has to be in yyyy-MM-dd hh:mm:ss
format (GMT timezone). (Default value for date columns is specified in RFC 822 format).image
- is a Base64 encoded image.relation
- is in ${tableName} ${relatedRowsArray}
format. Example: related [1,2,3]
.Custom endpoints allow to modify data structure before it is processed by Kinetise CMS endpoints. To understand how custom endpoints work you will need to have a little knowledge about how Kinetise exposes and receives data.
To use a custom endpoint you have to:
Kinetise uses JSON format to expose and receive data. You can use JQ format to define transformation to be applied over default JSON format generated by CMS.
For get-table
transformation is applied after endpoint returns its value. Assume that a get-table
endpoint returns following data:
{
"results": [{
"id": "2",
"title": "This is a basic list displaying texts and images.",
"description": "It contains data from the Kinetise backend\/CMS.",
"_created_ts": "2016-07-19T20:57:35+02:00",
"_updated_ts": "2016-07-19T20:57:35+02:00"
},
{
"id": "3",
"title": "To open CMS, click the CMS tab on the left of the screen.",
"description": "CMS is a powerful tool, but let\u0027s focus on getting data now.",
"_created_ts": "2016-07-19T20:57:35+02:00",
"_updated_ts": "2016-07-19T20:57:35+02:00"
}]
}
To count how many items are in this feed you could use transformation presented below:
{ "sample_items_count" : .results | length }
This transformation would be applied to an original feed. As a result following JSON would be returned to Kinetise:
{"sample_items_count":2}
create-row
transformation is applied before the data is put into an original endpoint. Assume that there is a list inside your form and Kinetise sends data in the following format:
{
"form": {
"list": [
{
"id": 1,
"selected": true
},
{
"id": 2,
"selected": false
},
{
"id": 3,
"selected": true
}
]
},
"params": {
}
}
Assume that you want to create a single new row with relationship column (called relation
) set to selected elements. For that task you could use following JQ transformation:
{
"form": {
"relation": (.form.list | map(select(.selected == true)) | map(.id))
},
"params": {
}
}
Applied to input JSON this transformation would produce following output:
{
"form": {
"relation": [
1,
3
]
},
"params": {
}
}
which is transferred to create-row
endpoint and correctly interpreted by Kinetise CMS as a relationship value.
Cloud Code enables developers to extend CMS functionality with arbitrary logic. It acts as a web-hook layer for all Kinetise endpoints.
Every time Kinetise CMS endpoint is called cloud code web-hook is invoked to either:
Examples:
For the rest of this document the first type will be referred to as hooks, while the second one as triggers.
Both web-hook types should handle POST
requests with following JSON body:
{
"projectGuid": "${projectIdentifier}",
"table": "${tableName}",
"originalRequest": {
"params": {
"${parameterOneName}": "${parameterOneValue}",
"${parameterTwoName}": "${parameterTwoValue}"
},
"headers": {
"${headerOneName}": "${headerOneValue}",
"${headerTwoName}": "${headerTwoValue}"
},
"body": {
"${firstBodyPropertyName}": "${firstBodyPropertyValue}",
"${secondBodyPropertyName}": "${secondBodyPropertyValue}"
}
},
"data": {
"columns": {
"${firstColumnName}": "${firstColumnType}",
"${secondColumnName}": "${secondColumnType}"
},
"rows": [
{
"${firstRowFirstColumnName}": "${firstRowFirstColumnValue}",
"${firstRowSecondColumnName}": "${firstRowSecondColumnValue}"
},
{
"${secondRowFirstColumnName}": "${secondRowFirstColumnValue}",
"${secondRowSecondColumnName}": "${secondRowSecondColumnValue}"
}
]
}
}
where:
projectGuid
describes project identifier,table
describes name of a table in behalf of which an endpoint was originally invoked,originalRequest
describes properties of a request send to Kinetise CMS:
parameters
is a dictionary of query parameters passed in request’s URL,headers
is a dictionary of headers passed in request,body
is a copy of body passed to a request (present only for POST
requests),data
describes rows and columns of originally requested data:
columns
contain pairs of column names and column types,rows
is an array with descriptions of every item connected to original request.2xx HTTP success status code should be returned to indicate that web-hook completed successfully. Any 4xx or 5xx HTTP error status code will make original Kinetise CMS fail.
In case of triggers request body is not checked. Any hook should respond with body in following format:
{
"columns": {
"${firstColumnName}": "${firstColumnType}",
"${secondColumnName}": "${secondColumnType}"
},
"rows": [
{
"${firstRowFirstColumnName}": "${firstRowFirstColumnValue}",
"${firstRowSecondColumnName}": "${firstRowSecondColumnValue}"
},
{
"${secondRowFirstColumnName}": "${secondRowFirstColumnValue}",
"${secondRowSecondColumnName}": "${secondRowSecondColumnValue}"
}
]
}
where:
columns
describes returned data scheme,rows
describes actual returned data.No. | Endpoint | Hook type | Description |
---|---|---|---|
1. | alterapi |
pre_register |
It is invoked before user registration is completed with AlterAPI form. It receives details of a freshly registered user and expects to get formatted data of this user back. |
2. | facebook |
pre_register |
It is invoked before first Facebook login for a user is completed. Works the same as the pre_register one for alterapi . |
3. | linkedin |
pre_register |
It is invoked before first LinkedIn login for a user is completed. Works the same as the pre_register one for alterapi . |
4. | get-users |
format_data |
It is invoked before data is converted to Kinetise format for get-users endpoint. It receives list of user details fetched from Kinetise CMS database and expects to get a formatted list of users back. |
No. | Endpoint | Hook type | Description |
---|---|---|---|
1. | get-table |
format_data |
It is invoked before data is converted to Kinetise format for get-table endpoint. It receives list of table rows fetched from Kinetise CMS database and expects to get a formatted list of rows back. |
2. | create-row |
pre_create |
It is invoked before data of a new entry is inserted into Kinetise CMS database in create-row endpoint. It receives list of table rows to insert and expects to get a formatted list of rows back. |
3. | update-row |
pre_update |
It is invoked before updated data of existing entry is inserted into Kinetise CMS database in update-row endpoint. It receives list of table rows to insert and expects to get a formatted list of rows back. |
No. | Endpoint | Hook type | Description |
---|---|---|---|
1. | alterapi |
post_login |
It is invoked after user has logged in using AlterAPI login. It receives details of a logged in user. |
2. | alterapi |
post_register |
It is invoked after user has registered using AlterAPI register endpoint. It receives details of a newly registered user. |
3. | alterapi |
post_logout |
It is invoked after user has logged out using AlterAPI logout endpoint. It receives details of a logged out user. |
4. | facebook |
post_login |
It is invoked after user has logged in using Facebook login. It receives details of a logged in user. |
5. | linkedin |
post_login |
It is invoked after user has logged in using LinkedIn login. It receives details of a logged in user. |
No. | Endpoint | Hook type | Description |
---|---|---|---|
1. | get-table |
data_requested |
It is invoked after data is requested for get-table endpoint. It receives list of table rows that were returned to a user. |
2. | create-row |
post_create |
It is invoked after data is inserted into Kinetise CMS database for create-row endpoint. It receives list of inserted table rows. |
3. | update-row |
post_update |
It is invoked after data is updated in Kinetise CMS database for update-row endpoint. It receives list of updated table rows. |
4. | delete-row |
post_delete |
It is invoked after data is deleted from Kinetise CMS database for delete-row endpoint. It receives list of removed table rows. |
In some scenarios the data received as an input for a web-hook might not be enough:
In such cases a web-hook can use CMS Developer API to fetch or alter data (or data scheme) for a project. CMS Developer API exposes a set of methods used by Kinetise CMS system in order to manage CMS project.
CMS Developer API is a set of RESTful services which allow to integrate with Kinetise CMS. It allows to perform per-project operations such as:
To use CMS Developer API you need to obtain two things:
To obtain a project identifier:
You can copy this identifier to clipboard using a copy button located next to the identifier.
Every call made to CMS Developer API has to provide a valid access_token
for a given project. To obtain such a token:
Token will be presented to you. Make sure to store this token securely, cause there is no way to retrieve it later.
Retrieved token has to be appended as an access_token
query parameter to every API call.
Example: assuming your generated token is equal to XYZ
a valid API call to get users list for project with abc
identifier would be:
https://api-cms.kinetise.com/api/kinetise/v1/projects/abc/users?access_token=XYZ
The API defines following entity types:
Every URL presented below follows four conventions:
https://api-cms.kinetise.com
.{apiVersion}
string which has to be replaced with an api version code. This reference describes API version 1. It is identified by v1
code.{projectIdentifier}
string which has to be replaced with project identifier. See section Project identifier for more details.It means that an API method referenced to as:
/api/kinetise/{apiVersion}/projects/{projectIdentifier}/users
for a project with identifier abc
secured by token XYZ
can be invoked like this:
https://api-cms.kinetise.com/api/kinetise/v1/projects/abc/users?access_token=XYZ
CMS Developer API is a REST API. All requests should contain Content-Type
header set to application/json
. Depending on a column type data should be sent in appropriate format:
No. | Column type | API data format | Example |
---|---|---|---|
1. | text |
JSON string | { "text": "Example text" } |
2. | float |
JSON decimal/float | { "float": 2.12 } |
3. | boolean |
JSON boolean | { "boolean": true } |
4. | datetime |
Date in RFC 3339 format as JSON string | { "date": "2016-02-10T12:24:30+01:00" } |
5. | image |
Base64 encoded image as JSON string | { "image": "iVB(...)5CYII=" } |
6. | relation |
JSON array of object IDs | { "relation": [ "1", "2" ] } |
CMS Developer API exposes a variety of column types to work with. Every column has following configuration options:
name
- a name of a column.type
- a type of a column.subtype
- specifies full column type together with type
(where applicable).default_value
- specifies a default value for a column (a format depends on a column type and is described in Data types section).is_required
- specifies whether a column value is mandatory when creating a row from Kinetise endpoint.related_table
- specifies an identifier of related table (if applicable). Example: { "related_table": "1" }
where 1 is table identifier (see id
field in Listing tables section).base_columns
- specifies an identifier of base columns for a column to work on (if applicable). Example: { "base_columns": ["1", "2"] }
where 1 and 2 are column identifiers (see id
field in Listing columns section).parameters
- specifies additional configuration parameters for a column (if applicable).Following column types are available:
No. | Column type | Description |
---|---|---|
1. | text |
Column of text type. Cannot have any of subtype , related_table , base_columns or parameters set. |
2. | float |
Column of a number type. Cannot have any of subtype , related_table , base_columns or parameters set. |
3. | boolean |
Column of a boolean type. Cannot have any of subtype , related_table , base_columns or parameters set. |
4. | datetime |
Column of a datetime type. Cannot have any of subtype , related_table , base_columns or parameters set. |
5. | image |
Column of a image type. Cannot have any of subtype , related_table , base_columns or parameters set. |
6. | relation |
Column of a relationship type. Have to have a single related_table defined. Cannot have any of subtype , base_columns or parameters set. |
7. | virtual |
Generic column type which represents a column that is not physically stored in Kinetise CMS. Cannot have related_table defined. Has to have subtype defined. May have base_columns and parameters defined. |
No. | Virtual column type | Description |
---|---|---|
1. | count_related |
Returns a count of elements in a relationship. Has to have exactly one base column defined (of relation type). Does not take any parameters. |
2. | get_first_related |
Includes values of all columns from a first related row to the parent row. All included columns are prefixed with virtual column name. Has to have exactly one base column defined (of relation type). Does not take any parameters. |
3. | get_last_related |
Works exactly like get_first_related , but takes last element instead of the first. |
4. | get_related_field |
Operates on a relationship. Returns a list of all values for a given column separated by comas. Has to have exactly one base column defined (of relation type). Takes a single parameter related_field which is a name of a column to join values from. |
5. | format_string |
Operates on one or more non-relationship, non-image type columns. Returns a text where all occurrences of {columnName} are replaced with {columnName} value. Has to have one or more base column defined. Takes a single parameter string_format with a format to return. |
GET /api/kinetise/{apiVersion}/projects/{projectIdentifier}/tables
API will respond with a list of all tables. Example:
[
{
"id": "1",
"name": "sample",
"tableGUID": "fdc445863226550411fdc2b5"
},
{
"id": "2",
"name": "sample_offline",
"tableGUID": "14174b163c7e4ef9586e6711"
}
]
where:
id
- is a table identifier,name
- is a table name,tableGUID
- is a deprecated table identifier string.POST /api/kinetise/{apiVersion}/projects/{projectIdentifier}/tables
The request should have a following body:
[
{
"name": "${newTableName}"
}
]
where ${newTableName}
is a name of a table to create. You can create multiple tables in single request. The API will respond with newly created tables’ data. Example:
[
{
"table_id": "4",
"tableGUID": "a35c084ef0fe052a92b165e5",
"name": "new_table"
}
]
where:
table_id
- is a table identifier,name
- is a table name,tableGUID
- is a deprecated table identifier string.PUT /api/kinetise/{apiVersion}/projects/{projectIdentifier}/tables/{tableIdentifier}
where {tableIdentifier}
is a table identifier that you can obtain from a table list (see id
field in Listing tables section). The request should have a following body:
{
"name": "${tableNameAfterRename}"
}
where ${tableNameAfterRename}
is a name of a table to rename it to. The API will respond with renamed table data. Example:
{
"table_id": "1",
"name": "renamed_table"
}
where:
table_id
- is a table identifier,name
- is a table name after rename.DELETE /api/kinetise/{apiVersion}/projects/{projectIdentifier}/tables/{tableIdentifier}
where {tableIdentifier}
is a table identifier that you can obtain from a table list (see id
field in Listing tables section).
The API will respond with an empty body:
{}
GET /api/kinetise/{apiVersion}/projects/{projectIdentifier}/tables/{tableIdentifier}/rows
where {tableIdentifier}
is a table identifier that you can obtain from a table list (see id
field in Listing tables section).
API will respond with a list of all table’s rows. Example:
[
{
"id": "1",
"title": "This is a basic list displaying texts and images.",
"description": "It contains data coming from Kinetise backend/CMS.",
"image": "https://api-cms.kinetise.com/api/kinetise/v1/projects/ae368da5aa29de5789bfcd24f89b657b/tables/1/columns/3/rows/2?ts=3d49698b3028ada0b540a02593a203f5",
"_created_ts": "2016-02-10T12:24:30+01:00",
"_updated_ts": "2016-02-10T12:24:30+01:00",
"_author_id": null,
"_author_username": null,
"_author_email": null,
"_author_role_name": null,
"_author_first_name": null,
"_author_last_name": null,
"_author_picture": null
},
{
"id": "2",
"title": "To open CMS, click pink DATA tab on the left of the screen.",
"description": "CMS is a powerful tool, but let's focus on getting data now.",
"image": "https://api-cms.kinetise.com/api/kinetise/v1/projects/ae368da5aa29de5789bfcd24f89b657b/tables/1/columns/3/rows/3?ts=3d49698b3028ada0b540a02593a203f5",
"_created_ts": "2016-02-10T12:24:30+01:00",
"_updated_ts": "2016-02-10T12:24:30+01:00",
"_author_id": null,
"_author_username": null,
"_author_email": null,
"_author_role_name": null,
"_author_first_name": null,
"_author_last_name": null,
"_author_picture": null
}
]
where:
id
- is an identifier of a row,_created_ts
- is a timestamp of record creation in RFC 3339 format,_update_ts
- is a timestamp of last record update in RFC 3339 format,_author_${property}
- describes a creator of the row (if the row was created from Kinetise app),POST /api/kinetise/{apiVersion}/projects/{projectIdentifier}/tables/{tableIdentifier}/rows
where {tableIdentifier}
is a table identifier that you can obtain from a table list (see id
field in Listing tables section).
The request body should describe inserted data. Every key should be a name of existing data column. Every value should be value for this column. Value format depends on column type and is described in Data types section. Example request:
{
"title": "New row title",
"description": "New row description"
}
The API will respond with newly created row’s data. Example:
{
"id": "8",
"title": "New row title",
"description": "New row description",
"image": null,
"_created_ts": "2016-02-10T13:55:43+01:00",
"_updated_ts": "2016-02-10T13:55:43+01:00",
"_author_id": null,
"_author_username": null,
"_author_email": null,
"_author_role_name": null,
"_author_first_name": null,
"_author_last_name": null,
"_author_picture": null
}
where:
id
- is an identifier of a row,_created_ts
- is a timestamp of record creation in RFC 3339 format,_update_ts
- is a timestamp of last record update in RFC 3339 format,_author_${property}
- describes a creator of the row (if the row was created from Kinetise app),PUT /api/kinetise/{apiVersion}/projects/{projectIdentifier}/tables/{tableIdentifier}/rows/{rowIdentifier}
where:
{tableIdentifier}
is a table identifier that you can obtain from a table list (see id
field in Listing tables section),{rowIdentifier} is a data row identifier that you can obtain from a row list (see
id` field in Listing data rows section).The request body should describe inserted data. Every key should be a name of existing data column. Every value should be value for this column. Value format depends on column type and is described in Data types section. Example request:
{
"title": "Updated row title"
}
The API will respond with freshly updated row’s data. Example:
{
"id": "1",
"title": "Updated row title",
"description": "Not updated row description",
"image": null,
"_created_ts": "2016-02-10T13:55:43+01:00",
"_updated_ts": "2016-02-10T13:55:43+01:00",
"_author_id": null,
"_author_username": null,
"_author_email": null,
"_author_role_name": null,
"_author_first_name": null,
"_author_last_name": null,
"_author_picture": null
}
where:
id
- is an identifier of a row,_created_ts
- is a timestamp of record creation in RFC 3339 format,_update_ts
- is a timestamp of last record update in RFC 3339 format,_author_${property}
- describes a creator of the row (if the row was created from Kinetise app),DELETE /api/kinetise/{apiVersion}/projects/{projectIdentifier}/tables/{tableIdentifier}/rows/{rowIdentifier}
where:
{tableIdentifier}
is a table identifier that you can obtain from a table list (see id
field in Listing tables section),{rowIdentifier} is a data row identifier that you can obtain from a row list (see
id` field in Listing data rows section).The API will respond with an empty body:
{}
POST /api/kinetise/{apiVersion}/projects/{projectIdentifier}/tables/{tableIdentifier}/rows/batch-delete
where {tableIdentifier}
is a table identifier that you can obtain from a table list (see id
field in Listing tables section).
The request body should contain row identifiers of rows to delete. You can obtain those identifiers from a row list (see id
field in Listing data rows section). Example request body to delete rows with identifiers of 3 and 4:
{
"ids": ["3", "4"]
}
The API will respond with an empty body:
{}
GET /api/kinetise/{apiVersion}/projects/{projectIdentifier}/tables/{tableIdentifier}/columns
where {tableIdentifier}
is a table identifier that you can obtain from a table list (see id
field in Listing tables section).
API will respond with a list of all table’s columns. Example:
[
{
"id": "1",
"table_id": "1",
"name": "title",
"type": "text",
"subtype": null,
"default_value": null,
"is_required": "0"
},
{
"id": "2",
"table_id": "1",
"name": "description",
"type": "text",
"subtype": null,
"default_value": null,
"is_required": "0"
},
{
"id": "3",
"table_id": "1",
"name": "image",
"type": "image",
"subtype": null,
"default_value": null,
"is_required": "0"
},
{
"id": "4",
"table_id": "1",
"name": "_created_ts",
"type": "datetime",
"subtype": null,
"default_value": null,
"is_required": "0"
},
{
"id": "5",
"table_id": "1",
"name": "_updated_ts",
"type": "datetime",
"subtype": null,
"default_value": null,
"is_required": "0"
}
]
where:
id
- identifier of a column,table_id
- identifier of a table containing this column (see id
field in Listing tables section),POST /api/kinetise/{apiVersion}/projects/{projectIdentifier}/tables/{tableIdentifier}/columns
where {tableIdentifier}
is a table identifier that you can obtain from a table list (see id
field in Listing tables section).
The request body should describe inserted column. Configuration is described in details in Columns’ Configuration Options section. Example request:
[
{
"table_id": "1",
"name": "new_text_column",
"type": "text",
"subtype": null,
"default_value": null,
"is_required": false
}
]
where:
table_id
- identifier of a table containing this column (see id
field in Listing tables section),name
- name of the new column,The API will respond with an empty body:
{}
PUT /api/kinetise/{apiVersion}/projects/{projectIdentifier}/tables/{tableIdentifier}/columns/{columnIdentifier}
where:
{tableIdentifier}
is a table identifier that you can obtain from a table list (see id
field in Listing tables section),{columnIdentifier}
is a column identifier that you can obtain from a column list (see id
field in Listing columns section).The request body should describe inserted column. Configuration is described in details in Columns’ Configuration Options section. Please note that not all column update operations are valid. We support only operations listed below:
is_required
property value,subtype
, base_columns
and parameters
.{
"name": "updated_column_name"
}
The API will respond with an empty body:
{}
DELETE /api/kinetise/{apiVersion}/projects/{projectIdentifier}/tables/{tableIdentifier}/columns/{columnIdentifier}
where:
{tableIdentifier}
is a table identifier that you can obtain from a table list (see id
field in Listing tables section),{columnIdentifier}
is a column identifier that you can obtain from a column list (see id
field in Listing columns section).The API will respond with an empty body:
{}
GET /api/kinetise/{apiVersion}/projects/{projectIdentifier}/users
The API will respond with a list of users. Example:
[
{
"id": "1",
"username": "kinetise_cms_user",
"email": "cmsuser@kinetise.com",
"created": "2016-02-11 11:13:38",
"first_seen": null,
"last_login": null,
"total_logins": "1",
"user_role": "USER",
"_is_deleted": false,
"devices": [],
"social": {
"Kinetise": {
"service_id": null,
"first_name": "Kinetise",
"last_name": "CMS User",
"country": null,
"city": "Warsaw",
"picture": null,
"profile_url": null
}
},
"first_name": "Kinetise",
"last_name": "CMS User",
"picture": null,
"city": "Warsaw",
"country": null
}
]
where:
* id
- user identifier.
* social
- describes social channel data for user. Currently three social sources are supported: Kinetise
, facebook
and linkedin
. Kinetise
is a CMS social entry, is initially populated with other sources (if possible) and always exists. facebook
and linkedin
socials exists only if user logged in with appropriate provider.
* devices
- stores info about mobile devices that user used to log in.
* Other fields are actual user data.
GET /api/kinetise/{apiVersion}/projects/{projectIdentifier}/users/{userIdentifier}
where {userIdentifier}
is a user identifier that you can obtain from a user list (see id
field in Listing users section).
The API will respond with single user data. Example:
{
"id": "1",
"username": "kinetise_cms_user",
"email": "cmsuser@kinetise.com",
"created": "2016-02-11 11:13:38",
"first_seen": null,
"last_login": null,
"total_logins": "1",
"user_role": "USER",
"_is_deleted": false,
"devices": [],
"social": {
"Kinetise": {
"service_id": null,
"first_name": "Kinetise",
"last_name": "CMS User",
"country": null,
"city": "Warsaw",
"picture": null,
"profile_url": null
}
},
"first_name": "Kinetise",
"last_name": "CMS User",
"picture": null,
"city": "Warsaw",
"country": null
}
where fields are exactly the same as described in Listing users section.
POST /api/kinetise/{apiVersion}/projects/{projectIdentifier}/users
The request body should describe user. Currently, we support following parameters:
username
- required field with username.password
- required field with password. It has to be pre-hashed with SHA1 algorithm.user_role
- identifier of a user role (see Listing user roles). If not present, default is set.first_name
- first name for Kinetise social channel.last_name
- last name for Kinetise social channel.city
- city for Kinetise social channel.Example request body:
{
"username": "new_user",
"password": "5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8",
"first_name": "New",
"second_name": "User"
}
The API will respond with created user details. Example API response:
{
"id": "2",
"username": "new_user",
"created": "2016-02-11 12:27:01",
"social": {
"Kinetise": {
"service_id": null,
"first_name": "New",
"last_name": null,
"country": null,
"city": null,
"picture": null,
"profile_url": null
}
}
}
PUT /api/kinetise/{apiVersion}/projects/{projectIdentifier}/users/{userIdentifier}
where {userIdentifier}
is a user identifier that you can obtain from a user list (see id
field in Listing users section).
The request body should describe user. Currently, we support updating following parameters:
username
- symbolic username.password
- user password. It has to be pre-hashed with SHA1 algorithm.user_role
- identifier of a user role (see Listing user roles).email
- e-mail address of a user.PUT /api/kinetise/{apiVersion}/projects/{projectIdentifier}/users/{userIdentifier}/add-info
where {userIdentifier}
is a user identifier that you can obtain from a user list (see id
field in Listing users section).
The request body should describe user social info. Currently, we support updating following parameters:
first_name
- user’s first name.last_name
- user’s last name.city
- user’s location.picture
- user’s picture. It has to be send as Base64 encoded image (see image
type under Data types).POST /api/kinetise/{apiVersion}/projects/{projectIdentifier}/users/delete
Request body have to specify a list of users to delete under ids
entry (see id
field under Listing users section). Example body:
{
"ids": ["2"]
}
The API will respond with an empty body:
{}
GET /api/kinetise/{apiVersion}/projects/{projectIdentifier}/users/roles
The API will respond with a list of user roles. Example:
[
{
"id": "1",
"name": "USER",
"description": "Default role",
"is_default": true
}
]
where:
id
- is a user role identifier,name
- is a name of a user role,description
- describes the role,is_default
- specifies whether the role is a default one. At one moment there has to be one and only one role that has is_default
set to true.POST /api/kinetise/{apiVersion}/projects/{projectIdentifier}/users/roles
Request body has to describe user role. Currently we support following settings:
name
- name of a role,description
- description of a role,is_default
- specifies whether the role is default. Important: if you create a default user role then all other roles will be marked non default.Example request:
{
"name": "NEW_USER_ROLE",
"description": "New user role",
"is_default": false
}
The API will respond with an empty body:
{}
POST /api/kinetise/{apiVersion}/projects/{projectIdentifier}/users/roles/{roleIdentifier}
where {roleIdentifier}
is an identifier of a role (see id
field in Listing user roles).
Request body has to describe user role. We support the same settings as for creating user roles (see Creating user role section). Important: updating a default role to a non-default will always fail (cause there will be no default role), while setting a role to be default will result in setting other roles to non-default.
Example request body:
{
"is_default": true
}
The API will respond with an empty body:
{}
POST /api/kinetise/{apiVersion}/projects/{projectIdentifier}/users/roles/delete
Request body have to specify a list of user roles to delete under ids
entry (see id
field under Listing user roles section). Example body:
{
"ids": ["2"]
}
The API will respond with an empty body:
{}
Important: deleting roles will fail if you try to delete a default role (there has to be a default role defined).
Users are a special case of data tables in Kinetise CMS. This module actually consists of a few data tables, but is presented as a single view.
The above fact has some implications in API. The most notable one is that custom user attributes are exposed as a data table with a special textual ID: _user_attributes
.
In order to work with user attributes you can use all the data rows & columns methods replacing {tableIdentifier}
with _user_attributes
. For example to list _user_attributes
for all users you would invoke:
GET /api/kinetise/{apiVersion}/projects/{projectIdentifier}/tables/_user_attributes/rows
The id
values for _user_attributes
always match id
values of users.