API Reference

API Rate Limits

To ensure a consistent experience for all users, the Waitlister API implements rate limiting. This page explains our rate limits and provides best practices for handling them in your applications.

Rate Limit Overview

Rate limits vary based on your plan and endpoint type. The limits are based on requests per minute (RPM) from a single API key.

Rate Limits by Plan and Endpoint Type

Endpoint Categories

• Subscriber Endpoints: All endpoints related to managing subscribers, including:
  • Adding subscribers (/sign-up)
  • Listing subscribers (/subscribers)
  • Getting subscriber details (/subscribers/{id-or-email})
  • Updating subscribers (/subscribers/{id-or-email})
• Log View Endpoint: The analytics endpoint for logging page views (/log-view)

These limits help in the following ways:

• Consistent performance for all users
• Protection against accidental infinite loops
• Prevention of API abuse

Rate Limit Headers

When you make an API request, we include headers that provide information about your current rate limit status.

For example:

X-RateLimit-Limit: 60
X-RateLimit-Remaining: 45
X-RateLimit-Reset: 1683741600

Increasing Your Rate Limits

If you need higher rate limits:

1. Upgrade Your Plan: The Scale plan provides double the API rate limits of the Pro plan.
2. Contact Support: For enterprise-level needs, contact us through the public contact form to discuss custom rate limits.

Monitoring Your API Usage

To prevent hitting rate limits, monitor your API usage regularly.

• Check rate limit headers in your API responses
• Implement logging of API calls and response headers
• Set up alerts when approaching rate limits
• Review your API usage patterns to identify optimization opportunities

Best Practices for Rate Limit Management

1. Implement Exponential Backoff: When receiving a 429 error, wait and retry with increasing delays

   function fetchWithBackoff(url, options, attempt = 1) {
     return fetch(url, options)
       .then(response => {
         if (response.status === 429 && attempt <= 5) {
           const delay = Math.min(Math.pow(2, attempt) * 1000, 30000);
           return new Promise(resolve => setTimeout(resolve, delay))
             .then(() => fetchWithBackoff(url, options, attempt + 1));
         }
         return response;
       });
   }
   

2. Batch Requests When Possible: Instead of making many small requests, batch operations where appropriate
3. Cache Responses: Store responses locally to reduce the number of API calls needed

By following these best practices, you can make sure your application interacts smoothly with the Waitlister API while respecting the rate limits.