How to Keep Your FMP API Key Private in Spreadsheets, Notebooks, and Apps

Your first FMP request works. You copy the URL into a notebook, paste it into a spreadsheet, screenshot the result, or add the project to GitHub.

The financial data in the response may be public, but the API key inside the request is not. Your key authorizes requests through your account and can be used to access the datasets available under your plan and consume your usage allowance.

The FMP API documentation supports two ways to authorize a request. You can send the key in a request header or include it as an apikey parameter in the URL. Both methods work, but either can expose the credential if the request is copied into something other people can inspect.

Most accidental exposures are ordinary mistakes. A key gets committed to GitHub, left in a notebook output, embedded in a spreadsheet formula, captured in a screenshot, or placed directly in browser-side code. Avoiding those mistakes does not require an elaborate security setup. It requires keeping the key separate from anything you plan to share.

Key Takeaways

• Treat your FMP API key as a private account credential, even when the financial data you retrieve is public.
• Keep the real key outside source code, notebooks, spreadsheets, screenshots, and other material you may publish or share.
• Use environment variables or a platform's secret-storage feature when available.
• Do not place a private API key in browser-side code. A visitor can inspect requests made from the browser.
• If your key is exposed, replace it from the FMP dashboard immediately, remove the public copies, update your projects, and review your recent usage.

What You Can Share Safely

An FMP API key authorizes requests against your account. It should not be treated like a ticker, date, endpoint name, or another example parameter.

A request header may contain apikey: YOUR_API_KEY. A URL-based request may look like https://financialmodelingprep.com/stable/profile?symbol=AAPL&apikey=YOUR_API_KEY.

The placeholder YOUR_API_KEY is safe to publish. Your actual key is not.

Information	Safe to publish?	Reason
FMP endpoint	Yes	It identifies the requested dataset
Public ticker	Yes	It identifies a security
Example parameters	Yes	They show how the request is structured
YOUR_API_KEY placeholder	Yes	It is not a working credential
Actual API key	No	It authorizes requests through your account
Complete URL containing your key	No	The credential remains visible in the URL

Public documentation for the Company Profile Data API or historical end-of-day prices can be linked and shared directly. A tutorial can also show a complete request structure as long as it uses a placeholder.

When your software supports header authorization, using a header can reduce the chance that the key appears in a copied URL, browser history, screenshot, or routine URL log. It does not make the key public-safe. The header still needs to be stored outside shared code and protected from logs or debugging output.

Before sharing any file, URL, image, or project, ask one question: Can someone who receives this see my actual FMP API key?

If the answer is yes, replace it with a placeholder or remove it from the shared material.

Keep Your API Key Out of GitHub

A working script often begins with the key written directly into the request. That may be acceptable for a quick private test, but it becomes a problem when the file is committed to a repository.

The safer approach is to separate the reusable code from the account-specific credential.

Project item	What it should contain
Source code	Endpoint, parameters, and instructions for reading the key from private configuration
.env or another private settings file	The actual API key
.gitignore	An instruction telling Git not to track the private settings file
.env.example	A placeholder showing where a user should add their own key
README	Setup instructions using YOUR_API_KEY, never the live credential

Add the private settings file to .gitignore before the first commit. A .gitignore entry prevents Git from adding an untracked file, but it does not remove a file that has already been committed.

GitHub recommends using environment variables or secret-management tools instead of writing credentials directly into source code. Hosted platforms may also provide their own secret settings for deployed projects.

Before making a repository public, search the entire project for the actual key. Check:

• Source files
• Notebooks and saved outputs
• Configuration files
• Test and example files
• README files
• Screenshots
• Logs and exported results
• Previous commits and branches

Removing the key from the latest version of a file may not remove it from Git history. If a live key was committed at any point, replace the key first and then address the repository copy.

A public repository should show readers how to use FMP without giving them access to your account credential.

Check Both Notebook Code and Saved Output

Notebooks create two possible exposure points: the instructions in a code cell and the output saved after that cell runs.

A cell may print a complete authenticated URL while you are troubleshooting a request. You can later remove the key from the code and still leave it visible in the saved output. When the notebook is uploaded or shared, that output travels with it.

A safer notebook setup loads the key from a private environment variable or the notebook platform's secret-storage feature. If the platform does not offer secret storage, you can enter the key through a hidden prompt each time the notebook starts rather than saving it in the notebook.

