Skip to main content

What it is

Mellowtel automatically caps how many requests a single device (a “node”) will accept and process. The cap is enforced inside the SDK. You do not configure it, and a misbehaving partner cannot raise it from the outside.

Why it matters

Sharing bandwidth should never slow the user’s app or connection. If a node served unlimited requests, a user on a slow network would feel it. Rate limiting is the mechanism that protects that promise, and it’s why you can ship Mellowtel to real users without worrying about support tickets about “the browser feels slow.”

How it works

Each request runs inside a sandboxed, credentialless window (see Privacy). Because requests are isolated from the user’s session, the only knob that matters for user experience is how many run, and that is what rate limiting controls. The current limit varies based on:
  • Bandwidth speed: slower connections receive fewer requests.
  • Geolocation: capacity is balanced regionally.
  • Overall network availability: the SDK backs off when global demand is low.
TODO: Document concrete numbers (req/min ceilings, geo tiers, bandwidth thresholds) once finalized. For now the limits are intentionally adaptive and not exposed via the public API.

API surface

There is no rate-limiting API to call. The throttle is internal and always on. You cannot disable it, and you should not need to inspect it. If you believe rate limiting is causing an issue in your integration, open an issue on GitHub or ping us on Discord.
  • Privacy: what the sandboxed window does and does not have access to.
  • Opt-in / Opt-out: the consent layer that sits in front of all of this.