What Happens When You Hit Your FMP API Limit?

Reaching an FMP API limit does not permanently disable your account. It means that your account has reached a usage boundary, either because it made too many requests in a short period, used its available daily calls, or transferred more data than the plan currently allows.

The first step is to identify which boundary you reached. A request is one attempt to retrieve data from FMP. Some plans limit how many requests can be made each day, while others limit how many can be made in one minute. Every plan also has a bandwidth allowance, which measures the total amount of data returned over the previous 30 days.

These limits require different responses. Slowing down requests may solve a short-term rate problem, but it will not reduce the total number of calls used in a day. Making fewer calls may protect a daily allowance, but it may not be enough if each request returns a large amount of data. This article explains how to identify the issue, reduce avoidable usage, and decide whether the account needs more capacity.

Key Takeaways

• Check the error message and account dashboard first. Together, they usually show whether the problem involves request speed, total daily calls, bandwidth, the API key, or access to a particular dataset.
• A 429 error means requests are being made too quickly. Pause new requests, reduce how many are running at the same time, and try again after a short delay.
• Daily calls and bandwidth recover differently. Basic-plan calls are limited by day, while bandwidth reflects the previous 30 days of use.
• Review how the data is being requested before changing plans. Repeated spreadsheet refreshes, duplicate requests, and full historical downloads can use more capacity than expected. Additional capacity will not fix an invalid API key or provide access to data that is not included in the plan.

Which FMP Limit Did You Reach?

The number shown with an unsuccessful request can help identify the problem. If you do not see an error number, check the message returned with the request and review the usage information in your FMP dashboard.

What you see	What it usually means	What to check	What to do first
429 or “Too many requests”	Too many requests were made within a short period	Frequent refreshes, several requests running at once, or repeated attempts after a failure	Pause, reduce the number of requests being made at once, and try again after a short delay
Basic-plan daily call total at its allowance	The available calls for the day have been used	The daily usage shown in the dashboard and any repeated requests	Wait for calls to become available again or reduce the number of calls the update requires
Bandwidth at or near its limit	The account has received more data than its current allowance supports	Large historical downloads, frequent intraday updates, or repeated full-data requests	Request less data, reduce refresh frequency, or consider additional bandwidth
403	The API key is missing, incorrect, or not being accepted	The key used in the request and the active key shown in the dashboard	Correct the key before investigating usage limits
One type of data fails while other requests work	The requested data may not be included in the current plan	The Market Data tab and current plan comparison	Confirm that the plan includes the data before changing capacity
500 or another service error	FMP or a specific data request may be experiencing a temporary problem	Whether other requests also fail and whether a service issue is reported	Check current API status and try again later if the issue is temporary

The API Quickstart error table distinguishes 403, 429, and 500 errors because they have different causes. Treating every unsuccessful request as “limit reached” can lead to the wrong fix.

How FMP Usage Limits Work by Plan

FMP currently provides 250 calls per day on the Basic plan. Paid individual plans use per-minute limits instead. All four individual plans also have a bandwidth allowance based on the amount of data returned over the previous 30 days.

Individual plan	Published request allowance	Published 30-day bandwidth allowance
Basic	250 calls per day	500 MB
Starter	300 calls per minute	20 GB
Premium	750 calls per minute	50 GB
Ultimate	3,000 calls per minute	150 GB

The request allowance and bandwidth allowance measure different things. A request allowance counts how often data is requested. Bandwidth measures how much data FMP returns. An account can remain below its request limit and still use substantial bandwidth if each request contains many records.

Plan allowances and included datasets can change, so confirm the current FMP pricing and plan comparison before making a purchasing decision.

What Should You Do After a 429 Error?

A 429 error means that requests are arriving faster than the account's current limit allows. The request that produced the error did not complete successfully, but the account has not been permanently blocked.

Pause new requests and wait briefly before trying again. If several requests are running at the same time, reduce that number. Avoid repeatedly selecting refresh or immediately resending the same request, because those attempts add more activity while the account is already at its limit.

Check whether a spreadsheet, dashboard, or scheduled update is refreshing repeatedly. An occasional 429 error may reflect a temporary burst, such as refreshing a large watchlist all at once. If the error occurs regularly during normal use, spread requests over more time and compare the busiest period with the request allowance of the current plan.

What Happens When the Basic Daily Allowance Is Used?

The Basic plan currently includes 250 calls per day. Once those calls have been used, additional requests are restricted until calls become available again. FMP does not currently publish one fixed reset time that should be promised to every user, so the dashboard is the best place to check current availability.

A daily allowance measures the total number of requests, not how quickly they are made. Spreading 300 requests across the day does not make them fit within a 250-call allowance. The update still needs fewer calls or a plan with a different allowance.

An analyst can estimate the size of a recurring task with a simple calculation:

Calls per update = number of companies × number of data requests per company

Suppose a watchlist contains 40 companies and each update requests three types of data: a company profile, an income statement, and historical prices. One full update would require approximately 120 calls. Running it three times in one day would require approximately 360 calls, before accounting for repeated requests or additional pages of results.

This calculation does not need to capture every detail on the first pass. It should show whether the planned work can reasonably fit within the account's allowance. The API usage estimation framework provides a fuller method for evaluating the number of companies, datasets, updates, and amount of returned data.

What Happens When the Bandwidth Allowance Is Reached?

Bandwidth measures how much data the account receives, rather than how many requests it makes. FMP calculates bandwidth over the previous 30 days. It does not return to the full allowance on the first day of each month. Capacity becomes available gradually as older usage moves outside that 30-day period.

