Skip to content

SendMan Console

The SendMan Console is the primary user interface for working with SendMan.
The console exposes the high-level functionality of SendMan with an intuitive interface for developers and other users within your organization.


The main page of the console is the applications page , which includes all the applications you configure.

The first application, automatically added to every organization, is the "Demo App". The Demo App shows how a basic integration with our SDK will look — with examples of receiving notifications, automatic user tracking, and end-user management of notification preferences.

If you are creating your first app, please see some explanation regarding the required information in the 'Add Application' section.


From here on out, the following pages are all associated with managing a specific application. Any configuration you add will not affect other applications you have.


The templates page shows a list of all push notification templates.
For each template, the following fields are displayed:

  • UID - A unique, immutable ID set on creation.
    You should use this ID for addressing the template in all API calls.
  • Name - A human-friendly name given to the template.
  • Recurring - If this template is scheduled to be sent periodically, displays the interval (daily/hourly).
  • Category - The category this template is associated with.
    SendMan will send or block push notifications for a given template based on the end user's preference for the associated category.

Clicking on any row in the templates table will open the template details page.

Template Details

The template details page consists of several sections:

Template Configuration

Here you can see the following parameters for each template:

  • UID (required) - A unique, immutable ID set on creation. It is used for addressing the template in all API calls. This field should contain only numbers, letters, dashes or underscores.
  • Title (optional) - A string your end user will see as the push notification title.
  • Text (required) - A string your end user will see as the body of the push notification.
  • Sound (optional) - The name of a sound file to play when this notification is received. "default" plays the default sound selected by the user in the OS settings.


    The selected file name must be bundled with the app in order to function. If it isn't, the default sound is played.
  • Additional fields (optional) - A list of key/value fields to be added to the notification payload and sent to your app in the notification payload.
  • Category (optional) - The category this template is associated with.
    Selecting one will enable your users to choose whether to receive notifications of this template, via our native notifications management view (iOS / Android).
  • Recurring Notification (optional) - The configuration for scheduling this notification to be sent at certain intervals.
Param replacement

Your notification can include parameters, added by using a placeholder syntax.
An example syntax would be:
{{ "param name" | "default value" }} (the | "default value" may be omitted).

Parameters can be placed in the title, text, and additional fields.

When sending a notification, these params will be replaced by data in this order:

  1. The data from a dictionary supplied in the REST API call or via our console .
  2. The current user properties set from either the SDKs or our REST API.
  3. The default value.
  4. An empty string.

Send Notifications

Immediately send push notifications based on this template in one of two ways:

  • Using the dashboard, you can trigger push notifications of this template to a list of users selected by using our filters.
    For parameterized templates, you will also be able to set values for the parameters (which will otherwise adhere to the logic mentioned in the previous paragraph).
  • For your convenience, we've also included a cURL command that you can copy and run from the command line to test this template.

User Engagement

This section shows engagement data for notifications generated using this template, on a per-send level. Each time notifications are sent based on a template, using either the UI or via our REST API, an activity is created. Every activity is a row in the table.

Each row contains:

  • Time - The time at which this activity was submitted (either via the UI or via our REST API).
  • Audience - The number of users targeted by their IDs or by using filters.
  • Sent - The number of users to whom the notifications were sent. For instance, users who have opted out using the native notifications management view (iOS / Android) will not be counted in this group.
  • Engaged - The number of users that have engaged with the notification, either directly or indirectly — or had their app in the foreground while the notification was delivered to their device.
  • % Engaged - This shows a conversion bar for quickly viewing the statistics. The percentages show the number of engaged users, and the colored bar shows the conversion funnel (lightest is "Audience", darkest is "Engaged").

When expanding each activity row, some extra data regarding the activity is shown:

  • A table listing the audience and their current engagement status.
  • A pie chart breaking down the different engagement statuses of this notification activity.
    Clicking on any engagement slice will filter the users' table according to the selected engagement status and display only the relevant users for that status.


    The engagement status filter can be removed by clicking the "ALL USERS" button on the top right corner of a filtered pie chart.

  • In case filters were used in this activity, they will be shown above the audience table.

Possible engagement statuses are:

Status Description
  Queued for delivery This notification has been submitted and will be delivered to Apple Push Notification (APN) service / Firebase Cloud Messaging (FCM) for native delivery soon
  Sent This notification was sent using the native delivery services
  Engaged directly The user clicked on the notification and interacted with the app
  Engaged indirectly The user has interacted with the app within 1 hour of receiving the notification (but did not click on it)
  Received in foreground The user received the notification while using the app
  Pre request The user has not yet seen a push notification permission request (relevant for specific platforms)
  Opted out of category The user has turned off notifications for this category using our native notifications management view (iOS / Android)
  Blocked The user has disabled all push notifications for this app
  No token The native token for sending notifications to this device is missing (this will rarely happen due to network or similar issues, and should be fixed automatically when the user reopens the app)
  Platform not configured A notification was sent to a user using an app that integrated our SDK but the platform was not configured on our console (iOS / Android)
  Failed An unknown technical error prevents us from delivering this notification. This should not happen, and if it did — we're already on it 😇

Recurring Notifications

Recurring notifications are comprised of the following configurable attributes:

  • Interval - hourly or daily.
  • Start Time - The date and time these notifications should be sent for the first time.


    If the start time is in the past, it will only affect the time of day in which these notifications should be sent.
  • Timezone (daily interval only) - May be either the user's local time or UTC time.
    • If UTC is selected, all users will receive the notifications at the same, regardless of their local time.
    • If User Local Time is selected, the notifications will be sent at the selected time of day to each user according to their own tracked timezone (automatically tracked by SendMan).
  • Filters - The conditions used to determine which users should receive these notifications. These filters are evaluated each time these notifications are sent. In order to see the current users matching these filters you can use the audience page.

