Velt · Rate Limits

Velt Rate Limits

Velt governs usage primarily through plan-based capacity rather than a published per-endpoint request-per-second limit. The main capacity dimensions are Monthly Active Documents (MADs) and simultaneous real-time connections, both set by tier (20 connections on Hacker, up to 100,000 on Growth, up to 200,000 on Enterprise). Data (REST) API calls that accept batches cap list inputs - for example notification config requests accept up to 30 document IDs per call. Webhook deliveries are subject to retry scheduling with exponential backoff and provider-side rate limiting on the delivery path. Specific per-endpoint request-rate values are not reconciled in this artifact.

Velt Rate Limits is the machine-readable rate-limit profile for Velt on the APIs.io network, conforming to the API Commons Rate Limits specification.

It captures 4 rate-limit definitions, measuring documents, connections, and deliveries.

The profile also includes 3 backoff/retry policies defined and response codes documented for throttled.

Tagged areas include Real-Time Collaboration, Comments, Presence, Notifications, and SDK.

4 Limits Throttle: 429
Real-Time CollaborationCommentsPresenceNotificationsSDKWebhooksRate LimitingQuotasThrottling

Limits

Monthly Active Documents (MADs) account
documents
plan-based (100 on Hacker; contract on Growth / Enterprise)
Documents with active collaboration in a billing month; primary capacity meter.
Simultaneous Connections account
connections
20 (Hacker) / up to 100000 (Growth) / up to 200000 (Enterprise)
Concurrent real-time client connections allowed by tier.
Document IDs Per Request request
documents
30
Batch input cap on endpoints such as notifications config get/set.
Webhook Delivery Retries account
deliveries
retry schedule with exponential backoff
Failed webhook deliveries are retried on a backoff schedule; provider rate-limits the delivery path.

Policies

Plan-Based Capacity
Capacity scales by tier via MAD volume and connection ceilings rather than fixed per-endpoint RPS.
Backoff Strategy
Clients should implement exponential backoff with jitter and honor Retry-After on 429 responses.
Webhook Recovery
Webhook deliveries retry with exponential backoff and provide a recovery path for missed events.

Sources