SMS section provides tools for sending messages, managing campaigns, analyzing delivery, and handling contact data.
¶ Overview
The module is structured into tabs for different messaging tasks.
- Send SMS
- SMS campaigns
- SMS report
- SMS inbox
- SMS templates
- Statistics
- Contacts
- HLR
¶ Send SMS
Used for sending single messages. Requires recipient, sender, and message content.
.png)
¶ SMS campaigns
Used for bulk messaging. Campaign defines message, recipients, and sending behavior.
1.png)
1.png)
¶ Campaign types
- Normal – sends messages once to all contacts in the selected group.
- Birthdays – runs every day at 10:30 (UTC) and sends a message only to contacts whose param_2 matches the current day. For birthday campaigns, param_2 must use mm-dd format.
- HLR – checks whether campaign contact numbers are reachable instead of sending SMS.
¶ Sending speed
Speed (SMS per minute) controls how fast the campaign is processed.
- allowed range: 1–255
- 0 = unlimited
The table below the speed field reflects campaign progress:
- Total – total number of contacts/messages in the campaign
- Sent – already processed messages
- Percentage – completion ratio of sent versus total
¶ Dynamic message content
Campaign text supports dynamic placeholders using contact fields.
Hello, {param_1} we wanted to remind you of the interest terms {param_2}. With regards, {param_3}.
When the campaign is sent, each placeholder is replaced using values stored in the selected contact group. This allows one campaign to generate personalized messages for multiple recipients.
Example:
- {param_1} → recipient name, for example John or Alex
- {param_2} → custom value, for example 2% or 5%
- {param_3} → company or sender name
¶ Message length and encoding
- Remaining – available characters in the current message part
- SMS count – number of message parts required
- Is unicode – indicates whether the message contains non-standard characters
Character limits (standard encoding):
- The first SMS part can contain up to 160 characters.
- If the message exceeds this limit, it is split into multiple parts.
- For the second part, 15 characters are reserved for concatenation data, leaving 145 characters available.
- For each additional part, 8 characters are reserved from the base limit, resulting in approximately 152 characters per part.
Character limits (Unicode encoding):
- If the message contains at least one character outside the standard GSM-7 set, the entire message is encoded in Unicode (UCS-2).
- This reduces the first part from 160 characters by 91 characters, leaving approximately 69 characters.
- When the message is split, the second part is reduced by 97 characters from the base limit.
- Each additional part is reduced by 94 characters from the standard 160-character limit.
This reduction is caused by encoding change and additional data required to combine message parts, which significantly increases the number of parts and total cost.
¶ SMS report
Provides message-level data including delivery status and cost.
1.png)
The table contains the following columns:
- Sent - date and time when the message was sent
- Received - date and time when the message was received
- From - sender ID or sending number
- To - recipient number
- Parts - number of SMS parts used
- Price - cost per SMS part
- Total - total cost of the message
- Status - delivery result
- Campaign - related campaign, if applicable
¶ SMS parts calculation
The Parts field shows how many SMS segments were used for a message.
- standard text → 160-145 characters per part
- unicode text → 69-63 characters per part
Each part is billed separately, so message length directly affects cost.
¶ Status meanings
- Queue – waiting to be sent to the SMS operator
- Enroute – sent to the operator, waiting for a response
- Delivered – delivered to the recipient
- Not sent – SMS was not sent, see error message
- Not delivered – SMS was sent but not delivered, see error message
- Rejected – SMS was not sent because it was rejected by system or operator
- Unknown – SMS status is unknown
¶ SMS inbox
Displays incoming messages and related metadata.
2.png)
¶ SMS forwarding
Incoming SMS messages can be automatically forwarded to external systems.
- Email – messages can be forwarded to a specified email address.
- Webhook – messages can be sent to a configured URL for further processing.
These options are configured in the Phone Numbers section, under the Options column.
This allows integrating SMS reception with external systems such as CRM, support tools, or custom APIs.
¶ Message preview
If the message text is too long to fit in the visible column, the info (i) icon can be used to view the full content.
¶ SMS templates
Templates allow reusing predefined message formats and ensure consistent communication.
1.png)
¶ Template configuration
- User – defines which account or user the template is sent from.
- Sender ID – specifies the sender name or number that will appear on the recipient’s device.
- Message – template text, which can include dynamic values (e.g. {param_1}).
¶ Statistics
Aggregated metrics for volume, delivery, and cost.
1.png)
¶ Status interpretation
- Queue – message not yet processed
- Enroute – message handed to operator, pending result
- Delivered – successfully received
- Not sent – blocked before sending
- Not delivered – delivery failed after sending
- Rejected – explicitly refused
- Unknown – status not returned
¶ Contacts
Manages recipient groups used in campaigns.
1.png)
Contacts can store custom fields param_1–param_5. These fields can later be used inside campaign messages as dynamic placeholders such as {param_1}, {param_2}, and so on.
3.png)
¶ Using contact parameters in campaigns
One contact group can contain multiple recipients with different parameter values. During campaign sending, each contact receives a message where placeholders are replaced with their own stored values.
Example campaign text:
Hello, {param_1} we wanted to remind you of the interest terms {param_2}. With regards, {param_3}.
This allows one campaign to generate personalized output per recipient.
¶ Blacklist
Blacklist contains numbers that must not receive messages. These contacts are excluded from campaigns and bulk messaging, for example after opt-out requests.
¶ Import contacts
Contacts can be added in two ways:
- Manual input – contacts can be entered directly in the text field, separated by commas.
- CSV import – contacts can be uploaded from a CSV file.
Delimiter defines how values are separated in the CSV file (for example comma or semicolon).
The delimiter can be changed directly in the import dialog, depending on the structure of the uploaded file.
2.png)
Supported CSV structure:
- phone_number
- param_1
- param_2
- param_3
- param_4
- param_5
¶ HLR
The HLR (Home Location Register) feature is used for phone number lookup, allowing verification of whether a number is valid and reachable.
Although located in the SMS section, HLR is not limited to SMS and is also used in call workflows.
HLR checks can be enabled for outgoing calls in Account Settings, where the system performs a lookup before initiating a call.
Note: HLR is a paid feature.
- 0.005 per request when performed via the HLR form
- 0.01 per call when used in call workflows
2.png)
¶ HLR lookup
HLR (Home Location Register) lookup is a number validation service used to retrieve information about a phone number. It is not limited to SMS and can also be used before placing outgoing calls.
HLR checks can be enabled in account settings for outgoing calls.
¶ Pricing
- 0.005 – per request via form
- 0.01 – per lookup when performed during a call
¶ HLR lookup result
The HLR form returns the result of the lookup request for the provided number.
- Number – the phone number that was checked
- Request – indicates whether the request was successfully processed (e.g. OK)
- Status – the result of the HLR lookup (e.g. REJECTED, DELIVERED, UNKNOWN)
The Request field reflects the API processing status, while the Status field represents the actual lookup result for the number.
¶ Response status codes
- 200 OK – request successfully processed
- 400 Bad Request – invalid request parameters
- 401 Unauthorized – authentication failed
- 403 Forbidden – access denied
- 404 Not Found – requested resource not found
- 429 Too Many Requests – rate limit exceeded
- 500 Internal Server Error – server error
These codes describe how the API handled the request, not the actual HLR lookup result.