Why Your Spreadsheet May Use More FMP API Calls Than You Expected

You enter a formula that retrieves FMP data, confirm that it works, copy it down 50 rows, and add another tab. The workbook still looks manageable, but your API usage is rising faster than expected.

A spreadsheet can hide the number of requests behind cells, formulas, tabs, and refreshes. If each copied formula retrieves data independently, what looks like one workflow can become dozens or hundreds of separate requests. Understanding which cells retrieve data and which reference existing results makes that usage easier to control. The goal is to understand where the calls are going and build the sheet so that the same data can be reused wherever it is needed.

Key Takeaways

• FMP counts actual API requests. The number of formulas or populated cells does not establish the request count.
• Direct API connections and FMP's native spreadsheet add-on have different usage considerations.
• Copied formulas, repeated retrievals across tabs, and additional refreshes can increase calls when they send new requests.
• Test a small set of tickers, reuse returned data, and measure usage before expanding the workbook.

Check How Your Spreadsheet Connects to FMP

Start by identifying the tool that retrieves the data. A custom formula, script, or connection that sends requests to an FMP API URL using your API key uses the API access associated with your account. FMP defines one API call as one request. A request may return multiple fields, dates, or symbols when the endpoint supports them.

The native Excel and Google Sheets add-on uses spreadsheet functions that can retrieve ranges of companies, fields, and periods together. Its documentation currently states that FMP does not impose data quotas on the add-on, while Google Sheets has its own request limits. It also cautions against excessive simultaneous requests.

The numerical examples below apply to separate requests made to the FMP API using an API key. They should not be treated as a formula-by-formula usage calculation for the native add-on. If you use a third-party connector, check how it retrieves and refreshes data before estimating calls from the number of cells.

A Single Formula Can Become Dozens of Requests

Suppose your spreadsheet sends one request for company profile data for each ticker in a list of 50 companies. That produces 50 requests. If it then sends a separate historical-price request and a separate financial-ratio request for each ticker, the total becomes 150.

The following estimates assume one separate request per ticker for each endpoint during a complete run. They also assume that each tab retrieves independently, with no combined-symbol requests, reuse of saved results, or additional requests.

Workbook setup	Requests per complete run
10 tickers × 1 endpoint	10
50 tickers × 1 endpoint	50
50 tickers × 3 endpoints	150
100 tickers × 3 endpoints	300
100 tickers × 3 endpoints × 2 independently retrieving tabs	600

The issue usually appears when several reasonable choices compound. You start with 20 tickers, add 10 more, add another endpoint, and duplicate the sheet for a second watchlist. Each addition feels small because you are looking at the workbook visually rather than at the requests it sends.

A response can also populate many cells. For example, a historical-price request may return multiple dates, and a company profile response may supply several fields. Using those returned values throughout the workbook does not require a new request for each value.

Before copying formulas across a larger list, check whether the data you need is already included in an existing response. Where an endpoint supports multiple symbols in one request, that can also change the estimate.

Recalculation Can Repeat a Request Without Changing the Data

A spreadsheet is not a static document, but recalculation does not always involve retrieving external data. Recalculating a margin from revenue and profit already stored in the sheet is a local calculation. A refresh that sends a new request to FMP creates another call, even if the returned values are unchanged.

Review the refresh settings available in your connection. Depending on the setup, retrieval may begin through a manual refresh, a schedule, or a change to an input. Some tools reuse previously retrieved results for a period of time. Check the behavior of the connection you actually use before assuming that every edit or workbook opening causes new FMP requests.

Suppose a full refresh sends 100 separate requests. Running that retrieval again sends another 100 if all requests are repeated. The dashboard may look exactly the same afterward, but the additional retrieval still contributes to usage.

Choose a refresh frequency that fits the work. A workbook reviewed once each morning may not need the same update schedule as a price-monitoring dashboard. Recording the last successful retrieval time also helps distinguish current data from values left over from an earlier refresh.

Reuse Data Across Tabs and Dashboards

This commonly happens as a spreadsheet grows: you build an Overview tab, then a Valuation tab, then a Watchlist tab. Each begins with a copied formula set because copying is faster than redesigning the workbook. If those formulas retrieve independently, several tabs may request the same information.

