For almost all REST methods there are no restrictions on the number and frequency of calls.
Limits can appear on a case-by-case basis, if application calls affect API.
Limit on the number of notifications
The number of notifications that the application can deliver to its users per day (from 4.00 to 4.00 of the following morning). Once the limit is reached, the delivery is stopped (sendMass) and any notifications (sendSimple) are forbidden. At 4.00, the counter is reset, and the restrictions are lifted.
The limit is set on a case-by-case basis for each application following a certain formula. The data for the formula are received from statistics that is reset at 4.00 every morning.
Statistics that is used in the formula to set the limit:
- average number of notifications sent in a day per one active user for all applications. An active user is a user that has authorized in the application at least once in the last 6 months. The data on notifications sent are collected for the 7 day period.
- the number of active application users
- the number of reactions to notifications sent in the last 7 days for this application. Quality is the ratio of all positive responses to notifications to negative ones.
The number of reactions to notifications directly influences the limit that will be allocated to the application in the next period. The higher it is as compared to the average portal number, the more notifications are allocated to the application in the next period. And conversely, if the quality is lower than the portal average, the application will not be able to send as many notifications.
The application can influence the quality of reactions to it in the following way:
- raise the overall quality of notifications
- target delivery to narrower, specific user types that will be interested in notifications
- the growth of the number of active users increases the limit proportionally
The application statistics page has a panel for monitoring the notification counter, allocated limit size, as well as input data of the limit calculation formula.
The user can have up to 6 notifications from the application at the same time (5 mass ones and 1 personal).
For better delivery targeting user masks can be used.
We provide resources for every application to store 32 bit-sized data on the user. users.updateMasks. This method allows for storing any set of bytes on the portal side and also retrieve it. For instance, you can use a certain byte to mark users that follow under a category or that have done an important action. Or you can reset it.
Categories identified, and all the appropriate users marked (marking can be gradual, when users perform a certain action, achieve something, etc.), the application starts to have its own intersecting sets. These sets can be “played with” to narrow notification targeting. For this, the method was supplemented with options that help to deliver notifications only to those users whose mask criteria satisfy the set condition.
Despite that in general the user mask is supposed to be used as a filter when delivering sendMass notifications, the application can use it for storing any other information.