- How does rate limiting work?
- What is my rate limit?
- What happens if my client is rate limited?
- How do I recover from rate limiting?
- How do I know if I'm close to being rate limited?
- I anticipate an increase in traffic. How do I ensure rate limiting will not affect my business?
- How do I avoid being rate limited?
- Log and monitor
- Detect and block bots
- Validate user input
- Query the minimum amount of data
- Reduce crawler crawl rate
- Wait before retrying
Rate limiting (Indeed PLUS)
Manage Indeed PLUS API limits.
Excessive API calls can disrupt Indeed’s services. To prevent this from negatively impacting Indeed’s platform and platform participants, Indeed uses rate limiting.
Rate limiting caps the total cost of calls a client can make within a certain amount of time, ensuring quality API usage and protecting Indeed’s systems, customers, and partners.
When you call the Indeed PLUS APIs, initiate a timeout after 5,000 milliseconds.
See also Job Sync API rate limits.
How does rate limiting work?
When a client performs a GraphQL operation, Indeed measures the cost of that operation. Each client is allocated a budget, and if the total cost of a client’s operations exceeds its budget within a certain time span (60 seconds), the client is rate limited.
If a client is rate limited, Indeed blocks successive operations–that is, operations fail and return an HTTP status code.
Indeed accumulates the cost of a client’s operations in a rolling total. 60 seconds after a client performs an operation, that operation’s cost is removed from the rolling total, freeing up room for other calls.
Each client has their own rolling total–they are not shared with other clients. There are several tiers with different capacities to accommodate clients’ needs.
This example shows how rate limiting works for Indeed PLUS APIs, with a maximum capacity of 100.
Units are for illustration only:
| Time | Action by partner | Cost | Response from Indeed | Rolling total Max capacity: 100 |
|---|---|---|---|---|
| 12:00:00 | No action (no calls made) | 0 | No action | 0 |
| 12:00:30 | Call A | 50 | Success | 50 |
| 12:01:00 | Call B | 50 | Success | 100 (at capacity) |
| 12:01:15 | Call C | 10 | Error | 100 (at capacity) |
| 12:01:30 | No action | Remove call A from rolling total | 50 |
What is my rate limit?
Indeed assigns each client a tier with a certain rate limit, depending on the client’s needs. There are several tiers available to accommodate different clients.
What happens if my client is rate limited?
If the rate limit is exceeded, each subsequent call returns an HTTP 429 response status code (too many requests). Indeed does not process API calls made after a client exceeds their rate limit.
Make sure to handle the case of being rate limited. There is no single method that fits all types of clients, so handle it in a way that fits your customers’ needs.
If you are being rate limited, contact your Indeed representative and provide traffic estimates so they can help you change your tier.
How do I recover from rate limiting?
If you're currently rate-limited:
- Each subsequent API call that is over your rate limit is blocked in 60 second intervals and returns the HTTP 429 error.
- Indeed does not process API calls made after a client exceeds their rate limit, and each subsequent call is blocked until your costs decrease.
To resolve this:
- Review your request patterns: Check whether your processes make excessive API calls.
- Implement best practices: For recommendations, see How do I avoid being rate limited?
- Contact your Indeed representative: Provide traffic estimates so they can help you change your tier.
How do I know if I'm close to being rate limited?
The following are two scenarios where there is an increase in traffic that may warrant rate limiting:
- Organic, gradual increase: Indeed may reach out to you with more details.
- Sudden increase: May indicate legitimate traffic, such as during a launch or campaign, or illegitimate, such as traffic caused by a bug or malicious actor. It is difficult for Indeed to determine the root cause, so Indeed assumes that the traffic is illegitimate and may rate limit you. If you anticipate a legitimate sudden increase, see the following section.
I anticipate an increase in traffic. How do I ensure rate limiting will not affect my business?
If the number of your requests remains stable or increases steadily, the type and content of your operations remains stable, and you implemented the best practices described in this document, you will most likely not be rate limited. If you get close to being rate limited, Indeed may reach out to you with more details.
If you anticipate an increase of 25% or higher in the number of requests and/or anticipate a significant change in the type and content of your operations, contact Indeed two weeks before you expect it to happen. Provide data to help estimate the impact, such as the following:
-
Increase in the number of requests:
- Number of additional requests during peak traffic
- Operations involved
- Duration of the increase
-
Significant change in the type and content of operations:
- Operations involved
- Sample operations
How do I avoid being rate limited?
To avoid being rate limited, consider the following best practices.
Log and monitor
Log and monitor the outcome of all requests. In particular, monitor the response’s HTTP status, especially when it’s not a 2xx success code. This will help you detect when you’re being rate-limited.
Detect and block bots
Set up alerts for when a bot is suspected of abuse. When you receive an alert, you can take steps like blocking the bot’s requests. Ideally, requests from such bots are automatically blocked to minimize impact.
Validate user input
Validate input from users so bad requests don’t add to your rolling cost total.
Query the minimum amount of data
Request only what you need, lowering the cost per operation.
Reduce crawler crawl rate
If you expect, or even welcome, “good” crawlers such as Googlebot, but fear they might cause you to be rate limited, consider restricting their crawl rate under high-load scenarios. For more information, see Reduce the Googlebot crawl rate.
Wait before retrying
You might have logic in place to retry a request if it fails. If you are being rate limited, consider increasing the time between retries and decreasing the number of retries.