Suppose three tabs each make 40 separate profile requests for the same companies. That is 120 requests during a complete run. A shared retrieval of those 40 profiles, with the other tabs referencing the returned cells, would require 40 under the same assumptions.

A practical structure separates the main jobs within the workbook:

Workbook area	Main job
Ticker list	Define the securities being followed
Retrieval area	Bring the required FMP data into the sheet
Calculation area	Calculate values from the retrieved data
Dashboard and charts	Display results from the retrieval and calculation areas
Research notes	Record assumptions and interpretation

The reduction comes from reusing results already loaded into the sheet. Moving the same independent requests onto one tab does not, by itself, reduce their number. Make sure dashboard and summary cells reference the returned values rather than contain copies of the external-data formulas.

This also makes the workbook easier to expand. A new chart can reference the existing retrieval area, and another research tab can use the same company data. For overlapping watchlists, check which symbols and datasets are shared before creating a separate retrieval for every list.

If you want to add financial ratios or key metrics, review the returned fields before adding another request across every ticker. A dedicated endpoint may provide useful information that the workbook does not yet contain. Calculate a value locally only when you have the required inputs and can match the intended definition and reporting period.

Repeated Testing Can Consume Calls Before the Workbook Is Finished

Testing itself uses calls whenever it sends requests. You try one symbol, change the formula, test another endpoint, and refresh the sample. Those requests contribute to usage even though the full workbook is still being built.

Suppose you test three endpoints across 10 tickers, making one separate request per endpoint per ticker. The first run uses 30 requests. Repeating it brings the total to 60, and then running the same setup across 100 tickers adds 300 more. The combined total is 360 requests before any further refreshes.

Start with two or three representative tickers that your account can access. Confirm the returned fields, reporting periods, and calculations before expanding the list. A small sample checks the request logic; it does not establish that every company or market will return the same data.

A small test tab can hold experimental formulas while you work. Once the request works, move the final version into the main retrieval area and remove or disable unnecessary test copies. This keeps temporary experimentation from becoming a continuing source of requests.

Measure One Refresh Before Expanding the Workbook

The most useful check is to compare an estimated retrieval with the usage it produces. For direct API requests, the account activity dashboard shows API usage and bandwidth. Use that information while the workbook is still small enough to inspect.

1. Choose a small test. Note the tickers, endpoints, and parts of the workbook that will retrieve data.
2. Record usage before the run. Choose a period with no other activity using the same account where possible. Other workbooks, scripts, and tools can affect the account total.
3. Run one deliberate refresh. Let it finish without repeatedly refreshing while you wait.
4. Compare the totals once usage has updated. If other activity occurred during the test, the difference includes that activity and cannot be attributed entirely to the workbook.
5. Change one thing and repeat. Replace a duplicated retrieval with a reference to existing results, then compare another equivalent run. Confirm that the required data still appears correctly.

If usage is higher than expected, inspect copied retrieval formulas, overlapping tabs, scheduled refreshes, and whether the connection repeats requests after errors. A lower count may reflect combined requests or reuse of earlier results. Check the connection's behavior rather than treating either outcome as proof of how every formula is counted.

Once you have a representative count, include refresh frequency in the estimate. If a complete retrieval sends 160 requests, four identical retrievals would send 640, before separate testing or other account activity. Refresh timing also matters when your plan has a limit on requests per minute.

Check Which Limit You Are Approaching

API call limits and bandwidth limits measure different things. Calls measure the number or frequency of requests. Bandwidth measures the amount of data returned. Requesting a shorter historical period may reduce the data transferred without reducing the number of calls.

Match the adjustment to the problem. Repeated requests for the same values call for more reuse or fewer refreshes. Repeated downloads of long histories call for a review of the date ranges and previously stored data. A Google Sheets or connector quota needs to be addressed within that service's usage rules.

If the remaining workload still needs more capacity, eligible accounts can add API-call capacity or bandwidth. Choose the resource that matches the limit you are approaching. Additional bandwidth does not increase a call allowance, and FMP capacity changes do not remove limits imposed by a spreadsheet service.

Keep the measured request count alongside the workbook's refresh schedule and ticker list. When you add another dataset, dashboard, or watchlist, that record gives you a basis for estimating the extra usage and checking whether the new retrieval is necessary.