How to Estimate Your FMP API Usage Before Choosing a Plan

Before choosing an FMP plan, it helps to answer a practical question: how many API calls will this project create?

You do not need a perfect forecast. You need a reasonable estimate based on what you are building and how many workflows will run under the same account or project. A small dashboard that updates once a day will use data very differently than an app refreshing prices throughout market hours, a screener checking hundreds of symbols, or a backtest pulling years of historical data.

Most usage comes from a few basic variables:

symbols × endpoints × refresh frequency × users or scheduled runs

That formula helps you avoid two common problems: underestimating usage and hitting limits too early, or overbuying before you understand your actual access pattern.

In practice, usage is rarely tied to one isolated request. A project may include testing scripts, scheduled jobs, dashboards, market data refreshes, fundamentals updates, and occasional historical pulls. Estimating usage means adding those pieces together so you understand the total access pattern, not just one endpoint call.

This article shows how to estimate usage across common FMP workflows, including fundamental models, screeners, dashboards, market data refreshes, user-facing apps, scheduled jobs, and backtests.

Key Takeaways

• API usage usually comes from the number of symbols, endpoints, refresh frequency, users, scheduled runs, and active workflows.
• Fundamental data and market data often create different usage patterns because they update on different schedules.
• Dashboards, apps, scheduled jobs, and backtests can increase usage quickly when they combine multiple datasets or refresh often.
• Estimating total usage before choosing a plan helps prevent surprises without forcing you to overbuy too early.
• Before upgrading, check whether duplicate calls, unnecessary refreshes, caching, batching, or bulk access could reduce usage.

Start With a Simple Usage Formula

A basic usage estimate starts with the workflow itself.

Use this formula as a planning shortcut:

number of symbols × number of endpoints × refresh frequency × users or scheduled runs

For example, a workflow that checks 100 symbols across two endpoints once per day may create about 200 calls per daily run, assuming each symbol and endpoint is requested separately.

A dashboard that checks the same 100 symbols across two endpoints every hour will create a much higher total. A user-facing app may create even more usage if each page load triggers profile data, price data, news, calendar data, and estimates at the same time.

Then add the other workflows attached to the same project. Development scripts, scheduled jobs, dashboard refreshes, backtests, and app traffic can all contribute to total usage. A single workflow may look manageable on its own, but the account-level pattern can grow once several pieces are running together.

The point is not to make the math perfect. The point is to understand where usage is coming from before you choose a plan, launch a workflow, or assume you need a higher tier.

Estimate Usage for Fundamental Models and Screeners

Fundamental data usually does not need the same refresh cadence as market prices.

Income statements, balance sheets, cash flow statements, ratios, and other fundamental datasets are typically tied to reporting cycles. A model tracking 500 companies does not need to pull the same statements every minute or every hour.

A simple fundamentals workflow might look like this:

Workflow	Example Usage Pattern
Company profile setup	Pull company profile data once for each symbol in a watchlist or universe
Fundamental model refresh	Pull statements, ratios, or key metrics after earnings or on a scheduled reporting cycle
Filing-based statement review	Pull as-reported financial statements when the workflow needs source filing context
Screener update	Refresh selected fields daily, weekly, or after new filings depending on the strategy
Forecast update	Pull financial estimates when consensus expectations need to be refreshed

If you are building a model across 500 companies and calling one endpoint for each company, that may create about 500 calls for that endpoint if each ticker is requested separately. If the workflow calls four endpoints for each company, the same run may create about 2,000 calls.

That estimate changes based on how the endpoint is structured, whether batch options are available, and whether your workflow can reuse previous results. But the planning logic is the same: more symbols, more endpoints, and more frequent refreshes increase usage.

The easiest place to reduce unnecessary usage is slow-changing data. Company reference data, classifications, and certain historical fields often do not need to be requested repeatedly. If the data does not change often, cache it or reuse the last result when appropriate.

If you are still deciding which datasets belong in the first version of the workflow, start with the data that directly supports the output you need, then add secondary datasets only when they improve the model, dashboard, or report.

Estimate Usage for Dashboards, Price Feeds, and Market Data Refreshes

Market data workflows are usually more sensitive to refresh frequency.

A dashboard that updates once per day may only need one price sweep. A market monitor that refreshes hourly will create more calls. An intraday tool that refreshes every minute during market hours can create a much larger usage pattern.

For example:

Market Data Workflow	Example Usage Pattern
100 symbols refreshed once per day	About 100 calls per daily price sweep if each symbol is requested separately
100 symbols refreshed hourly	About 700 calls during a seven-refresh trading window
100 symbols refreshed every minute	Usage increases quickly and should be planned carefully before launch

