Should You Call the FMP API From the Front End, Back End, or a Serverless Function?

For a public application that uses your FMP API key, make the FMP request on the server. The browser can ask your application for data, while a backend service or serverless function keeps the key out of the code and requests that visitors can inspect.

The choice between a backend service and a serverless function depends on what the application already uses and what the request needs to do. Both can retrieve FMP data, apply access rules, and prepare a response for the interface. A personal browser experiment has different requirements, but its key is still visible inside that browser.

Key Takeaways

• Keep an application's shared FMP key server-side when other people use the product.
• A serverless function is a form of backend. It runs application code outside the visitor's browser.
• Access checks, request limits, caching, and error handling need to be implemented whichever server-side approach you choose.
• Permission to display or redistribute FMP data is separate from where the request runs.

Start With the Project

The same FMP endpoint can sit inside very different products. A personal research page might retrieve a company profile and display it immediately. A SaaS product might use the same endpoint while serving many users, and a financial dashboard might combine the response with historical prices and its own calculations.

The endpoint's purpose has not changed. What changes is who can access the application, who holds the credential, and how the application manages demand.

Approach	Who sends the request to FMP?	Where the key is used
Front end	The visitor's browser	In the browser, where it can be inspected
Backend service	Your application's server	In private server configuration
Serverless function	A function running on the hosting provider's infrastructure	In private function configuration

The two server-side options can keep the key private when configured correctly. Neither automatically limits what visitors can request or how often they can request it. Those rules belong in your application.

Before choosing, establish who will use the application, whether it uses one shared FMP key, and how much data it needs to retrieve. Also check whether an existing backend already handles user accounts and permissions. Adding FMP there may be simpler than creating a separate service.

When a Direct Front-End Request May Be Appropriate

A front-end call means the browser communicates directly with FMP. It sends the request, receives the response, and displays the result. Any credential it needs for that request is available within the browser environment.

For a personal experiment on a trusted local page, you may choose to test with your own key and accept that visibility. Keep the key out of files or templates that you share. If you want it outside the browser altogether, a small local server can make the FMP request and return the data to your page.

A password-protected page still exposes a browser-side API key to people who can use the page. A colleague or customer can inspect the requests made by their browser. When several people use a tool with one account credential, keeping the FMP API key private means keeping it outside the code, configuration, and responses sent to those users.

Browser access also depends on cross-origin request permissions, commonly called CORS. A request working in a local script does not establish that a webpage can read the same response. Browser compatibility and credential privacy are separate checks.

A Back-End Request Gives the Application More Control

With a backend architecture, the browser talks to your application, and your application talks to FMP. The browser might send a ticker symbol to a company-data route on your server. Your application checks the request, uses its private key to contact FMP, and returns the information the interface needs.

Suppose your interface needs only five fields from a larger company profile response. The backend can select those fields, perform application-specific calculations, and return a response designed for the interface. The browser no longer needs to know how the FMP request is constructed.

This becomes more useful when the product has more than one interface. A web application may need company data, a mobile application may need the same information, and an internal dashboard may need a different view of it. They can all use the same application service.

A backend can also retrieve historical prices, calculate returns, and send the chart only the values it needs. FMP supplies the underlying data; the application performs the calculation. Keeping that distinction clear helps users understand which values came from the provider and which were calculated by the product.

For a small project, the backend might consist of one route that retrieves a profile and returns selected fields. If the application later changes which FMP endpoint it uses, the front end may continue using the same application route. That can make changes easier to manage without replacing the interface.

Serverless Functions Provide the Same Server-Side Role

A serverless function runs on a hosting provider's infrastructure. It can receive a request from the browser, contact FMP using a privately stored key, and return the permitted result. The provider manages the execution infrastructure, while you remain responsible for the function's code, configuration, and access rules.

Suppose a site has a search box where users enter a ticker. The front end can send that ticker to a serverless function. The function checks the input, makes the FMP request, and returns the relevant result.

This can be a practical fit for a site that needs a small amount of server-side work and does not already have a backend service. The front end remains responsible for the interface, while the function handles the FMP request. It can also be a permanent part of a larger application; growth alone does not require moving away from serverless.

The trade-offs depend on the platform. For example, AWS Lambda's function quotas govern execution time, memory, and simultaneous runs. Check the equivalent limits, expected response times, and charges for the platform you intend to use, especially if a request retrieves a large history or performs several data calls.

Shared caching also needs deliberate design. A value held in one function instance's memory is not a dependable, permanent cache for every instance. If multiple instances need the same saved responses or usage counters, provide a shared service that supports that purpose.

Serverless can scale the application's processing capacity, but it does not increase the FMP account's allowance. More simultaneous function runs can mean more simultaneous FMP requests. Your application still needs to manage that combined demand.