Before sharing a notebook:

1. Search every code cell for the actual key.
2. Search text cells, comments, and configuration variables.
3. Clear outputs that display URLs, headers, or request details.
4. Restart the notebook and confirm it works without a stored key.
5. Save, close, and reopen the final file to inspect what another person will receive.

Google Colab users can store a credential in the notebook's Secrets area and allow the notebook to retrieve it when needed. Local Jupyter users can load it from a private environment setting. In either case, the public notebook should contain only the name of the secret, not its value.

Clearing visible output is important, but it does not make a previously exposed key private again. If the notebook was already public or sent to someone with the key inside it, replace the key.

Treat Shared Spreadsheets as Shared Files

Spreadsheets can hide a key even when the visible dashboard shows only prices, company names, and calculated metrics.

The key may appear in:

• API formulas
• Hidden sheets
• Helper cells
• Named ranges
• Query or connection settings
• Scripts attached to the workbook
• Configuration cells
• Previously saved copies

Hiding a row, sheet, or formula does not protect the credential from someone who can inspect or copy the workbook. It only removes the value from the main view.

If a spreadsheet contains the key and makes FMP requests directly, keep the workbook private. When another person only needs the results, share a values-only copy, CSV export, or PDF that does not contain the underlying request.

If the workbook must remain interactive, use one of these approaches:

• Have each authorized user enter their own API key.
• Use a spreadsheet integration that stores credentials outside visible cells and formulas.
• Retrieve the data through a private service that makes the FMP request and sends only the permitted result to the workbook.
• Share the workbook only with trusted users who are allowed to access the same project and credential.

A workbook that leaves your control should not contain a key you expect to remain private. This is especially important for templates, client deliverables, classroom files, and spreadsheets posted for public download.

Before sharing, search formulas, inspect hidden sheets, review named ranges and connection settings, and check any scripts attached to the workbook. Then open the shared version as the recipient would see it.

Inspect Screenshots, Tutorials, and Recordings

Source files are not the only places where credentials appear. A screenshot can expose an API key just as easily.

A browser screenshot may capture the key in the address bar. A terminal image may include an authenticated request. A spreadsheet screenshot may show the formula bar, while a notebook image may include the key in a code cell or output.

What you share	Where the key may appear
Browser screenshot	Address bar or developer tools
Terminal screenshot	Command, error message, or request output
Notebook screenshot	Code cell, output, or configuration cell
Spreadsheet screenshot	Formula bar, cell, or connection settings
Dashboard screenshot	Settings, request details, or browser tools
Screen recording	Any URL, command, setting, or output shown during the recording

Use a placeholder when preparing the example whenever possible. If you must edit an existing image, cover the full credential and inspect the final exported image at its original size before publishing it.

Tutorials require the same review. Check the article text, code examples, screenshots, downloadable files, sample notebooks, and repository history. A placeholder such as YOUR_API_KEY gives readers all the information they need without exposing your account.

Screen recordings deserve extra care because a key may appear for only a few seconds. Review the full recording, including setup steps, error messages, browser tabs, and developer tools.

Do Not Put a Private Key in Browser-Side Code

A local notebook and a public browser application do not have the same security boundary.

In a local project, your computer makes the FMP request. In a browser application, the visitor's browser may make the request. If the browser needs your key to send the request, the visitor can generally inspect it through the application code or browser tools.

Changing the variable name does not protect it. Encoding or splitting the value across several client-side files does not protect it either. The browser must reconstruct the credential before making the request.

A public web application should generally send the user's request to a server you control. The server reads the FMP key from private configuration, makes the authorized request, and returns only the information the application is allowed to display. The visitor's browser never receives the key.

The same principle applies to mobile or desktop applications distributed to users. A credential embedded inside an application package may be extracted. If the application must use one private account credential, keep that credential on a server rather than distributing it with the application.

Protecting the key addresses credential security, but it does not determine whether FMP data may be redistributed. A public website, client dashboard, or customer-facing app also needs the appropriate commercial-use permission for its users, datasets, and delivery method.

What to Do If Your FMP API Key Is Exposed

Once a key has appeared in a public repository, shared file, screenshot, tutorial, or browser application, stop treating it as private. Deleting the visible copy does not prevent someone from using a key they already copied.