Not every dashboard needs minute-by-minute refreshes. A portfolio overview, end-of-day market summary, or internal reporting dashboard may work well with daily or scheduled updates. A trading-adjacent tool, active market monitor, or user-facing app may need a more frequent cadence.

The main question is: how fresh does the data actually need to be?

If the user only needs end-of-day context, frequent intraday calls may waste usage. If the workflow depends on current market movement, a higher refresh cadence may be justified. Match the refresh schedule to the product need before assuming the plan is the issue.

For workflows built around daily price history, the full historical end-of-day price endpoint can support charts, backtests, dashboards, and historical analysis without requiring every workflow to refresh intraday. For trading apps or more active market data products, the refresh schedule should be planned around how the product uses real-time and historical market data.

You can also check usage patterns in the FMP dashboard as your workflow runs. That gives you a better view of whether usage is coming from real demand, repeated calls, inefficient loops, or refresh schedules that are more frequent than necessary.

Estimate Total Usage Across Apps, Dashboards, and Scheduled Jobs

Many FMP projects use more than one dataset or workflow at a time.

A company page might show profile data, recent price movement, financial statements, analyst estimates, market news, and earnings dates. A dashboard might combine historical prices, ratios, fundamentals, and watchlist data. A scheduled job might pull multiple datasets across a large symbol universe every morning.

Real usage often comes from several workflows running at the same time. A dashboard might refresh prices daily, a scheduled job might update fundamentals weekly, and a user-facing page might call profile, price, news, and estimates data whenever someone opens it. Each workflow may look manageable on its own, but total project usage comes from the combined pattern.

Each dataset adds to the total.

Workflow	What Adds Usage
Dashboard tracking 100 tickers	Daily prices, company profiles, watchlist fields, selected metrics
Model pulling fundamentals and estimates	Statements, ratios, key metrics, analyst estimates, refresh schedule
User-facing company page	Profile data, prices, news, calendar data, estimates, repeated user sessions
Historical backtest	Large symbol universe, long lookback period, historical prices, fundamentals, repeated test runs
Scheduled maintenance job	Reference data checks, historical refreshes, estimates updates, retry logic

Combined workflows can create usage faster than expected because each screen, widget, endpoint, refresh schedule, user session, and background job adds calls.

That does not automatically mean you need a higher plan. It means the total access pattern should be mapped before launch. Ask which data needs to load every time, which data can be cached, which endpoints can refresh on a schedule, and whether any requests can be combined, batched, or moved into a background job.

If the project is pulling large historical datasets, many symbols, or repeated multi-endpoint refreshes, it may be worth reviewing whether bulk or batch delivery would be more efficient than many individual requests. This is especially relevant when the workflow starts to look more like an end-to-end data pipeline than a few isolated endpoint calls.

How to Use Your Estimate Before Choosing a Plan

The goal of estimating usage is not to make the plan decision complicated. It is to make the plan decision more grounded.

A practical path looks like this:

1. Estimate expected calls using symbols, endpoints, refresh frequency, users, scheduled runs, and active workflows.
2. Test the workflow at small scale before expanding the symbol universe or refresh cadence.
3. Check usage in the dashboard once the workflow is running.
4. Look for duplicate calls, unnecessary refreshes, or data that could be cached.
5. Add together all scripts, dashboards, apps, and scheduled jobs that will run under the same project or account.
6. Decide whether the project genuinely needs more capacity, broader dataset access, bulk delivery, or a higher plan.

This helps separate two different situations.

In the first case, usage is high because the workflow is inefficient. The same endpoint may be called repeatedly, static data may refresh too often, or the app may request the same data every time a page loads.

In the second case, usage is high because the project is growing. The app has more users, the dashboard tracks more symbols, the job runs more often, the backtest covers more history, or the product needs more datasets.

Those two situations should not be handled the same way. Inefficient usage should be optimized first. Real workflow growth may justify a higher plan or a different delivery method.

If you are still in the testing stage, start by validating the workflow before committing to a larger access pattern. Free access can be enough to confirm endpoint behavior, response structure, and early data fit before the workflow scales.

Common Usage Patterns by Workflow Type

This table can help you turn the workflow into a rough planning estimate.

Workflow Type	Main Usage Drivers	Planning Notes
Endpoint testing	Small number of endpoints and symbols	Start small and confirm response structure before expanding
Fundamental model	Symbols, statement endpoints, ratios, refresh cycle	Cache slow-changing data and avoid unnecessary hourly refreshes
Screener	Symbol universe, metrics, refresh schedule	Usage grows with the number of companies and fields checked
Dashboard	Widgets, endpoints, symbols, refresh cadence	Not every dashboard needs intraday updates
Market data feed	Symbols and refresh frequency	Frequent refreshes can increase usage quickly
User-facing app	Page loads, active users, endpoints per screen	Estimate usage per user session, then multiply by expected traffic
Backtest	Historical depth, symbol universe, endpoints, repeated runs	Large lookbacks and broad universes may require more capacity
Scheduled job	Number of runs, endpoints, symbols	Check whether jobs can run less often or reuse previous data
Combined project	Multiple scripts, dashboards, app screens, jobs, and users	Add usage across all active workflows, not just the largest one