The amount of data returned can vary considerably by request. A current company profile may contain relatively little data. A long history of daily or intraday prices can contain much more. Repeatedly requesting a company's complete price history will therefore use more bandwidth than requesting only the dates that have not already been saved.

The full historical stock-price dataset allows users to specify dates and narrow the period returned. The same principle applies more broadly: request only the history, companies, and information the analysis actually requires when those options are available.

Most spreadsheet tools, data applications, and account records can help estimate how much data a regular update returns. If an exact measurement is not readily available, begin by identifying the largest and most frequent downloads. Historical prices, intraday records, broad company lists, and repeated full-data refreshes are sensible places to look first.

Once the average size of an update is known, estimate monthly use with:

Estimated 30-day data use = average data returned per update × updates per day × 30

The estimate may not exactly match the dashboard, but it helps identify whether one recurring task accounts for most of the account's bandwidth.

Use the Dashboard to Separate Usage From Access Problems

The FMP dashboard shows daily API calls and bandwidth used over the previous 30 days near the account's API key. The Market Data tab helps users check which datasets are available through the current plan.

These views answer three separate questions:

• Usage: Is the account close to its call or bandwidth allowance?
• Access: Does the current plan include the requested data?
• API key: Is the correct active key being used?

Five Ways to Reduce Avoidable FMP Usage

The goal is not to minimize every request. It is to remove repeated work that does not provide newer or more useful information.

1. Match Refresh Frequency to the Data

Not every dataset changes at the same pace. A company profile usually does not need to be requested every time someone opens the same spreadsheet or dashboard. Annual financial statements do not need the same refresh schedule as market prices.

Group data by how often it can reasonably change. Refresh frequently changing data when the analysis requires it, but keep previously collected information that remains current.

2. Do Not Download the Full History Every Time

The first collection of historical data may require a large request. Later updates usually need only the newest period or any recently revised records. If five years of prices have already been saved, the next update should not automatically request the same five years again.

Keep a simple record of the most recent successful date or reporting period. Use that point to determine what the next update needs to collect.

3. Check for Repeated Spreadsheet Refreshes

Spreadsheet formulas and connected tools can refresh more often than expected. Reopening a file, changing an unrelated cell, copying a formula, or allowing several people to use the same workbook may repeat the same data request.

Review when the spreadsheet refreshes and whether the results can be reused for a reasonable period. A scheduled update may be more efficient than allowing every worksheet action to request the same information again.

4. Reuse the Same Result When Possible

If several charts, worksheets, or users need the same data at the same time, they may be able to use one saved result rather than request identical information separately. This is especially useful for shared dashboards and frequently viewed company data.

The appropriate reuse period depends on the analysis. Daily closing prices, quarterly statements, and live market data should not all follow the same schedule.

5. Review the Scope of Each Update

A watchlist may have grown from 20 companies to 200 without a corresponding review of its request volume. A model may also be collecting datasets that are no longer used in the final analysis.

Periodically review the companies, dates, and data types included in each recurring update. Remove unused requests before purchasing more capacity.

Do You Need an Add-On or a Different Plan?

Additional capacity makes sense when a necessary, well-organized research process still exceeds the current allowance during normal use. It will not correct an API key problem, unlock data excluded from the plan, or solve repeated requests that can be removed.

Situation after reviewing usage	Most likely next step
An occasional burst produces a 429 error	Spread requests over more time and avoid several simultaneous refreshes
The normal workload regularly exceeds the request allowance	Consider additional request capacity or a plan with a higher limit
Necessary large downloads use the bandwidth allowance	Consider additional bandwidth or a plan with a larger allowance
The required data is not included in the plan	Compare the data included with each plan; more capacity alone will not provide access
The data will appear in a public product or client work	Confirm the appropriate commercial and data-display terms in addition to usage capacity

Eligible users can use FMP plan add-ons to increase request or bandwidth capacity. The available options depend on the active subscription and appear in the dashboard. Add-ons increase capacity but do not change the datasets, markets, history, or features included in the underlying plan.

Before adding capacity, review a representative period of normal activity. Record the total number of calls, the busiest minute, the amount of data returned, the largest recurring downloads, and expected growth in the number of companies or users. That evidence will show whether the account has a temporary spike or a lasting capacity need.

What Information Should You Send to Support?

If the cause remains unclear, a detailed support request can reduce unnecessary follow-up. Do not include the API key itself.

Provide:

• The email address associated with the account.
• The type of data being requested and the relevant page or dataset name.
• The approximate time of the problem, including the time zone.
• The error number and message shown.
• Whether all requests fail or only one type of data is affected.
• The daily-call and 30-day bandwidth readings shown in the dashboard.
• Whether the request works when tried once but fails during a larger update.
• A screenshot or example with the API key removed.

Do not place an API key in a support ticket, screenshot, public document, or shared record. If a key has been exposed, replace it from the account dashboard.

A Simple Response Plan

When an FMP request fails, work through the issue in this order:

1. Record the error number, message, data requested, and time.
2. Check daily calls, 30-day bandwidth, API-key accuracy, and data access in the dashboard.
3. For a 429 error, pause and reduce how many requests are being made at once.
4. For a 500 error, check the API status page for a service issue.
5. Estimate the calls and amount of data required by one normal update, then remove repeated requests and unchanged historical downloads.
6. Consider an add-on or different plan only if the necessary workload still exceeds the allowance.

If a limit is reached, start by identifying which one and what created the demand. The error message points to the likely problem, the dashboard shows current usage and access, and a basic usage estimate indicates whether the appropriate response is a smaller update, a slower schedule, or more capacity.