Use this recovery process:

1. Replace the key immediately. Sign in to the FMP dashboard, open API Keys, and use the refresh button next to the existing key. The current replacement instructions are available in the FMP account FAQs.
2. Remove the exposed copy. Delete it from the public page, screenshot, shared file, notebook output, application, or repository.
3. Address repository history when necessary. If the key appeared in Git, removing it from the latest file may leave it in earlier commits. GitHub explains how to handle sensitive data stored in repository history. Rotate the key before spending time rewriting history.
4. Update your trusted projects. Replace the old key in private environment settings, notebook secrets, spreadsheet connections, scheduled jobs, and server configuration. A running project may stop working until it receives the new key.
5. Search for other copies. Check branches, backups, exports, logs, old notebooks, shared workbooks, screenshots, documentation, and downloaded project folders.
6. Review recent account activity. The FMP dashboard shows API usage and bandwidth activity, which can help you identify an unexpected increase after an exposure.
7. Contact FMP support if needed. Use the FMP Help Center if you cannot replace the key, see activity you do not recognize, or need help securing the account.

Rotating the key is the most important step because it stops the exposed value from remaining the credential your projects use. Cleaning up the public copy is still worthwhile, especially when it appears in a document or repository that other people may continue to view or copy.

A Simple Checklist Before You Share

The safest routine is to decide where the real key will live when you create the project. Keep that location separate from any file you expect to publish.

Before you...	Confirm that...
Publish source code	No live key appears in code, configuration, tests, examples, or history
Upload a notebook	No key appears in cells, saved outputs, comments, or settings
Share a spreadsheet	No key appears in formulas, hidden areas, scripts, or connections
Post a screenshot	No key appears in the address bar, formula bar, terminal, or browser tools
Publish a tutorial	Every example uses a placeholder
Deploy a public app	The key remains in private server configuration
Share a project folder	Private settings and old exports are excluded

A free FMP account can serve as a controlled project sandbox while you test endpoints and decide which workflow is worth developing. The same security rules apply during that early stage. Keep the endpoint and request structure in the project, but keep the credential in private configuration.

Keep the Key With the Account

An API key is easy to protect when the safe routine becomes part of the project from the beginning.

Store the key separately. Use placeholders in examples. Inspect the full artifact before sharing it. Keep authenticated requests out of public browser code.

If a key becomes visible, replace it promptly and remove the old copies. That routine works for a spreadsheet, a notebook, a GitHub project, and a public application without turning a small FMP project into a complicated security exercise.

Frequently Asked Questions

What is an FMP API key?

An FMP API key is the credential used to authorize requests to the Financial Modeling Prep API. It allows requests to use the datasets and usage allowance available through the associated account.

Where can I find my FMP API key?

FMP provides the key through the account dashboard. If you have not set up an account yet, the FMP account creation process explains how to register and find your account details.

Should I send my key in a header or in the URL?

FMP supports both methods. A header can reduce the chance that the key appears in browser history, copied URLs, screenshots, and routine URL logs, but the credential must still be stored privately.

Is it safe to commit an FMP API key to GitHub?

No. Store the key in an ignored local settings file, environment variable, or secret-management tool. Public code should contain a placeholder and instructions for users to supply their own key.

Can a Jupyter notebook expose my key?

Yes. The key can remain in code cells, printed URLs, saved output, comments, or configuration variables. Check the notebook's code and stored output before sharing it.

Can I use an FMP API key in a spreadsheet?

Yes, if the workbook and its credential remain private. If the workbook will be shared, remove the key from formulas, hidden sheets, scripts, named ranges, and connection settings, or provide a static values-only version.

Is it safe to put an FMP API key in browser JavaScript?

No private key should be placed in browser-side JavaScript. A visitor can inspect the code or network request. Keep the key on a server and return only the permitted data to the browser.

What should I do if I expose my FMP API key?

Replace the key from the FMP dashboard immediately, remove the public copies, update your trusted projects, search for other exposures, and review recent account usage. Contact FMP support if you see activity you do not recognize or cannot secure the account.

Can I publish FMP API examples without exposing my key?

Yes. Publish the endpoint, ticker, parameters, and request structure with YOUR_API_KEY as the placeholder. Readers can insert their own credentials when they test the example.