Quotas and plans

Notifly operates on a model of daily quotas. The main unit of accounting is an event: any action that generates a notification or consumes platform resources charges exactly one event. When the daily limit is exhausted, new events on the same day are rejected — until the counter resets at 00:00 Moscow time.

Plans

Limits depend on the plan. Current values:

Limit	Free	Pro	Business
Events/day (`dailyEvents`)	1 000	100 000	1 000 000
AI requests/day (`aiRequestsPerDay`)	20	500	5 000
Assistant requests/day (`assistantRequestsPerDay`)	100	2 000	20 000
Port scans/day (`portScansPerDay`)	10	100	1 000
Devices (`devices`)	3	5	20

Devices — the number of simultaneously active clients (applications receiving notifications). When downgrading the plan, excess devices are automatically moved to suspended (the oldest active clients are disabled).

One action — one deduction

A deduction happens at the moment of the action — a check, a ping, sending a point, receiving an email — not for the resulting notification. From this follows:

a monitor check that triggered an alert charges only the check event (monitor / http_monitor / content_monitor / port_monitor / workflow_monitor) — there is no separate event for alert or recovery;
a heartbeat recovery notification does not charge anything beyond the already counted heartbeat;
exception — heartbeat_alert: the “missed ping” alert has no ping of its own (the ping didn’t arrive), so it is counted as a separate event;
metric alerts are counted via the metric point; there is no separate event for an alert;
email and webhook router are counted on arrival: one incoming email = one email event, one incoming router payload = one router event, regardless of how many channels they are forwarded to (forwarding to channels is not charged separately);
a single action is never charged twice under different categories.

When the limit is exceeded the user receives a system notification once per day that the quota is exhausted.

Event types

Each deduction belongs to one of the event types. These same keys appear in quota breakdown and in the admin.

Key	When charged	Limit
`message`	Each incoming message to a channel	`dailyEvents`
`heartbeat`	Each ping of the heartbeat	`dailyEvents`
`heartbeat_alert`	Triggering of the “missed ping” alert	`dailyEvents`
`monitor`	Each check of a protocol monitor (TCP/DNS/TLS, etc.)	`dailyEvents`
`http_monitor`	Each check of an HTTP monitor	`dailyEvents`
`content_monitor`	Each check of a content monitor	`dailyEvents`
`port_monitor`	Each check of a port monitor	`dailyEvents`
`workflow_monitor`	Each check of a multi-step API workflow monitor	`dailyEvents`
`port_scan`	Each discovery port scan of a host	`portScansPerDay`
`web_script`	Each trigger of the web script	`dailyEvents`
`metric`	Each sent metric point	`dailyEvents`
`ask`	Each question posed to the ask monitor	`dailyEvents`
`email`	Arrival of an email in the inbox (once per email)	`dailyEvents`
`router`	Incoming payload to the webhook router (once per request)	`dailyEvents`
`ai_request`	Call to AI/LLM (choosing a router rule, selector, or workflow step)	`aiRequestsPerDay`
`assistant_request`	Dialog interaction with the chat assistant	`assistantRequestsPerDay`

Counter reset

All daily counters are reset on schedule at 00:00 MSK. The historical breakdown by day is not removed — the new day simply starts counting from zero, and past days’ statistics remain available.

Rate limit for the scripts ingest endpoint

In addition to the daily quota, the public ingest endpoint for the web script (POST /script/:token) is protected by a separate rate limit: no more than 120 requests per minute per token (fixed window). When exceeded the server responds with HTTP 429 Too Many Requests with a Retry-After header (seconds until the end of the current window) and a body:

{ "ok": false, "error": "rate limited" }

The client SDK batches events itself and enforces a hard limit of 100 POSTs per session, so 120/min comfortably covers legitimate traffic. The limit is applied per-token and is counted separately from the daily events quota.

Balance top-up and plan changes

Balance and plan are managed in the admin — app.notifly.ru, in the user profile section. You can also see current usage for each quota there.

Changing the plan (free / pro / business) takes effect immediately. When downgrading the plan, excess devices are automatically moved to suspended — the oldest active clients are disabled until the new limit.
Balance top-up is available directly to administrators; regular users are provided with payment details for bank transfer.

Quota breakdown

GET /user/quota-breakdown returns detailed usage statistics for the current user for a day (by default — today in MSK; another day — via ?day=YYYY-MM-DD):

curl -H "X-Notifly-Key: C_xxx" \
  "$NOTIFLY_URL/user/quota-breakdown?day=2026-06-23"

The response contains:

day — the date (YYYY-MM-DD in MSK);
rows — row-wise breakdown “event type × resource” with a human-readable resource name;
hourly — hourly events consumption for the day;
series — per-minute consumption split into three series: events (main quota), ai (AI requests) and portscan (port scans).

REST API

Base URL — https://notifly.ru (or $NOTIFLY_URL). Authorization header — X-Notifly-Key (client-token, prefix C) or Basic Auth.

Method	Path	Purpose
`GET`	`/user/quota-breakdown`	Detailed daily usage breakdown (`?day=YYYY-MM-DD` optional)
`POST`	`/current/user/topup`	Top up balance. Body: `{"amountRubles": N}` (integer ≥ 1). Direct top-up — only for administrators; regular users receive `402` with payment details
`POST`	`/current/user/plan`	Change plan. Body: `{"plan": "free"｜"pro"｜"business"}`. When downgrading it suspends excess devices (response includes `suspendedDevices`)