Skip to end of metadata
Go to start of metadata

There are many different data points that can be used within apps built on Mobsted. All of these data points are referenced using the #Hashtag# notation, which pulls in the needed data piece all parts of Mobsted platform, like from a local app's storage, from a session, from Mobsted backend or from an API operation.

Hashtags are used in elements' properties in Constructor (in most fields of most elements, for example input fields, actions, etc ), API Operations, API Providers, API Methods, Filters and when sending messages to application users.

Hashtags can be created manually or automatically via Hashtag generator function in Constructor.

1. How and Where its Engaged 

Every where you see the sign # - you can call the generator and find a piece of data you need.

2. Which Data Points are Available

Hashtag generator works for the below parts and functions of the platform:

  • Application

  • Backendname

  • Event

  • LastEvent (last event created on app user action)

  • Filter

  • Object

  • API Operation

  • Screen

  • System

  • Tenant

  • Variable

  • Lists of Tables (Custom Data Tables)

When entering Hashtags manually make sure the text contains no spaces otherwise they won't work.

Some hashtags work for app users or for platform users (admin part) only. Please, pay attention to relevant notes to the sections below.

3. Hashtags Usage Examples

User Interface

Hashtags are used to display, or execute upon, Object data  from a needed column. Here is a sample of simply displaying data:

Constructor View - #Object:Name#

Application User View - resulting data pulled from Object's column "Name"

API Providers

Hashtags are used to pass data into API call parameters, for example, #Backendname:city# in the sample below:

This sample is taken from another article - Using API calls.

Sending personalized messages to app users:

This is a sample of messaging block of the platform.

Custom JS

Hashtags are used to pass data into Custom JS code, for example to call a native Share link function, and track which objectID does most sharing you can add a hashtag into Custom JS, like in the sample below:

