Rate Limits
J-Quants API has rate limits (usage frequency restrictions) in place to ensure stable service operation.
If you send requests exceeding the limit within a certain period, API usage will be temporarily restricted.
Rate Limits by Plan
The maximum number of requests per minute varies depending on your subscription plan.
| Plan | Limit (Requests / min) |
|---|---|
| Free | 5 |
| Light | 60 |
| Standard | 120 |
| Premium | 500 |
※ The above are the basic limit values and may be adjusted depending on system conditions.
※ Calls to the List of Downloadable Files API (/v2/bulk/list) and the Get File Download URL API (/v2/bulk/get) are also subject to the rate limits above.
※ Requests are counted per account (user). Issuing multiple API keys does not raise your limit.
Rate Limits by Endpoint
For the following endpoints, individual limits apply regardless of your plan.
| Endpoint | Limit (Requests / min) |
|---|---|
Financial Data (Summary only) (/v2/fins/summary) | 60 |
Financial Statement Data (BS/PL/CF) (/v2/fins/details) | 60 |
※ These endpoints are evaluated against a dedicated limit separate from the plan limit, and the plan limit does not apply to them. Even on the Premium plan, the limit for these two endpoints is 60 requests per minute.
Rate Limits for Add-on
If you have an add-on subscription, separate rate limits apply to add-on-specific APIs.
| Add-on | Limit (Requests / min) |
|---|---|
| Stock Prices (minute-OHLC, Tick) | 60 |
| TDnet/Company Disclosure | 100 |
※ Add-on-specific APIs have limits independent of plan rate limits.
Other Limits
- There is no limit on the number of concurrent connections. The same subscriber may access the API in parallel from multiple worker processes, as long as the rate limits above are observed.
When Limits Are Exceeded
If you make requests exceeding the rate limit, the API will return HTTP status code 429 Too Many Requests.
Rate limits are evaluated using a one-minute sliding window. No Retry-After header is included in the 429 response, so if 429 is returned, do not retry immediately; we recommend implementing controls on the application side so that requests resume after waiting at least one minute (because the window slides, allow about two minutes to be certain).
Requests that return 429 are also counted, so repeatedly retrying without waiting makes it take longer for the limit to clear.
Temporary Access Restriction
If you significantly exceed the rate limit and continue making requests, access may be completely blocked for approximately 5 minutes.
During this time, all requests will result in errors, so it is recommended to implement controls such as retrying with appropriate intervals on the application side.
Best Practices
-
Efficient Data Retrieval:
- Use query parameters to retrieve only the necessary data and reduce unnecessary requests.
- Many APIs allow you to retrieve data for all issues by specifying only the date. Avoid retrieving data for one issue at a time across all dates.
- Please use the file download feature for bulk retrieval of historical data.
- We also recommend the file download feature for use cases such as retrieving daily bars for several thousand issues on every business day.
-
Error Handling: For how long to wait and how to resume after a
429, see When Limits Are Exceeded.