When editing templates, recurrence can be edited or removed. For changes to take effect, the template should be updated after clicking Save in the Schedule Template dialog (or Remove in the delete confirmation dialog).


The categories page shows a list of all the template categories defined for this app.
This view also describes the structure seen by end users when opening the native notifications management view in a mobile app integrating SendMan's SDK (iOS / Android).

Category Hierarchy

There are two types of category definitions:

  • Category - A collection of templates with a common name and description, which can be opted into and out of by the end users. They can optionally be nested in category groups.
  • Category Group - A list of categories, with additional descriptions. Groups are used to improve readability and to make managing notification preferences easier for the user. They cannot be opted into or out of.

Editing Categories

Categories Screen

Using the category screen, you can drag and drop categories within their parent Category Group, or switch between top-level Categories and Category Groups.


Changing a category from a non-nested category to a nested one (and vice versa) is only possible within the category "edit" mode.

Edit Category Screen

The edit screen is available by clicking the category in the categories screen.
In this screen you will be able to edit other elements of the category (while maintaining its underlying ID, used for stable identification of your end users' preferences):

  • Name (required) - The name of the category displayed to the user.
  • Description (optional) - Additional text displayed to the user within the native notifications management view.
  • Turned on by default - The opt-in state new users should have for this category. Once a user has seen this category within the native view, changing the default value will no longer affect that user's opt-in state.
  • Group (required) - The name of the category group in which this category should be nested. Can be None in order to place this category in the top-level.


A list of the end users tracked for this app.
This list can be filtered by user properties saved by the SDK (like the device platform) or by any custom property (iOS / Android).


A property can be either Boolean, numeric, or a string. The filter relation options will match the property type. If a certain property has been tracked with different value types, it will be treated as a string from that point onward.

In order to comply with General Data Protection Regulation (GDPR), on this screen you can choose to delete your users' information. Once it is done, SendMan no longer stores any of the previously saved data about the selected users.

Clicking a single user row will open an expandable information pane containing some high-level data about the user. For extended information, you can click "View user data".

User Data Screen

The user data screen consists of several sections:

High-level Data

This is data that is automatically collected by our SDK. It describes high-level properties of the users' device and app, such as its region, device details, and app-level push notifications state.

This section also includes the push notification token, which can be used for sending push notifications from sources external to the SendMan platform.
This section also contains a User Settings button, which opens the current state of the notification preferences as currently defined by the end-user on their app.


When developing or troubleshooting, it is worth noting that notification preferences are only saved when the notifications view is closed (or navigated away from) in the mobile app.

Custom Properties Table

Contains a list of all custom properties, including their name, current value, the time at which they were first set, and the last time they were changed.

Notification Activity

Contains a list of the notifications that were sent to this user.
It includes the name of the template used to generate this notification, the time at which it was sent, the current status, and some more elaborate explanation of the status (you should refer to the 'User Engagement' section for detailed explanation of the statuses).

Clicking the name of the template will open the template screen, while clicking the row will expand and show metadata about the notification, including the params that were replaced for the user according to the logic mentioned here.

Events Breakdown

This vertical timeline component shows the events reported by the SDK.
These are native events that are automatically reported, such as categories being opted into or out of, a click on a notification, etc. Events will sometimes include values (for instance, an event related to a template, will include the template name).

Events by Time

This graph component shows an aggregated view of user activity, useful for getting a sense of the user's behavior in the app over time.

API Keys

This screen contains two sets of keys, used for authenticating requests with our API.

App Keys

These keys are used for integrating the mobile SDKs within your apps. They authenticate the app sending the data and authorize tracking user data.


These keys are authorized to report data for any user of your app, but have no control over configuration or your end user's experience.
This means they are perfectly safe to bundle in your apps.

Backend Keys

These keys are used for calling our REST API. They authenticate the integrated app and authorize a more powerful interface than the app keys, allowing for sending notifications to users and managing different aspects of the configuration.


These keys are sensitive as they affect your end users. It is important to keep them safe, and expose them only through dedicated key stores in your backend (or via other secure means).
This means they should NEVER be published in the bundles of your apps.

Configuration / Add Application

This form is used to create and configure an application or to edit an existing one.
It allows editing your application name and setting the environment for which this app is used.

iOS-Specific Definitions

In order to send notifications using Apple Push Notification service (APN) you need to set several additional fields.
If this is your first time integrating push notifications, you can refer to this part of Ray Wenderlich 's push notification guide in order to learn how to create authentication keys for APN.
Make the .p8 you create is associated with "Apple Push Notifications service (APNs)", as this is required for SendMan to send notifications on your behalf.

Field Description
Bundle ID The bundle ID of your app, required for any app registered in Apple's Developer Portal .
APNs Key ID The key ID you created for push notifications in Apple's Developer Portal.
Apple Team ID The team identifier of your Apple developer account (either personal or organizational).
.p8 certificate The content of the private push notification key, used to identify with Apple's servers. This is securely stored on our servers, accessible only from our Virtual Private Cloud .


It is important to note that Apple isolates its testing environments from its production environments.
When selecting the app type in this form, make sure to select the correct environment.

Android-Specific Definitions

In order to send notifications using Firebase Messaging (FCM) you need to set several additional fields.
If this is your first time integrating push notifications, you can refer to this guide on our blog describing how to create a service account, used to authenticate our servers with FCM in order to deliver notifications to your users.

Field Description
FCM Database URL This is your project's identifier in Firebase. It may be used for several applications under the same account.
.json Service Account This is the content of the private push notification key, used to identify with Google's Firebase servers. This is securely stored on our servers, accessible only from our Virtual Private Cloud .