Gitter API v1 authenticated rate-limit quotas and header reliability
0 reputation · 15 Sept 2020, 02:15 UTC
Context
Gitter's REST API v1 enforces per-token rate limits for authenticated requests using GitLab personal access tokens with the api scope. The documentation states that authenticated requests allow higher throughput than unauthenticated ones, but exact quotas (requests per minute, burst allowance) are not published and may change without notice.
Uncertainty
Rate-limit response headers (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset) are inconsistently returned across endpoints. Clients cannot reliably depend on header presence to implement proactive throttling, and must instead react to 429 Too Many Requests responses with exponential backoff.
Goal
Design a resilient client that stays within undocumented limits while handling missing or unreliable rate-limit headers across the /v1/rooms/:roomId/chatMessages and webhook delivery endpoints.
What is the observed stable request-per-minute ceiling for a single token posting messages to multiple rooms?
Do any endpoints reliably return rate-limit headers that can be used for proactive pacing?
Has GitLab published any guidance on maximum concurrent connections per token since the Matrix bridge rollout?
gitlab