Rate Limit Documentation

1. Purpose of Rate Limits

Rate limits protect the stability, performance, and security of the Vibble platform. They prevent abusive behavior, excessive load, and denial-of-service scenarios caused by misconfigured clients or malicious actors.

2. Types of Rate Limits

Vibble applies limits on multiple levels:

• Per-Endpoint Limits: Specific caps for endpoints (timeline, search, posting, etc.).
• Per-User Limits: Requests per authenticated user over a defined window.
• Per-App Limits: Requests per API key or application ID.
• Burst Limits: Short-term peak controls to avoid instant spikes.

3. Read vs Write Operations

Write operations (posting, following, messaging) are more heavily restricted than read operations. Exceeding write limits can trigger stricter enforcement and potential fraud review.

4. Standard Rate Limit Tiers

Illustrative examples (exact values are provided in the developer portal):

• Standard Developer Tier: Suitable for small apps, testing, and prototypes.
• Pro Tier: Higher throughput for production integrations.
• Enterprise Tier: Custom limits defined in contractual SLAs.

5. Rate Limit Headers

Vibble returns rate limit information in HTTP response headers where applicable, such as:

• X-RateLimit-Limit – Maximum requests allowed in the window.
• X-RateLimit-Remaining – Requests left in the current window.
• X-RateLimit-Reset – Time (epoch or seconds) until the window resets.

6. Handling Limit Exceedance

When limits are exceeded, the API may return status codes such as 429 Too Many Requests. Recommended behavior:

• Honor Retry-After headers where provided.
• Back off exponentially rather than retrying aggressively.
• Implement caching to avoid redundant requests.

7. Abuse Detection & Misuse

Abnormal traffic patterns may trigger automated safeguards:

• Temporary throttling or connection slowdowns.
• Automatic suspension of API keys or user tokens.
• Investigation by security and trust & safety teams.

8. Best Practices for Developers

• Batch requests where possible and use bulk endpoints.
• Implement client-side and server-side caching.
• Avoid polling; use webhooks or streaming APIs when appropriate.
• Monitor logs and alerts for 429 responses.

9. Custom & Enterprise Limits

Enterprise customers may negotiate custom rate limits. These are documented in contractual SLAs and enforced via dedicated service configurations. Breaches of agreed usage may result in additional charges or reduced limits.

10. Policy Changes

Vibble may adjust rate limits without prior notice in emergency or abuse scenarios. For planned changes, we aim to notify developers via the developer portal, email bulletins, or status page.

11. Contact

Developer Support: dev@vibble.org
Rate Limit & Capacity Planning: capacity@vibble.org
Legal & Compliance: legal@nexa-group.org