Link is copiedevalink talos Rate Limits and Peak-Load Behavior
Overview
evalink talos enforces rate limits and concurrency limits at several layers to keep the platform stable when a single account or alarm source produces traffic significantly above its normal level. Understanding these limits helps you design reliable integrations and diagnose unexpected delays or rejections during high-volume periods.
All limits described on this page are the default values applied to every account. A subset can be raised on a per-account basis — see section Custom Limits.
The limits serve three purposes:
- Protect downstream services — databases, integrations, and monitoring stations — from being overwhelmed by a single tenant.
- Isolate accounts from each other so a spike in one account does not slow down another.
- Detect and contain misbehaving devices that would otherwise flood the alarm pipeline.
Key Concepts
-
Rate limit — the maximum number of requests, alarms, or workflow steps that can be processed in a rolling time window (for example, "100 per 30 seconds"). Once the budget for the window is consumed, additional work either waits for the window to slide or is rejected.
-
Concurrency limit — the maximum number of operations that can be in flight at the same instant, regardless of how fast they complete. A concurrency of 10 means at most 10 simultaneous executions; the eleventh waits.
-
Burst — a short-term allowance above the steady rate, used to absorb normal traffic peaks. A rate of 90/30 s with a burst factor of 8 lets the account briefly send up to 8× the steady fill rate before being throttled.
-
Per-account vs. per-user limits — most limits have two tiers: a per-account limit (the total budget for everything happening under one customer account) and a per-user / per-API-token limit (the budget for a single UI user or API token). A request must fit both tiers. If a single user is quiet but the account as a whole is busy, the account-wide limit can still throttle that user.
-
Unlimited (−1) — where a limit is shown as unlimited, no cap is applied at that tier; the next applicable tier still applies.
API Request Limits
REST API
Limits applied at the REST API gateway control how many concurrent requests and how many requests per 30-second window a caller may issue. When a caller exceeds these limits, the request is held briefly (up to approximately 30 seconds) waiting for capacity, then rejected with HTTP 429 Too Many Requests if no capacity becomes available.
| Caller type | Concurrency (per user/token) | Concurrency (per account) | Rate (per user/token) | Rate (per account) | Burst |
|---|---|---|---|---|---|
| UI user (logged in) | 6 | unlimited | 90 / 30 s | unlimited | 8× |
| API token (server-to-server) | 5 | 10 | 125 / 30 s | 250 / 30 s | 8× |
| Anonymous (no auth) | 2 | unlimited | 30 / 30 s | unlimited | 2× |
| Alarm submission | 5 | 5 | 300 / 30 s | 300 / 30 s | 10× |
| Webhook callbacks | 5 | unlimited | 300 / 30 s | unlimited | 2× |
| PDF export and report generation | 20 | 20 | unlimited | unlimited | 1× |
Alarm submission covers both the public alarms API (POST /api/alarm-service/alarms, .../alarms-batch) and the integration receiver paths used by webhook-based alarm sources, including /api/webhook-integration/incoming, /api/webhook-integration/periodic, /api/brivo-integration/events, /api/eagle-eye-service/een-automation, and /api/dc09-receiver/vav.
Webhook callbacks covers endpoints that third-party services call back into evalink talos — Twilio, Axis, Zoho webhooks, OAuth providers, the FTP receiver upload path, and the ARC-XML check endpoint. These are typically lightweight and time-sensitive, so they receive a higher rate limit.
PDF generation is not rate-limited by request count because PDFs are slow and naturally self-limiting; only a concurrency cap applies.
CORS preflight (OPTIONS) requests bypass rate limiting entirely.
GraphQL API
| Caller type | Concurrency (per user/token) | Concurrency (per account) | Rate (per user/token) | Rate (per account) | Burst |
|---|---|---|---|---|---|
| UI user (logged in) | 10 | unlimited | 90 / 30 s | unlimited | 8× |
| API token (server-to-server) | 5 | unlimited | 125 / 30 s | 250 / 30 s | 8× |
| Anonymous (no auth) | 2 | unlimited | 30 / 30 s | unlimited | 2× |
| PDF report rendering | 20 | 20 | unlimited | unlimited | 1× |
GraphQL WebSocket subscriptions (/graphql-ws) and actuator endpoints are not subject to rate limiting.
GraphQL Query Complexity Limits
In addition to request-rate limits, the GraphQL gateway rejects queries that are too complex or too large. A query exceeding any of the following thresholds is rejected before execution.
| Threshold | Default | What it limits |
|---|---|---|
| Maximum operations per request | 3 | Named operations (queries / mutations / subscriptions) in a single document |
| Maximum field count | 1 000 | Total fields selected across the query |
| Maximum depth | 10 | Nesting depth of selection sets |
| Maximum aliases | 50 | Aliased fields per query |
| Maximum directives | 20 | Directive applications per query |
| Maximum fragments | 50 | Fragment definitions per query |
| Maximum duplicate fields | 100 | Same field selected multiple times in a single query |
| Maximum batch count | 10 | Operations per batched request |
| Maximum parallel queries per request | 10 | Fields executed concurrently within a single query |
If your query hits these thresholds, the recommended fix is to split it into smaller queries.
Alarm Submission Limits
Alarm ingestion is rate-limited at two layers: at the API gateway (covered above) and inside the alarm service itself, on a per-source basis. The per-source limit is designed to detect and contain a single device or feed that has started flooding the platform.
Per-Source Flood Protection
Each alarm source — the device, receiver, or integration that produced the alarm — is tracked individually. When a single source exceeds its rate, subsequent alarms from that source are dropped and an informational alarm is raised so operators can investigate.
| Setting | Default |
|---|---|
| Action when limit is exceeded | Drop the alarm and emit an ALARM_LIMIT_EXCEEDED event |
| Steady rate | 30 alarms per 15 minutes per source |
| Block duration after first breach | 15 minutes |
| Maximum block duration | 3 hours |
The block duration grows with repeated breaches using an exponential back-off, capped at the maximum.
Per-Alarm-Code Overrides
Some alarm codes are produced at high volume by design — for example, telemetry-style alarms or parking events. These codes have their own higher per-source limits so they are not constantly throttled by the default rule.
| Alarm code | Steady rate |
|---|---|
DATA | 1 000 per 3 hours per source |
UnknownVehicle | 250 per 15 minutes per source |
If your integration produces a new high-volume alarm code, support can add a custom rule for it.
Alarm Enrichment
Once an alarm enters the system, it is enriched by calling several internal services. The enrichment scheduler limits how many enrichment calls each account can make in parallel, so a burst of alarms cannot starve the rest of the platform.
The scheduler uses two queue classes:
| Queue class | Used for | Concurrency (per account) | Rate (per account) |
|---|---|---|---|
| Fast | Device and virtual device lookups (low-latency) | 50 | 100 per 5 s |
| Slow | Workflow service and alarm dispatcher routing (heavier work) | 25 | 50 per 5 s |
The enrichment queue can hold up to 1 000 000 pending enrichments per account. In practice this limit is sized to cover all but the most extreme sustained incidents.
Workflow Limits
Workflow Start
Limits how many workflows can be started or resolved per account per time window.
| Queue | Concurrency (per account) | Rate (per account) |
|---|---|---|
| Workflow start | 10 | 60 per 15 s |
| Workflow preparation | 10 | 60 per 15 s |
| Per-account global | unlimited | 100 per 15 s |
The shared work queue holds up to 1 000 000 pending start/resolve operations per account.
Workflow Engine — Per Step Type
Each workflow step is dispatched into one of several queues, sized for that step's typical cost. This prevents a noisy step type from consuming capacity that other step types need.
| Step queue | Concurrency (per account) | Rate (per account) | Used for |
|---|---|---|---|
| instant | 10 | 100 per 10 s | Lightweight control flow: alarm, alarm-close, check-condition, close-workflow, do-nothing, jump, loop-counter, match-alarm, pdf-step-report, time-of-day |
| short | 10 | 120 per 30 s | Most operational steps: messaging, status and tag changes, monitoring station dispatch, integration calls (Brivo, DC09, Slack, TNA, VBV), check-status, blacklist-check, and others |
| long | unlimited | 120 per 1 min | Long-running work: AI agent calls, mobile alarm verification, Sequrix calls, intervention deployments (Baviloc, patrol), async-flow |
| wait | unlimited | 100 per 10 s | wait-for-status, wait-for-alarm, wait-time |
| webhook | 10 | 25 per 5 s | Outbound trigger-web-hook calls |
| 3 | 25 per 1 min | send-email | |
| twilio-short | 3 | 30 per 1 min | twilio-send-sms |
| twilio-long | unlimited | 15 per 1 min | twilio-call, twilio-group-call, twilio-sms-verification, twilio-verify-alarm |
The per-account global rate for the workflow engine is 50 per 5 s. The queue can hold up to 1 000 000 pending step executions per account.
Per-Device Workflow Execution
To prevent a single misbehaving device from accumulating runaway workflow executions, evalink talos limits the number of concurrent workflow executions tied to one device to 10. When a device exceeds this limit, new workflows for that device are deferred until existing ones complete.
For details on limits when running concurent automated workflows, see section Concurrent Execution of Automated Workflows.
What Happens When a Limit Is Hit
-
HTTP 429 Too Many Requests — returned by the API or GraphQL gateway when the rate limit cannot be satisfied within the wait budget (approximately 25 seconds). Retry with exponential backoff. The response body contains a brief explanation, for example: Rate limit exceeded (API). Please try again later.
-
Slow response with no error — when a request only briefly exceeds capacity, the gateway holds it for a few seconds until a permit becomes available. This is normal and intentional during traffic bursts.
-
Dropped alarms — when per-source flood protection fires, alarms are dropped and an
ALARM_LIMIT_EXCEEDEDevent is logged so operators can find the offending source. The source remains blocked for at least the configured block duration. -
Backpressure (queueing) — enrichment and workflow steps that exceed their queue rate wait in line. They are not lost; they will execute as capacity becomes available.
Recommended client behaviour:
- Treat any 429 as transient and retry with exponential backoff — start at 1 s, cap around 30 s.
- Limit concurrency on your side. For batch ingestion especially, 5–10 in-flight requests almost always outperforms unbounded concurrency.
- Use bulk endpoints (
/alarms-batch) where available — they count as a single request against the rate limit.
Custom Limits
Most of the limits above can be raised, lowered, or disabled per account by evalink talos support, including:
- Per-account API and GraphQL request rates and concurrency
- Per-account alarm submission rates and intervals
- Workflow engine global rate and per-queue rates (notably the webhook queue)
- Alarm enrichment per-queue rate and concurrency
- Maximum concurrent workflow executions per device
If your integration legitimately needs higher limits — for example, a busy enterprise account, a high-volume telemetry feed, or a data backfill — contact evalink talos support with:
- The account ID and a description of the workload
- The expected sustained rate and peak rate
- The integration or endpoint that will produce the traffic
Limit increases take effect within a few seconds without any service restart.
Diagnosing Throttling Issues
If you suspect throttling, the quickest signals are:
- HTTP 429 on the calling side — or a Rate limit exceeded message from the gateway.
ALARM_LIMIT_EXCEEDEDevents in the event log — per-source flood protection has fired for a device or integration.- Slow alarm or workflow processing — workflow steps may be queuing due to rate limits; they will still execute, just with a delay.
For each case, evalink talos support can correlate the event with the active limits for your account and confirm whether the cause is a default limit, a per-account override, or a misbehaving alarm source.