Cascading Message Sending

Cascading message sending is the sequential sending of a message via different channels over the message’s lifetime.

The message is resent in case of receiving a status indicating that the message was not successfully sent.

Cascading message sending is not available by default. To enable it, the Partner must contact their supervising manager.

The service supports the following types of cascading message:

• FlashingCall;

• Push;

• SMS;

• Viber;

• VK;

• WhatsApp.

When sending, it can be any sequence of message types.

The order and options for such resending can be configured on the Service Provider’s side at the request of the Partner. In this case this additional sending of messages performs with the default parameters, and no additional parameters need to be passed in the request body.

It is possible to pass the desired cascade options using additional parameters of the HTTP request.

Request Parameters

Possible parameters of the HTTP request for cascade message resending.

Parameter Name	Type	Description
order_list	string	Parameter that defines the sequence of message sending. More details Message types should be listed in the order they are to be sent. Possible values (case insensitive): s — SMS; p — Push; v — VK; i — Viber; w — WhatsApp; f — FlashingCall. Example: order_list = v,i,s means sequential resending of messages of the following types: VK → Viber → SMS.
<type>_resendCond	string	Parameter that defines the conditions for triggering a resend. More details Here <type> is a character that defines the type of message (i, s, v, f, p, w), for which the settings are applied. Possible values (case insensitive): N — do not resend; Y — resend upon receiving status Not Delivered; S — same as Y, plus resending will occur if status Viewed is not received within the message's lifetime. Important The value S is not applicable for SMS and FlashingCall messages, as they do not have a Viewed status. Using a combination of parameters, various settings can be defined for different types of messages. Example 1. Standard values with arbitrary order of message types: order_list = "W,V,S", W_resendCond = Y, V_resendCond = S In this case, a resend will be performed to VK if the status Not Delivered is received for WhatsApp, and then to SMS if the status Viewed is not received, or if the status Not Delivered is received for VK. Example 2. In this case, only the first message of the cascade (Flashing Call) will be sent: order_list = "F,S", F_resendCond = N, S_resendCond = Y The cascaded SMS will not be sent, as the triggering of a cascade AFTER the Flashing Call message is prohibited (F_resendCond = N). The parameter S_resendCond = Y has no effect here, as this is a setting for triggering the cascade AFTER SMS.
<type>_resendSn	string	Parameter that defines the service names from which messages will be sent in resend mode. More details Here <type> is a character that defines the type of message (i, s, v, f, p, w), for which the settings are applied. Example. v_resendSn=0002&i_resendSn=0001&s_resendSn=0000 means that: VK messages are sent from the 0002 name; Viber messages are sent from the 0001 name; SMS messages are sent from the 0000 name. The service names used must be available for the Partner. To use service names, please contact your account manager.
<type>_resendText	string	Parameter that defines the alternative message text for different types of messages that will be sent in resend mode. More details Here <type> is a character that defines the type of message (i, s, v, f, p, w), for which the settings are applied. Example: v_resendText=textVK&i_resendText=textViber&s_resendText=textSMS means that: VK messages are sent with the text textVK; Viber messages are sent with the text textViber; SMS messages are sent with the text textSMS. The message text is subject to the same restrictions as the corresponding types of individual messages (see the relevant sections “Request Parameters”).
<type>_resendValid	string	Parameter that defines the lifespan for different types of messages sent in resend mode. More details Here <type> is a character that defines the type of message (i, s, v, f, p, w), for which the settings are applied. The lifespan means the interval during which the operator will attempt to deliver the message to the recipient. If the message lifespan has expired and the message has not been delivered, it will no longer be delivered to the recipient. Acceptable lifespan ranges for different types of messages: SMS — from 1 to 2880 minutes (up to 2 days); FlashingCall — from 1 to 5 minutes; VK — from 60 to 86400 seconds (up to 1 day); Viber — from 30 to 86400 seconds (up to 1 day); Push — from 30 to 86400 seconds (up to 1 day); WhatsApp — from 1 to 10080 minutes (on the operator's side, the value is rounded to whole days). The value format for the parameter is YYMMDDhhmmsstnnp, where: YY — last two digits of the year; MM — a month (from 01 to 12); DD — a day (from 01 to 31); hh — an hour (from 00 to 23); mm — a minute (from 00 to 59); ss — a second (from 00 to 59); t — a tenth of a second (from 0 to 9); nn — a number of quarter-hours (15-minute intervals) indicating the time difference between local time and UTC time (from 00 to 48). For example, for 8 hours the value is 32; p — an attribute for scheduling message resending and lifespan expiration (in absolute or relative time formats). Possible values for p in the absolute time format: + — a shift of the local time in quarter-hour increments ahead of UTC. For example, 08+ corresponds to GMT+2; – — a shift of the local time in quarter-hour increments behind UTC. For example, 04–responds to GMT–1. Example 1. In the absolute time format 29.04.2025 22:00:00 (GMT+3) is encoded as 250429220000012+. Important In the absolute format 250429220000012+ for GMT+ timezones, the final plus sign must be appropriately encoded when sent in an HTTP request, i.e. in the query string it should appear as 250429220000012%2B. The p attribute in the relative time format: R — message lifespan relative to the current time. The values for tenths of a second (t) and the UTC offset (nn) are ignored and must be set to 0 and 00, respectively. Example 2. For a message lifespan of 3 minutes relative to the current time, the format is 000000000300000R. Absolute time format The default format. The scheduled resending time and message lifespan expiration are specified in the global UTC format, including a quarter-hour offset and a direction symbol (+ or –). Relative time format Relative time can be specified by setting the UTC orientation flag to R instead of + or –. In this format, the time is interpreted as a number of years, months, days, hours, minutes, and seconds relative to the current time. For example, the following time format 020610233429000R will be interpreted as a relative period of 2 years, 6 months, 10 days, 23 hours, 34 minutes, and 29 seconds from the current time.
shorten_list	string	Parameter designed to control the shortening of links in various types of cascaded messages. More details Important This parameter will only be processed if the order_list parameter is provided. The value of the shorten_list parameter may contain: a list of message types (comma-separated) for which links need to be shortened; an empty value (shorten_list = ) if link shortening is not required for all message types. Possible values (case insensitive): s — SMS; p — Push; v — VK; i — Viber; w — WhatsApp. Example: shorten_list = S,I means that links will be shortened only in SMS and Viber messages of the cascade. By default, the Link Shortening Service is not available. To enable it, please contact your account manager.

Note

Example of the sequence for a configured cascading message sending: VK → Viber → SMS.

1. The message will be sent into VK.
2. If the message is successfully delivered, the cascading is completed (go to step 6).
3. If the message is not delivered due to an error or within the specified time to live, the message will be resent via Viber.
4. If the message is successfully delivered, the cascading is completed (go to step 6).
5. If the message is not delivered due to an error or within the specified time to live, an SMS message will be sent.
6. The Partner receives the final status of message sending (optionally - all intermediate statuses).