ByteArk · Rate Limits

Bytark Rate Limits

ByteArk does not publish explicit numeric request-per-second rate limits for its Stream, Storage, and Fleet APIs in public documentation. The most concrete documented constraint is a per-account live transcode limit (transcodelimit) capping the number of simultaneous active live transcodes, which is raised on request through ByteArk sales. Storage and CDN are usage-metered rather than request-throttled. Specific per-endpoint values are not reconciled in this artifact.

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

It captures 4 rate-limit definitions, measuring concurrent_transcodes, requests, and bandwidth.

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

Tagged areas include Video, Streaming, CDN, Object Storage, and Rate Limiting.

4 Limits Throttle: 429
VideoStreamingCDNObject StorageRate LimitingQuotasThrottling

Limits

Simultaneous Live Transcodes account
concurrent_transcodes
see account transcodelimit
Per-account cap on simultaneous active live transcode channels, returned as transcodelimit / transcodeusage in the live channel API. Raised on request.
Stream API Requests account
requests
see provider documentation
No public numeric RPS/RPM limit documented for the Stream Video API.
Storage (S3) Requests account
requests
see provider documentation
S3-compatible operations; no public numeric request limit documented. Usage is billed by stored GB rather than request count.
CDN Delivery account
bandwidth
usage-metered
CDN is metered per GB of egress; no documented request throttle.

Policies

Concurrency-Based Limiting
The primary documented constraint is a live transcode concurrency cap per account rather than request-rate throttling.
Backoff Strategy
Clients should implement exponential backoff with jitter and honor Retry-After on any 429 responses.

Sources