Rate Limits

To keep our service reliable and fair, the Publer API enforces rate limits on all requests. Limits are applied per user account (across all API keys) and use a sliding-window algorithm.

Default Limits

Limit Window	Requests Allowed
2-minute sliding	100 requests

Note: If you need higher throughput for your integration, see Requesting Higher Limits below.

Tracking Your Usage

When you reach the rate limits, every API response includes these headers so you can monitor your rate limit status:

Header	Description
X-RateLimit-Limit	Total requests allowed in the current window
X-RateLimit-Remaining	Requests remaining in the current time window
X-RateLimit-Reset	UNIX timestamp when your window resets (next available slot)

Example Response Headers

X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1714558492

When You Exceed the Limit

If you go over your quota, the API returns:

• HTTP Status: 429 Too Many Requests

• Response Body:

  {
    "error": "Rate limit exceeded. Retry later."
  }

• Headers will show X-RateLimit-Remaining: 0 and a future X-RateLimit-Reset.

Best Practices to Avoid Throttling

• Cache responses for idempotent or infrequently changing endpoints.

• Use bulk endpoints (e.g., POST /api/v1/posts/schedule for multiple posts).

• Stagger non-urgent requests during off-peak hours.

• Monitor headers and throttle your client.

• Implement exponential backoff when you approach or hit the limit.

Requesting Higher Limits

For integrations requiring a higher rate limit, please contact us with:

• Your expected request volume (per minute/hour/day)

• Use case description and critical endpoints

• Project or company name and contact info

Email: [email protected]