Skip to main content
The Dashboard allows you to stay on top of integration health, by informing you of required SDK updates, and monitoring throttling, latency, and error rates.

​
Health overview

The Health page gives you a high-level view of your Fingerprint setup, surfacing issues that need attention and pointing you to where to fix them. To check it out, visit Dashboard > Health.
Clean Shot 2026 06 09 At 14 15 40@2x
Three status widgets at the top of the page highlight anything that needs your attention:
  • Throttled requests (1) shows the total number of requests throttled in the current period, along with the API keys responsible. Each key links to its API key details, where you can adjust the RPS limit or investigate the traffic pattern.
  • Webhooks (2) shows your webhook failure rate and the webhooks with the most recent delivery failures. Each entry links to its delivery logs.
  • SDK versions (3) shows how many SDK updates are available across your integrations. Each entry shows the current version and the latest available version, and links to corresponding library page for the full breakdown.
When everything is healthy, each widget shows a neutral state - no action needed. Below the widgets, a single timeline chart (4) lets you switch between three views using the dropdown:
  • API Latency show the average latency for JavaScript agent requests, in 5-minute buckets. This is the time it takes a Fingerprint identification request to return data from the server. Only requests from client-side JavaScript SDKs are counted.
  • API Errors shows requests that timed out or returned an error, including both client and server-side errors from the JavaScript agent.
  • Webhook Failed Calls shows webhook delivery failures over time, broken down by webhook endpoint.

​
API key monitoring

For Public and Server API keys, you can view detailed monitoring information on the key details page. To check it out, visit Dashboard > API keys and select a key to view its details.
Clean Shot 2026 05 28 At 14 55 12@2x
The key details page shows when the key was last used, by which library version, and on what origin domains or mobile apps. Two charts give you a closer look at how the key is being used:
  • The Request usage chart shows incoming identification requests using this API key, broken down into:
    • Success - successful requests with response HTTP 200
    • Throttled - requests over the configured RPS limit, responded with HTTP 429
    • Restricted - requests filtered out by request filtering rules or that exceeded workspace/environment limits, responded with HTTP 403
  • The Server-side latency chart shows percentiles for the average time to process identification requests. Client-side signal collection latency is not included.

​
Webhook monitoring

For each registered webhook, you can view a log of every delivery attempt by clicking into the webhook on the Webhooks page. To check it out, visit Dashboard > Webhooks and select a webhook.
Clean Shot 2026 05 28 At 14 53 33@2x
The Webhook events page lists each delivery attempt with:
  • Request ID - the identification request this delivery is associated with
  • Visitor ID - the visitor ID from the event payload
  • Status - whether the delivery succeeded or failed
  • Status code - the HTTP response code returned by your endpoint
  • Date - when the delivery was attempted
Clicking on a request row will expand it, so you can inspect the full request and response when diagnosing why a delivery failed. For details on retry behavior and the expected response contract, see Webhooks > Timeout and errors.

​
Outdated libraries

The Libraries & integrations page shows you a detailed view of all SDKs in use across your integrations, including both web and mobile SDKs as well as Server API SDKs. To check it out, visit Dashboard > Libraries & integrations.
Clean Shot 2026 06 09 At 14 19 38@2x
Each row in the Libraries list shows:
  • The library (e.g. JavaScript, Next.js, Node.js, iOS) and where it runs (Website, Server, or App)
  • The number of requests in the last 24 hours
  • The version in use, and the latest version available
Libraries are refreshed once every 24 hours.

​
Per-library health

Clicking an active library opens its Health tab, which gives you a detailed view of where that SDK is running and which deployments are out of date.
Clean Shot 2026 06 09 At 14 22 14@2x
At the top of the page, four summary cards show:
  • The latest version of the library
  • The number of outdated origins out of the total observed
  • Total requests in the selected window
  • How many of those requests came from outdated versions
Below the summary, the origins table lists every domain (for web SDKs) or app (for mobile SDKs) where this library is running:
  • Origin - the domain or app ID
  • Version - the SDK version in use, or a “Multiple” label when more than one version is detected
  • Requests - the number of identification requests from this origin in the selected window
  • Last request - timestamp of the most recent request
  • Severity - whether the origin is up to date, or how far behind it is
Domains For web SDKs, clicking a domain row expands it to show the specific URLs observed on that domain and the SDK version detected on each. When more than one version appears on the same URL, each version is listed with its own request count, so you can see whether stale clients are still trickling in or whether a deployment really is out of date. Mobile apps Mobile apps often have multiple SDK versions in use at once, since users update apps at different rates. Each version is shown with its request count so you can see the adoption of your latest release. Activity Below the origins table, the Activity chart shows total request volume over time, with errors and timeouts called out separately. This helps you spot whether an outdated origin is also experiencing reliability issues.