Why FMP Examples May Show Different API Versions, and Which Docs to Use Now

You copy an FMP endpoint from an older article, open the current developer documentation, and find another URL for what appears to be the same dataset.

The mismatch is easy to misread. One example may use an /api/v3/ route while another points to a /stable/ path. A code sample may include different parameters, or a newer response may contain fields that an older example never mentioned. That does not automatically mean one source is wrong.

For a new integration, start with the current API documentation. Use the endpoint and parameters documented for the data you need, then investigate older examples when a difference affects your request. If you are maintaining existing code, check the older route's availability and the effect of any proposed change before replacing it.

Key Takeaways

• Build new requests from the current endpoint documentation, including its parameter names, authentication requirements, and response information.
• Do not assume that changing /api/v3/ to /stable/ produces a valid request. Endpoint names and request settings can also differ.
• Additional response fields can reflect an optional parameter or a dataset update without requiring a different endpoint.
• Older examples remain useful for understanding existing code, but legacy documentation and route access should be checked against your account's eligibility.

Why FMP Examples Can Look Different

An API example reflects the request used when it was written. If an FMP article was published when a particular route or parameter set was current, that is naturally what the article will show. A GitHub repository may preserve the same request long after publication, while a newer developer page presents an updated route or additional functionality.

The underlying financial task can remain the same. An older screening example and a current one may both identify technology companies, even though the endpoint name or the way results are retrieved has changed. The analytical purpose alone does not establish that their requests are interchangeable.

Search results can add to the confusion. An older article may answer your question well and appear prominently, while the current endpoint reference sits elsewhere. The age of a page provides context, but the more useful question is whether its request matches what FMP documents now.

Different resources serve different purposes:

Resource	What it helps you establish
Current endpoint documentation	The endpoint, parameters, and response information for a new request
Changelog	Documented changes to routes, parameters, fields, or behavior
Legacy documentation	How an older endpoint was described
Older article	The workflow, calculation, or analytical purpose behind an example
Existing repository	How a particular project constructs requests and uses the results

An article may also show only the fields needed for its calculation. A shorter example response does not necessarily mean those were the only fields available. Before treating two examples as different API versions, compare their endpoint paths, parameters, and the amount of response detail each author included.

Start With the Current API Documentation

For a new integration, establish the request from the current endpoint page. Check the full path, accepted parameters, required authentication, and the response fields your project will use. Do not construct a new URL by combining pieces from examples published at different times.

The Stock Screener endpoint provides a concrete example of why the full path matters.

Example	Endpoint path
Older stock-screener route	/api/v3/stock-screener
Current stock-screener route	/stable/company-screener

Both routes relate to screening companies, but the change includes the endpoint name: stock-screener becomes company-screener. Replacing only /api/v3/ with /stable/ would leave you with a different path from the one currently documented.

A current request for a page of technology companies can look like this:

https://financialmodelingprep.com/stable/company-screener?sector=Technology&limit=100&page=0&apikey=YOUR_API_KEY

Replace YOUR_API_KEY with the key for your account. This request specifies the technology sector, asks for up to 100 results, and starts at page 0. Access remains subject to the permissions and limits associated with the account.

The request also illustrates why you need to compare parameters separately from the path. The page parameter controls which group of results is requested; the sector filter controls which companies qualify. Changing the endpoint name does not automatically update either part of the surrounding code.

Once you have a current request, compare the response fields your project actually uses. If a spreadsheet depends on a particular column or a script reads a named field, confirm that the current response supplies what it expects. A successful request is only the first check; the returned data must also fit the calculation or display that follows.

Use the Changelog to Understand a Specific Change

The changelog is most useful when you know what differs and want to understand the change. It can help establish when a parameter appeared, why a response contains additional information, or whether a particular endpoint received an update.

It does not replace the current endpoint reference. A short update may describe what was added without repeating every supported parameter or response field. Use the change history to understand the difference, then return to the endpoint page for the request you intend to make.

Three examples show why it is worth identifying the type of change before editing code.

Pagination changes how results are retrieved

FMP added pagination to the Stock Screener endpoint, allowing results to be requested by page. An older article may show a single request because it used a smaller screen or predated that option. A newer example may include page because it is designed to collect a larger result set.

When retrieving larger screener results by page, keep the screening criteria consistent as you move through the results. For the request above, the next page uses page=1 while retaining the same sector filter and limit. If the research requires every matching company, the first page alone does not establish that the screen is complete.

Optional parameters can add detail to the same endpoint

The Earnings Calendar offers a different example. Setting includeReportTimes=true requests additional reporting-period, confirmation-status, and estimated report-time information through the existing endpoint.

https://financialmodelingprep.com/stable/earnings-calendar?includeReportTimes=true&apikey=YOUR_API_KEY

Two examples can therefore show different amounts of earnings detail while using the same route. One may request the additional reporting-period and timing information, while the other omits that option. Comparing publication dates or URL prefixes alone would miss the reason for the difference.

Check the complete request before concluding that a field is unavailable or that the endpoint has been replaced. Optional parameters can affect what comes back, and the current documentation should guide how those options are used.

A new field does not necessarily require a new route

FMP's addition of senateID gives Senate records a senator-level identifier. An older example may not include that field even though its broader purpose, such as examining disclosed trades, remains relevant.