const share = function(){
title: '',
text: 'Check out the Mobsted platform',
url: '
.then(() => console.log('Successful share'))
.catch((error) => console.log('Error sharing', error));

if (navigator.share) {
document.getElementById("btnShare").onclick = share
} else {
document.getElementById("btnShare").onclick = () => alert('Sharing does not work');

In this case the #Object:objid# will be pulled in by the JS function.

4. Available System Wide Hashtags

We try to have this list up to date, however there is good chance there are more hashtag references available on the platform, as new ones are added often. 


  • #Tenant:Name# - tenant name

  • #Tenant:UserName# - name of tenant creator(Client) specified at registration

  • #Tenant:MobileNumber# - phone number of tenant creator(Client) specified at registration

  • #Tenant:Country# - country of tenant creator(Client) specified at registration

  • #Tenant:LastModified# - date of the last change made in the tennant

  • #Tenant:PrimaryEmail# - email of tenant creator(Client) specified at registration

  • #Tenant:CompanyName# - company name


  • #System:SentSMSCount# - number of SMS sent in the current tenant

  • #System:SentEmailCount# - number of Emails sent in the current tenant

  • #System:SentPushCount# - number of Push notifications sent in the current tenant.


  • #Application:id# - app unique identifier

  • #Application:Name# - app name when stored on a mobile device

  • #Application:DateCreate# - app creation date and time

  • #Application:ThumbImageUrl# - link to the image used as app icon

  • #Application:EmailPhone# - identification type: Email or Phone Number or empty if none of these specified

  • #Application:PIN# - if the PIN code is set to log in to app, can be 1=YES or 0=NO

  • #Application:CreateObjects# - auto-create object on accessing app, can be 1=YES or 0=NO

  • #Application:Everytime# - request to enter IP or PIN on user return after time out (Return visitor timeout security setting), can be 1=YES or 0=NO

  • #Application:EventNotify1# - type of initial notification: Email=Email, SMS=Text Message, Push=Push or Not Selected if not specified

  • #Application:EventNotify2# - type of second notification:

    Email=Email, SMS=Text Message, Push=Push or Not Selected if not specified

  • #Application:EventNotify3# - type of third notification: Email=Email, SMS=Text Message, Push=Push or Not Selected if not specified

  • #Application:DesktopName# - app name on Mobsted platform

  • #Application:IP# - access security configuration status IP address (used with parameters subnet mask 1 and 2), can be 1=set to on, 0=set to off.

  • #Application:Mask1# - subnet mask 1 (with IP address security setting enabled)

  • #Application:Mask2# - subnet mask 2 (with IP address security setting enabled)

  • #Application:return_visitor_timeout# - time period in seconds set before requesting PIN or IP address check with PIN or/and IP address security setting enabled.


  • #Screen:id# - screen unique ID

  • #Screen:Name# - screen name

  • #Screen:SortOrder# - sequential screen number created in Constructor

  • #Screen:DateCreate# - screen creation date

  • #Screen:LastModified# - the date of last change made to screen

  • #Screen:ishomescreen# - current screen is Home screen = true, not Home screen = false.

Screen hashtags will ONLY work for app users, in API operations called by app users and in filter results requested by app user. As these need screen context.


#Variable:myvar123# - value that is stored in any variable you create in the app, in this case - "myvar123" variable. For more information on Variables, please, refer to Variables article.

Variables ONLY exist in user's session. Which means passing variable in hashtag anywhere, like to API operations or Filters, must be done from the app's user perspective. In case you need that data somewhere on a backend, you must use intermediary to store user's variables, like Lists of Tables.


This is very similar to variables, but allow to ID data from a particular element, like a button or select or text input.

  • #Backendname:name# - backendname set for Text input element to reference the data entered by app user

  • #Backendname:radio:label# - LABEL of the option in Radio Buttons element selected by user ("radio" is the Backendname of Radio Buttons element). Example: use #Backendname:radio1:label# to reference the second radio element label

  • #Backendname:radio:value# - VALUE of the option in Radio Buttons element selected by user ("radio" is the Backendname of Radio Buttons element). Example: use #Backendname:radio1:value# to reference the second radio element value


    • Use #Backendname:PolicyAgreeCheckBox[0]:label# to reference the label of the first selected element

    • Use #Backendname:PolicyAgreeCheckBox[0]:value# to reference the value of the first selected element.


  • #Object:id# - object unique ID

  • #Object:PIN# - login PIN if PIN is set in user access settings

  • #Object:Phone# - object phone number

  • #Object:Email# - object email

  • #Object:CreateDate# - object creation date

  • #Object:LoginUrl# and #Object:InviteUrl# - personal short link to enter the app on behalf of the object. #Object:InviteUrl# is used for app distribution to new users

  • #Object:Enabled# - object Status, if 0 - the object will not be able to access the app (requires to make settings in Enabled column in Objects)

  • #Object:LastLogin# - last date the app was accessed by the object

  • #Object:InviteStatus# - status of an invite sent to the object

  • #Object:Timezone# - current time zone

  • #Object:AutomaticalTimezone# - set automatic time zone, can be ON=1 or OFF=0

  • #Object:LastModified# - last date when object's data was changed

  • #Object:anyColumnName# - reference to any custom column created in Objects

  • #Object:FacebookChannel# - FB bot enabled=1, not enabeld=0

  • #Object:TelegramChannel# - Telegram bot enabled=1, not enabled=0

  • #Object:ViberChannel# - Viber bot enabled=1, not enabled=0

  • #Object:VKChannel# - VK bot enabled=1, not enabled=0

  • #Object:NotifyPush# - Chrome push enabled =1, not enabled =0

  • #Object:NotifyEmail# - Email push enabled =1, not enabled =0

  • #Object:NotifySMS# - SMS push enabled =1, not enabled =0

  • #Object:anyColumnName123# - reference to any custom column created in Objects.


  • #ObjectsFilter:FilterName: FilterValue# - get data on Objects filter

  • #EventsFilter:FilterName: FilterValue# - get data on Events filter

Where FilterName is filter's unique name.

In the hashtags above FilterValue can have the following values:

  • Value - filter value

  • Count - number of records that apply to the filter

  • Data - all filter records

  • Value - value for aggregated data (record count, max, min value)set in filter

Filter hashtags can use Self modifiers:

  • SelfData

  • SelfValue

  • SelfCount

Self modifiers allows to set additional filtering conditions on specified Object parameters.

For example: #EventsFilter:FilterName:FilterValue:SelfData:id# will return records applicable to current Object only.

Object column referenced in Self modifier must contain data, otherwise the filter will not work.


Each filter can contain either AND or OR conditions. In order to merge OR and AND conditions use hashtags to one filter within the second filter.

Example: we created the filter that displays users with email on Mobsted OR Outlook domain, and who has US phone number.

Venn diagram demonstrating the logic of the filter on Mobsted PWA platform

  • First filter will contain the required Email condition, we will name it as "Email"

  • Second filter will contain the required Phone condition merged with the condition filtering Emails that falls into the first filter

#ServerSide:ObjectsFilter:Email:Data@join(",", "objects@Email")# - where "Email' is the first filter's name.

Object column for join action must contain some data, and not be empty. For example, you can use "objects@id" instead of "objects@Email" at the end of the hashtag or any other column which already participates in filtration.


Loops hashtags can be created only manually.

  • #ObjectsFilter:FilterName:Data# - creating loop which contains data based on Objects filter

  • #EventsFilter:FilterName:Data# - creating loop which contains data based on Events filter

  • #Operation:OperationName:Response:Result:0:response:holidays# - creating loop which contains data on API Operation (read more about API Operation hashtags in API operation section)

Example: creating a loop with Object filter reference.

Referencing Loops:

  • #Loop:LoopName:OperationParameterName# - referencing the repeated element of API Operation that is specified in LoopName

  • #Loop:LoopName:objects@Phone# - referencing Phone column of Objects based on filter that is set in LoopName.

Example: displaying Objects columns which fall under Filter condition.

Resulting in the following looped data:


Event hashtags are available in Triggers' operations only.

  • #Event: id# - Event id

  • #Event:Value:EventFiledName# - data from the specified field name in Event Value column

  • #Event:ActionName# - event action name.


LastEvent hashtag returns data from last event created on app user action.

LastEvent hashtags are available everywhere except Triggers' operation.

  • #LastEvent:id# - Last Event id

  • #LastEvent:Value:EventFiledName# - data from specified field in Event Value column

  • #LastEvent:ActionName# - Last Event action name.


  • #Operation:OperationName: Response:Code# - HTTP status code after executing the operation

  • #Operation:OperationName: Response:Result[0].value# - data received as response to the operation execution ([0] - this array contains the entire response to the API request. Nesting can be multi-level, nesting levels are separated by a dot OR semicolon

  • #Operation:OperationName: Error:Code# - HTTP status code (in case of error), after performing the operation

  • #Operation:OperationName: Error:Result[0].value# - data received as response to the failed operation execution ([0] - this array contains the entire response to the API request. Nesting can be multi-level, nesting levels are separated by a dot OR semicolon.

Where OperationName – operation name assigned in the list of operations upon creation.

Example: you can ran an operation to check weather in London and recieve the following data:

"meta": [],
"data": {
"Response": {
"Result": [{
"location": {
"name": "London",
"region": "City of London, Greater London",
"country": "United Kingdom",
"lat": 51.520000000000003,
"lon": -0.11,
"tz_id": "Europe\/London",
"localtime_epoch": 1555318097,
"localtime": "2019-04-15 9:48"
"current": {
"last_updated_epoch": 1555317913,
"last_updated": "2019-04-15 09:45",
"temp_c": 9,
"temp_f": 48.200000000000003,
"is_day": 1,
"wind_mph": 15,
"wind_kph": 24.100000000000001,
"wind_degree": 90,
"wind_dir": "E",
"pressure_mb": 1023,
}, 200, { ... }],
"Code": 200
"Error": {
"Result": [],
"Code": 0

Please Note:

  • you can refer to the element of the array by using [array element number]

  • use dots instead of colons to refer to a nested JSON element.

If you were to set up this hashtag in a weather in app, you can set up the following hashtag call in app to display : #Operation:weatherOperation:Response:Result[0]:current.temp_c#, where "current.temp_c" refers to the name of an array "current" (see ABOVE api response) and it's needed element - "temp_c".

To see which data points in API response you need to refer to, you can check the structure of the received data (after performing the operation) via Hashtag generator.

This check requires having the API method as already set in your INTEGRATION section of Mobsted. The Weather example API method is available by default.


The FULL general form of the hashtag to call on custom tables is the following:



"List" is the initiation line telling the system to look into lists of tables data.

"list_name" is the custom name you give to your custom list of tables

"table_name" is your custom name of the needed table within the list

"N" is the ID of the ROW within the table

"column_name" is the custom name of a column

The full form returns to the exact data cell. 

The List's hashtags can be used in it's partial form to pull in arrays of data from the table:

  • #List:list_name:table_name# - returns the table in full, and is often used with ONE column tables
  • #List:list_name:table_name:N# - returns the specified ROW from the table, with all the columns

You can also use a hashtag WITHIN a hashtag to make more dynamic data calls, as shown in the example below, taken from the Task Manager sample app (located in your account):

You can see that the hashtag used in the Constructor (marked Red)  of the app,  has this form (marked Green) - 

Now, look into this hashtag - #List:languages:translation:3:#Backendname:Language##, open the Lists of Tables (marked Red), click down to Languages > Translations. You can see that the first part (in bold) of the hashtag fully repeats the route to the table.

Now - look at the second part of the hashtag #List:languages:translation:3:#Backendname:Language## ( in bold again). Each row stores how each piece of text in app is in every language. Then a column is requested using another hashtag, from a backend element's name, where use sets his own language. Note that in this case you user a double ## at the end to "close" both hashtags, just as with spreadsheet formulas. 


Current page route (URL) will pull into the application any information located in the incoming/open/current URL. This is often used to pass data between applications without any complex integration.

  • #Route:fullPath# - absolute path

  • #Route:path# - relative path

  • #Route:query:appid# - application ID

  • #Route:query:screenid# - screen ID

  • #Route:query:os# - OS the application was launched on (iOS / Android). Will be detected automatically if not specified

  • #Route:query:objid# - current Object ID

  • #Route:query:ref# - referrer. Possible options:

    • ref=PWA - application was launched from Home Screen

    • ref=vcard - application was launched from Contacts

    • ref=sms

    • ref=email

  • #Route:query:Custom_Parameter# - custom parameters that can be passed from external systems. Example: #Route:query:paymentSuccess=1#, or #Route:query:utm_referer# to read off the "objectid" info sent from the Custom JS example in Section 3 above. 

Related articles

Related articles