Use these as planning categories, not fixed rules. The same endpoint can create very different usage depending on whether it is used once a week, once a day, once an hour, or every time a user opens a page.

The real estimate should include everything running under the project. A low-volume dashboard, a few scheduled jobs, and a development script can still add up if they run often or touch many symbols.

Before Upgrading, Check for Request Design Issues

Hitting a usage limit does not always mean the plan is wrong.

Before upgrading, look for common request design issues:

• Are you calling the same endpoint multiple times for the same symbol?
• Are you refreshing fundamentals more often than they update?
• Are you requesting company profile or reference data on every page load?
• Can slower-changing data be cached?
• Can scheduled jobs run less frequently?
• Can large workflows use batch, bulk, or background processing?
• Are test scripts still running after development work is done?
• Are several smaller workflows creating more total usage than expected?

If the project is already efficient and still needs more capacity, a higher plan may make sense. But if usage is high because of duplicate calls or overly frequent refreshes, optimizing first can help you choose a plan with more confidence.

Choose a Plan After You Understand the Total Usage Pattern

Once you have a rough estimate, compare it against the plan details that matter most for your project.

Do not look only at calls per minute. Also check:

• dataset availability
• historical depth
• coverage
• bandwidth
• bulk or batch delivery needs
• intraday or end-of-day requirements
• whether the workflow is internal, team-based, or user-facing
• whether multiple workflows will run under the same account or project

For early endpoint testing, Basic may be enough. For recurring fundamentals, historical prices, dashboards, or screeners, Starter may be the first paid plan to compare. If the workflow needs deeper history, intraday data, broader fundamentals, technical indicators, or higher call capacity, Premium may be a better fit. If the workflow depends on global coverage, transcripts, ETF and mutual fund holdings, 13F ownership data, bulk delivery, batch endpoints, or larger-scale production use, Ultimate or sales support may be more appropriate.

When comparing plans, estimate total usage across the project, not just the largest single workflow. A dashboard, a scheduled fundamentals job, a development script, and occasional backtests may each seem small on their own, but together they define the real access pattern.

The best plan is the one that matches how the data will actually be used, not the one that looks largest on paper.

FAQs

How do I estimate FMP API usage before choosing a plan?

Start with a simple formula: symbols × endpoints × refresh frequency × users or scheduled runs. This gives you a rough baseline for how many calls one workflow may create. Then add other scripts, dashboards, apps, and scheduled jobs that will run under the same project so you can estimate total usage more realistically.

What creates the most API usage?

The biggest drivers are usually large symbol universes, frequent refresh schedules, multiple endpoints per screen, user-facing app traffic, scheduled jobs, and historical lookbacks. Several smaller workflows can also add up if they run often or touch many symbols.

Do fundamentals and market data create the same usage pattern?

No. Fundamentals usually update on a slower cycle, so they often do not need frequent refreshes. Market data can create more usage when prices refresh throughout the day. The right cadence depends on the workflow. A quarterly model, daily dashboard, intraday app, and backtest all use data differently.

Should I upgrade if I hit a usage limit?

Not immediately. First check whether the project is making duplicate calls, refreshing data more often than needed, or requesting the same slow-changing data repeatedly. If the workflow is efficient and still hitting limits because of real scale, compare the next plan tier against the total usage pattern. Starter, Premium, and Ultimate differ not only by call limits, but also by historical depth, dataset availability, coverage, and delivery options.

Can I reduce usage before upgrading?

Yes. Common ways to reduce usage include caching slow-changing data, removing duplicate calls, adjusting refresh schedules, batching requests where available, and moving large jobs into scheduled background processes. These changes can lower usage without changing the underlying workflow.

How should I estimate usage for a dashboard or app?

Estimate how many endpoints load on each screen, how many symbols each screen uses, how often the data refreshes, and how many users or sessions you expect. Then add any scheduled jobs, development scripts, or background refreshes that support the same dashboard or app.

Do historical backtests use more API calls?

They can, especially when the backtest covers many symbols, multiple endpoints, long lookback periods, or repeated test runs. A narrow backtest over a small symbol list may be manageable, while a broad backtest across many years and many companies can require more capacity or a more efficient ingestion approach.