Protect the Route That Calls FMP

Your public application route can be called repeatedly even when its FMP key remains private. If it forwards every request to FMP without restrictions, someone can consume your allowance without seeing the key.

Apply access checks and input validation at that route, whether it runs in a backend service or a serverless function.

Control	What to implement
User access	Check sign-in and permissions where access is restricted. Public routes still need usage limits.
Allowed requests	Select the FMP endpoint on the server. Validate symbols, date ranges, and result limits; reject arbitrary destination URLs.
Request volume	Limit requests per user or visitor where practical, and control total requests sent through the FMP account.
Credential handling	Keep the key in private server settings and exclude it from browser responses, public files, and logs.
Response handling	Return only the fields the interface needs and that the application is permitted to provide.
Failures	Stop requests that take too long, limit repeated attempts, and return a clear error without credentials or internal details.

Caching can reduce repeat retrievals when the same data can be reused. Decide how long a stored response remains suitable for the workflow and how the interface will show its age. Keep user-specific results separate, and make sure storage and reuse fit the applicable agreement.

If FMP returns a rate-limit response, immediate repeated attempts can add to the problem. The API error guidance identifies a 429 response as too many requests and recommends reducing demand or adding a delay. Put that behavior in the application rather than relying on users to stop clicking.

No-Code and Hybrid Projects Need the Same Decision

A component labelled “API request” does not tell you whether the request runs in the browser or on the platform's servers. A visual builder may support either approach. Establish where the request executes and whether the credential is included in anything delivered to the user.

For a public application using a shared FMP key, use a server-side action or function with private credential storage. Confirm that the platform's “private” setting keeps the key out of the published page and its network requests. Also check who can invoke that action and what limits the platform lets you apply.

The same caution applies to spreadsheets and other hosted tools. Their interface may run in a browser while data retrieval happens elsewhere. The actual connection determines where the key is used.

A static website has another option when it does not need fresh data for each visitor. A private build or scheduled process can retrieve FMP data and publish a permitted snapshot. That avoids a live FMP call for every page view, but the published output needs a clear update time and the appropriate display rights. The key must stay out of the generated website files.

Check Display Rights Separately

Keeping the key outside the browser addresses credential exposure. It does not, by itself, authorize the resulting data display. The requirements for using FMP data in public apps and client dashboards depend on who receives the output and how they can use it.

FMP requires a Data Display and Licensing Agreement for displaying or redistributing its data. Confirm that the agreement covers the intended users, datasets, and delivery method. Internal business tools can also require commercial permission, so “private” should not be treated as equivalent to personal use.

Choose the Setup That Fits the Work

Once the shared key is kept server-side, choose between a function and a broader backend based on the application's existing services and workload. If the server-side requirement is small and each request can be handled independently, a serverless function may be enough. If the application already has a backend, keeping FMP there may be more coherent.

Project situation	Practical starting point
Personal local experiment	Test with your own key, understanding browser exposure, or use a small local server to keep it outside the browser.
Public site needing data on demand	Use a serverless function or backend with private credentials and request controls.
Site using periodic data snapshots	Retrieve data in a private build or scheduled process and publish only the permitted output.
Application with an existing backend	Add the FMP integration to that service where it fits the existing access and data controls.
Web, mobile, and internal interfaces sharing data	Provide a shared application API, implemented with backend services, serverless functions, or both.

Before sharing the application, check what a visitor can see and request. Confirm that the key remains private, that the server accepts only the intended requests, and that repeated use stays within your configured limits.

Frequently Asked Questions

Can I call the FMP API directly from the front end?

A direct browser request makes the API key visible within that browser. This may be acceptable for a personal experiment with your own key, but public or shared applications using one account credential should keep that key on a backend or serverless function.

Should I use a backend service or a serverless function?

If your application already has a backend that handles user accounts and permissions, adding FMP requests there is often straightforward. A serverless function can suit a project that needs limited server-side processing without a separate backend service. Both require private credential storage and appropriate request controls.

Does moving the FMP request to a server automatically make it secure?

No. Keeping the key private prevents visitors from receiving it, but they may still repeatedly call your application's public route. Validate incoming requests, check permissions where access is restricted, and limit how much activity the route can send to FMP.

Will a serverless function reduce my FMP API usage?

Moving a request into a function does not automatically reduce calls. Usage can fall when the application reuses suitable saved responses, avoids duplicate retrievals, or refreshes less frequently. Those behaviors need to be configured; serverless hosting does not provide them automatically.

Does a backend change whether I can display FMP data publicly?

No. Request location and data-display permission are separate matters. Your agreement must cover the intended users, datasets, and delivery method, including any public display, downloads, or redistribution. Keeping the key on a server does not change those requirements.