Access token rate limits and best practices

To help prevent nefarious use of the eBay APIs, each application has a limit on the number of requests it can make to the OAuth endpoint in any one 24-hour day. The number of requests allocated to an application is called the rate limit for that application.

The OAuth rate limits are assigned to the endpoint that an application uses to mint OAuth access tokens (https://api.ebay.com/identity/v1/oauth2/token), and the rate limits are different for each grant_type value. The following table shows the rate limits for the different types of grant_type values:

Grant type

Access Token Type

Rate Limit

Client credentials grant

(grant_type = client_credentials)

Application access token 1,000 requests/day

Authorization code grant

(grant_type = authorization_code)

User access token 10,000 requests/day

Refresh token grant

(grant_type = refresh_token)

User access token 50,000 requests/day

OAuth token best practices

The following list presents some best practices for working with access tokens and their rate limits:

  • Access tokens are short-lived in that they expire relatively quickly after they have been minted. This is a security measure meant to keep ill-intended users from abusing access tokens. Use an access token until it expires, then create a new one using either a client credentials grant for Application access tokens or a refresh token grant for User access tokens.
  • Refresh tokens are long-lived, but they can be unexpectedly revoked. For example, the associated user can change their eBay user name or they can revoke their consent. In addition, eBay can revoke a token for various reasons. With these scenarios in play, your application needs to gracefully handle User access token revocations.
  • Refresh tokens are valid for 18 months. When a refresh token expires, you must issue another permissions grant request to mint a new User access token for the respective user.
  • Even while access tokens are short lived, eBay strictly enforces a daily rate limit on the number of tokens you can mint with each type of grant request. Make sure your application stays within the request limits for your OAuth tokens.
  • Create your User access tokens using all the scopes needed for the current capabilities in your application, plus any capabilities you plan to add to the app. Adding a new scope to an existing User access token requires a new permission grant from each of your users, and they might balk at multiple consent requests.
  • Create tokens using only the scopes your app needs. For example, there is no need to specify a read-only scope if the corresponding view and manage scope is also being specified.
  • Store your OAuth credentials and refresh tokens on a secure server to prevent them from being hacked and used by bad actors for corrupt or possibly unlawful behavior.