> ## Documentation Index
> Fetch the complete documentation index at: https://docs.fingerprint.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Troubleshooting Unexpected Usage Spikes

> If you're seeing a sudden spike in Fingerprint usage, it usually comes down to two main causes: implementation issues or malicious traffic. This guide will help you quickly diagnose and resolve the issue.

## Quick Checklist

* **Check for recent code changes** - Spikes often correlate with a recent deployment. Review any updates that may have changed when or where the Fingerprint agent is called.
* **Check for caching** - Without caching, repeat visits or user actions can trigger multiple identification requests. Ensure visitor IDs are cached appropriately using `sessionStorage` or `localStorage`.
* **Audit for duplicate calls** - Look for React `useEffect` calls missing dependency arrays, or code that triggers `get()` multiple times per session.
  * The JavaScript agent only bills for `get()` calls. Confirm you’re calling it only when the visitor ID is needed, and not on every page load or render.
* **Review the "Insights" section** - On the [Overview](https://dashboard.fingerprint.com/overview) page of your Fingerprint dashboard, adjust the trend chart by selecting the "events per visitor" metric in the drop down. A noticeable increase could indicate your code is sending more identification requests than before.
* **Inspect Smart Signals** - Use the [Smart Signals](https://dashboard.fingerprint.com/smart-signals) page to check for bot activity. Spikes caused by "bad bots" suggest abuse, not implementation error.
* **Secure your API key** - Check if your API key is used on unknown domains or apps. Set up [request filtering](/docs/request-filtering) to block unwanted domains, headers, or IPs.
* **Contact support** - If you’re still unsure, reach out to [Support](https://fingerprint.com/support/) or review our [bill forgiveness](/docs/billing#how-am-i-protected-from-overpaying) policy.

## Implementation Related Spike

These spikes are usually caused by integration issues. Clues include a spike following a recent code change or usage increasing alongside user activity. For example, if usage scales with traffic but seems higher than expected, it may indicate an implementation issue - such as more identification calls per user than intended. Common causes include missing caching, duplicate calls, or unintentional triggers.

### Missing Visitor ID Caching

* Without caching your visitor ID, each page load or user action can generate a new request, increasing your API usage.
* Choosing whether to cache depends on your use case and risk tolerance:
  * If your use case demands highly accurate identification, we recommend identifying the visitor [only when needed](/docs/identify-visitors#timing-identification-requests) and always using a fresh visitor ID *without* caching.
  * For less sensitive scenarios, caching can significantly reduce redundant calls and improve performance.
* You can store the visitor ID in `sessionStorage` (recommended) or `localStorage` to reuse the ID for up to 1 hour and reduce redundant calls.

Read: [Caching Visitor ID](/docs/identify-visitors#caching-the-visitor-id)

### Duplicate Calls from Loops

* Common in single-page applications (SPAs) where component re-renders or navigation triggers extra calls.
* In React, missing a dependency array in `useEffect` can cause `get()` to be called on every render.
* Use the [React SDK](/docs/react) to manage this more easily.

### Unintended Calls to Fingerprint

* For the JavaScript agent, `start()` requests are not billed, but `get()` requests are.
  * Only call `get()` when the visitor ID will be used by your application.
* Avoid triggering identification on every render or page view.
* Visit the [Optimizing JavaScript Agent Usage](/docs/optimize-javascript-agent#only-use-the-javascript-agent-where-you-need-it) page to learn more about common use cases and when to make the `get()` request.

## Malicious Traffic or Bot-Driven Spike

These spikes often happen suddenly and without any recent deployments. Look for unusual traffic patterns - like bursts of activity or off-hour usage. Use Smart Signals or the Server API to review recent identification events. A high number of “bad bot” detections typically points to automated abuse, not an integration issue.

### Bot Traffic

* Visit the **Smart Signals - [Bot detection](https://dashboard.fingerprint.com/botd)** page to view traffic flagged as bots.
* A sudden increase in "bad bots" can indicate scraping or automated abuse.
* Use this information to adjust filters or rate-limiting rules in your app.

Some helpful resources to learn more:

* [Browser Bot detection](/docs/bot-detection/overview)
* [Bot detection: How to block bad bots in 2025](https://fingerprint.com/blog/bot-detection/)
* [How to Identify and Block Bots in Your Firewall](https://fingerprint.com/blog/bot-detection-powered-application-firewall/)
* [Mitigating bad bots at WAF level through Cloudflare](/docs/cloudflare-integration-blocking-ips-and-origins)

### Public API Key Misuse

* Public API keys are visible in client-side code and can potentially be leaked or copied.
* Check whether your API key is being used on unknown domains or in unauthorized mobile apps.
* It’s good practice to restrict your API key to only the domains, headers, or IP addresses where legitimate traffic is expected.
* Set up [**Request Filtering**](https://dashboard.fingerprint.com/traffic-rules) in the dashboard to prevent unwanted usage and protect your billing.

Protect your Public API key:

* [Request Filtering for Websites](/docs/request-filtering-for-websites)
* [Mobile App Filtering](/docs/mobile-app-filtering)
* [Search Bot Filtering](/docs/search-bots-filtering)
* [Network Filtering](/docs/network-request-filtering)

## Deep Dive: Exporting and Analyzing Identification Data

If you want to dig deeper into a spike, exporting your data to CSV allows for a more granular investigation. Here's how:

1. **Check usage trends** - Go to the [Overview](https://dashboard.fingerprint.com/overview?period=last_30_days) page and review API usage over the past 30 days.
2. **Identify the spike window** - Pinpoint the spike date, and include the day before and after.
3. **Filter identification events** - Navigate to the [Identification](https://dashboard.fingerprint.com/events) page and apply a date filter for that window.
4. **Export the data** - Use the export option to download a CSV file of events.
5. **Analyze usage patterns** - Use the CSV to review the data grouped by:
   * `identification.visitor_id`
   * `linked_id` or `tags`
   * `url`
   * `ip_info.geolocation.country_name`

This can help surface unusual usage patterns, like excessive requests from a single user or unexpected geographies.

## Next Steps and Support

* If you can’t resolve the issue on your own, please reach out to [support](https://fingerprint.com/support/).
* You may be eligible for partial [bill forgiveness](/docs/billing#how-am-i-protected-from-overpaying) in cases of unintentional spikes or confirmed malicious activity.

**Important:** Forgiveness can only be applied to your **most recent completed invoice** (i.e. the last completed billing cycle). Older invoices are not eligible, even if they experienced a spike.

***

[Billing and account limits explained](/docs/billing)