Rate limiting (Indeed PLUS)

Manage Indeed PLUS API limits.

 

Excessive API calls can disrupt Indeed services. To protect the platform and its participants, Indeed applies rate limiting.

Rate limiting caps the total cost of API calls that a client can make in a set period. This helps protect Indeed 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.

Understand rate limiting

When a client performs a GraphQL operation, Indeed measures the cost of that operation. Each client has a budget. If the total cost of the client's operations exceeds that budget within 60 seconds, Indeed rate limits the client.

When Indeed rate limits a client, it blocks later operations and returns an HTTP status code.

Indeed tracks operation cost in a rolling total. Sixty seconds after a client performs an operation, Indeed removes that operation's cost from the rolling total. This frees capacity for other calls.

Each client has its own rolling total. Clients do not share totals. Indeed offers several tiers with different capacities to support different client needs.

This example shows rate limiting for Indeed PLUS APIs with a maximum capacity of 100.

Units are for illustration only:

Rate limiting

Time	Action by partner	Cost	Response from Indeed	Rolling total Max capacity: 100
12:00:00	No action	0	No response	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		Call A is removed from the rolling total	50

Check your rate limit

Indeed assigns each client to a tier with a specific rate limit based on that client's needs. Several tiers are available.

Handle rate limiting

If a client exceeds its rate limit, each later call returns an HTTP 429 response status code. Indeed does not process API calls after the client exceeds its rate limit.

Plan for rate limiting in your integration. No single approach works for every client, so choose an approach that fits your customers' needs.

If your client is being rate limited, contact your Indeed representative and provide traffic estimates so they can help you change your tier.

Recover from rate limiting

If your client is rate limited:

• Expect later API calls to be blocked and return HTTP 429 until enough operation cost expires from the rolling total.
• Expect Indeed to stop processing API calls after your client exceeds its rate limit, and to keep blocking later calls until your costs decrease.

To resolve this:

• Review your request patterns: Check whether your processes make too many 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 whether I am close to a rate limit?

These scenarios can increase traffic and lead to rate limiting:

• Track organic, gradual increases: Indeed might contact you with more details.
• Prepare for sudden increases: Legitimate traffic, such as a launch or campaign, or illegitimate traffic, such as a bug or malicious actor, can cause a sudden increase. Indeed cannot always determine the cause, so it might treat the traffic as illegitimate and rate limit your client. If you expect a legitimate sudden increase, see the following section.

Prepare for traffic increases

If your request volume stays stable or increases gradually, the type and content of your operations stay stable, and you follow the best practices in this document, your client is unlikely to be rate limited. If your client gets close to its limit, Indeed might contact you with more details.

If you expect a 25% or greater increase in request volume or a significant change in the type or content of your operations, contact Indeed two weeks in advance. Provide data that helps estimate the impact, such as:

• Estimate the increase in requests:

  • Number of additional requests during peak traffic
  • Operations involved
  • Duration of the increase

• Describe significant changes in operation type and content:

  • Operations involved
  • Sample operations

Avoid rate limiting

To reduce the chance of rate limiting, follow these best practices.

Log and monitor

Log and monitor the outcome of all requests. In particular, monitor the HTTP status in each response, especially when the status is not a 2xx success code. This helps you detect rate limiting.

Detect and block bots

Set up alerts for suspected bot abuse. When you receive an alert, block the bot's requests if appropriate. Ideally, your system blocks those requests automatically to reduce impact.

Validate user input

Validate user input so invalid requests do not add to your rolling cost total.

Query the minimum amount of data

Request only the data that you need. This lowers the cost of each operation.

Reduce crawler crawl rate

If you expect or welcome "good" crawlers such as Googlebot, but want to avoid rate limiting during high-load periods, consider limiting their crawl rate. For more information, see Reduce the Googlebot crawl rate.

Wait before retrying

If your system retries failed requests, increase the time between retries and reduce the number of retries when rate limiting occurs.

 

Was this page helpful?