The field name is senateID, including its capitalization. If a project will use it to connect records, that exact name matters. The useful check is whether the field is available in the endpoint and records being used, rather than whether an older article happened to display it.

These examples involve different changes: a way to retrieve more results, an optional request setting, and an added response field. None should be treated as proof that every older example needs a new URL.

Older FMP Articles and Code Can Still Be Useful

An older example should not be discarded simply because the URL looks different. It may explain why a dataset was selected, how a calculation was structured, or what the author was trying to achieve. A repository can also show how an existing application handles results, storage, or presentation.

Those lessons can remain useful even when the request syntax has evolved. The problem starts when historical implementation details are copied into new code without checking whether they still apply. Preserve the analytical reasoning, then verify the endpoint and fields on which it depends.

For inherited applications, the legacy documentation can help identify the original request. However, access to legacy route details requires sign-in and an eligible account. Finding an old URL in an article does not establish that a new account can use it.

A working legacy request also does not answer every maintenance question. Before deciding whether to keep or replace it, establish whether the route remains supported for the account, whether FMP has documented a relevant change, and which parts of the application would be affected.

If a legacy documentation link redirects to a current endpoint page, do not treat the redirect alone as confirmation that the requests behave identically. Compare the documented request details and clarify any unresolved access or support question before changing the application.

What to Do When an Old Example and the Current Docs Disagree

The first step is to isolate the disagreement. It might be the endpoint path, a parameter name, a response field, pagination, or simply an article showing an abbreviated result. Write down the specific difference before making changes.

A short comparison keeps the task manageable:

Difference	What to check
Different endpoint path	The complete current path, including the endpoint name
Different parameter name	The accepted name, value format, and whether it is required
Additional response fields	Whether they are optional, newly added, or simply omitted from the older example
Different pagination	Page settings, result limits, and how subsequent pages are requested
Older route in existing code	Account eligibility, documented support, and the effect of replacing the request

Do not create a hybrid request by taking the old path and adding parameters from the new example. That can produce a request neither source documents. For new work, start with the current endpoint and add the options listed for that endpoint.

For an existing implementation, test a proposed replacement separately before changing the working request. Keep the company, filters, reporting period, and other relevant settings comparable. Then check the fields and calculations the application depends on, rather than assuming that two responses serving the same general purpose will have identical structures.

If the discrepancy concerns a field, first determine whether the field is absent from the actual response or merely absent from the article's example. If it concerns the number of results, check pagination and filters before treating the difference as a coverage problem. These checks can resolve the issue without replacing the whole request.

An explicit authentication or access error requires a separate check. Address API-key and account-access questions before interpreting a failed request as evidence that the endpoint has changed.

When the Documentation Does Not Settle the Question

Sometimes the current endpoint page and relevant change history still leave a specific question unanswered. You may need to confirm whether an account can use an older route, whether a field is expected under particular parameters, or whether a documented request is behaving as intended.

In that situation, contact FMP support with the two examples and the exact difference. Include the documentation URLs, endpoint paths, request parameters, and the response or error you received. Explain whether you are creating a new request or maintaining an existing integration.

Remove the API key from copied URLs, headers, screenshots, and logs before sharing them. A precise question, such as whether a named parameter applies to a particular route, gives support more to work with than a general report that two examples look different.

Keep a Reference for the Request You Use

Once you have resolved the difference, retain the current documentation link alongside the request in your project notes. Record the endpoint, the parameters you selected, and any response fields your calculation depends on. If a particular changelog entry explains a decision, keep that link as well.

That small record helps the next person understand why the request looks different from an older article or repository. It also gives you a starting point if the same question returns later. You can review the part that changed without reconstructing the entire history of the integration.

FAQs

Why do different FMP articles show different API URLs?

Articles and repositories can preserve routes that were used when they were created. Current documentation may show a different endpoint name or request structure. For a new integration, use the current endpoint reference and compare the complete request rather than only its version label.

Which FMP documentation should I use for a new project?

Start with the current API documentation. Find the endpoint for the dataset you need, then check its parameters, authentication requirements, response information, and access conditions.

Can I replace /api/v3/ with /stable/ in an older URL?

Do not assume that is sufficient. The stock-screener example changes from /api/v3/stock-screener to /stable/company-screener, so the endpoint name changes too. Other request details must be checked against the current endpoint page.

Does a response with more fields mean I am using a newer API version?

Not necessarily. An optional parameter can request more detail from the same endpoint, an update can add a field without changing the route, or an article may show only part of a response. Compare the request settings and actual response before deciding what changed.

Should I rewrite an existing integration because the endpoint looks different now?

Not automatically. Confirm the older route's availability for the account, review relevant changes, and test the proposed replacement against the application's requirements. A different URL alone does not establish the scope of work needed.

Why can I find an older route online but not see its details in the public documentation?

Legacy route details require sign-in and an eligible account. An older article or repository can remain publicly available even when its endpoint documentation is restricted. Check eligibility separately from whether the example exists online.

What if the changelog does not explain the difference?

Check the full current endpoint reference and confirm that the examples use comparable parameters. If the behavior or access question remains unresolved, send support the specific requests and response details with the API key removed.