ActivityPub · Rate Limits

Activitypub Rate Limits

ActivityPub is an open protocol with no centrally mandated rate limits. Each server implementation sets its own limits. The values below are representative defaults from common implementations such as Mastodon and Misskey. Server operators may tune these values based on their capacity.

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

It captures 5 rate-limit definitions, measuring requests_per_5_minutes, requests_per_second, requests_per_30_minutes, and requests_per_day.

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

Tagged areas include Rate Limiting, Social Networks, and Federation.

5 Limits Throttle: 429
Rate LimitingSocial NetworksFederation

Limits

Client-to-server API (authenticated) user
requests_per_5_minutes · 5 minutes
300
Representative Mastodon default for authenticated client requests (e.g., posting, reading timelines). Unauthenticated requests have lower limits.
Client-to-server API (unauthenticated) ip
requests_per_5_minutes · 5 minutes
100
Unauthenticated read requests limited per IP address on most implementations.
Server-to-server inbox delivery remote-server
requests_per_second · second
10
Inbound federation delivery rate from any single remote server. Implementations typically queue and retry delivery with exponential backoff on 429 or 503 responses.
Media upload user
requests_per_30_minutes · 30 minutes
30
Media attachment uploads are rate-limited separately from API calls due to bandwidth cost. Mastodon default is approximately 30 uploads per 30 minutes.
Account creation ip
requests_per_day · day
5
New account registrations are heavily throttled per IP to prevent spam signup.

Policies

Retry-After header
When a 429 is returned, implementations include a Retry-After header indicating when the client may retry. Clients must respect this header.
Federation backoff
When delivering to remote inboxes, servers must implement exponential backoff and retry queues. Persistent failures result in the remote server being marked as unreachable temporarily.
HTTP Signatures
All server-to-server POST requests must be signed with HTTP Signatures (using the sending actor's private key). Unsigned or invalid deliveries are rejected with 401 or 403 before rate limiting applies.
Implementation-defined limits
Because ActivityPub is a decentralized protocol, there is no universal authority for rate limits. Each server operator configures limits appropriate for their infrastructure. Clients should handle 429 gracefully on any endpoint.

Sources