# Accessing session data Source: https://docs.poh.org/accessing-session-data This guide explains how to retrieve session data from the Proof of Human API. There are three primary methods to access your data: by specific session ID, by user ID, or by tag. A separate endpoint is available to retrieve the full event log for a given session. For more detailed information on the API specification, see the [API Reference](api-reference). ## Authentication All API requests require authentication using your secret API key: ``` Authorization: Bearer YOUR_SECRET_KEY ``` If you don't have a secret key, you can generate one on your [account page](https://app.poh.org/account). There are three methods to retrieve session risk scores and flags: ## Method 1: Retrieve a specific session When you need data from a specific session, use the session ID to retrieve detailed information: ``` GET https://api.poh.org/v1/sessions/{sessionId}/report ``` > **This route is also available using query parameters:**\ > `GET https://api.poh.org/v1/sessions/report?sessionId={sessionId}` ### Example request ```bash theme={null} curl -X GET https://api.poh.org/v1/sessions/abc123def456/report \ -H "Authorization: Bearer YOUR_SECRET_KEY" ``` Query parameter example: ```bash theme={null} curl -X GET "https://api.poh.org/v1/sessions/report?sessionId=abc123def456" \ -H "Authorization: Bearer YOUR_SECRET_KEY" ``` This returns the risk score, risk explanation, biometric checks, and device checks for the specified session. The session ID can be retrieved with `window.getRoundtableSessionId()` in the browser. ## Method 2: Retrieve all sessions for a user To retrieve all sessions associated with a specific user: ``` GET https://api.poh.org/v1/users/{userId}/sessions ``` > **This route is also available using query parameters**\ > `GET https://api.poh.org/v1/users/sessions?userId={userId}` ### Example request ```bash theme={null} curl -X GET https://api.poh.org/v1/users/user-123/sessions \ -H "Authorization: Bearer YOUR_SECRET_KEY" ``` Query parameter example: ```bash theme={null} curl -X GET "https://api.poh.org/v1/users/sessions?userId=user-123" \ -H "Authorization: Bearer YOUR_SECRET_KEY" ``` This returns an array of session data for the specified user. Each entry is an object consisting of the session data for that user. While in beta, this endpoint is limited to the most recent 100 sessions. ## Method 3: Retrieve all sessions for a tag To retrieve all sessions associated with a specific tag: ``` GET https://api.poh.org/v1/tags/{tag}/sessions ``` ### Example request ```bash theme={null} curl -X GET https://api.poh.org/v1/tags/tag-123/sessions \ -H "Authorization: Bearer YOUR_SECRET_KEY" ``` This returns an array of session data for the specified tag. Each entry is an object consisting of the session data for sessions that include the given tag. While in beta, this endpoint is limited to the most recent 100 sessions. ## Retrieving the event log for a session The methods above return risk scores and flags. To retrieve a detailed log of every action a user took during a given session, use the events endpoint: ``` GET https://api.poh.org/v1/sessions/{sessionId}/events ``` ### Example request ```bash theme={null} curl -X GET https://api.poh.org/v1/sessions/abc123def456/events \ -H "Authorization: Bearer YOUR_SECRET_KEY" ``` This returns the full event log for the specified session, including the total event count and each event's action and timestamp. ## Next steps * Visit the [Dashboard](https://app.poh.org/account) to generate a secret key. * Review our [API Reference](api-reference/session-data) for detailed endpoint specifications. # Getting session events Source: https://docs.poh.org/api-reference/events-data GET /v1/sessions/{sessionId}/events Get the chronological list of user events recorded during a specific session # Getting session data Source: https://docs.poh.org/api-reference/session-data GET /v1/sessions/{sessionId}/report Get the risk score, risk explanation, biometric checks, and device checks for a specific session ID. The `user_logs` field is also included for backward compatibility but is deprecated — use the [`/v1/sessions/{sessionId}/events`](/api-reference/events-data) endpoint to retrieve a session's event log. # Getting tag data Source: https://docs.poh.org/api-reference/tag-data GET /v1/tags/{tag}/sessions Get the 100 most recent sessions that include a specific tag # Getting user data Source: https://docs.poh.org/api-reference/user-data GET /v1/users/{userId}/sessions Get the 100 most recent sessions for a specific user ID # Best practices Source: https://docs.poh.org/best-practices This page contains recommendations for getting the most out of Proof of Human. This will help you deploy Proof of Human effectively, calibrate your risk thresholds, and maintain your detection pipeline over time. ## Deploy the tracker on as many pages as possible Proof of Human is designed to run on every page of your application. The more pages you track, the more behavioral data is collected, and the more accurate your risk scores become. Unlike traditional CAPTCHAs that create a single checkpoint, continuous cross-page tracking makes it much harder for bots to game your system by temporarily "acting human". Pages with text input fields are especially valuable — typing is one of the best signals for distinguishing humans from bots and AI agents. ## Gather data before gating Place the tracker as early as possible in the user journey and check risk scores as late as possible, ideally checking at the moment of a critical action like a survey submission, account creation, or payment. This gives Proof of Human the maximum amount of behavioral data to work with before you need to make a decision. The longer a session runs before you call the API, the more confident the risk score will be. ## Start with recommended risk score thresholds As a starting point, we recommend the following thresholds: * **70 and above:** Auto-block or reject the action. This range has a high likelihood of bot or fraudulent activity. * **50–70:** Flag for manual review or require additional verification (e.g., email confirmation, a secondary check). * **Below 50:** Allow the action to proceed. ### Adjust thresholds based on sensitivity These defaults work well for most use cases, but you should adjust them based on your tolerance for false positives and false negatives. High-sensitivity workflows (such as highly paid surveys, financial transactions, or password resets) should use lower thresholds, while lower-stakes actions can afford higher ones. ## Start in monitor-only mode and set initial thresholds Before enforcing any automated blocking rules, we recommend running Proof of Human in observation mode for a period. This just means adding the tracker to your site or project and letting data accumulate without acting on it. You can then review sessions in the [Dashboard](https://app.poh.org) or retrieve them via the [API](/accessing-session-data) to calibrate your thresholds against real traffic. ### Adjust thresholds over time Your thresholds and rules should evolve as you learn more about your traffic patterns. Regularly review blocking rates and false positive reports in the dashboard, and adjust your thresholds accordingly. What works at launch may need tuning as your user base or threat landscape changes. # Changelog Source: https://docs.poh.org/changelog Latest updates and improvements to Proof of Human. ## August 2026 Added a Visitor IDs page to the dashboard that provides summaries and recent histories for each visitor. Updated the visitor ID fingerprinting model to reduce false positives when identifying duplicate devices. Added the most common visitor IDs to the route and tag summaries to identify potential duplicate sessions and participants. ## July 2026 Added `visitor_id` to the session, user, and tag API endpoints and to the session details modal on the dashboard. The visitor ID is a fingerprint of the user's device and browser. Sessions with the same visitor ID likely came from the same device, even if the user ID differs. Added the ability to filter sessions by flag directly on the dashboard. Clicking a flag in the flags detected table opens the session list filtered to sessions where that flag fired. Improved the visibility of the dashboard by adding new visualizations and metrics on the main dashboard page. ## June 2026 Released the `external_input` biometric flag, which detects when a user left the survey tab and pasted input after returning — a signal that responses may have been generated outside the survey. Added the ability to customize the weight of each flag in the risk score calculation on the dashboard. Released the `programmatic_clicking` biometric flag, which detects when user clicks were made programmatically rather than through natural user interaction. ## May 2026 Increased the weight of the `agent_behavior` flag in the risk score calculation. Added the `software_renderer` device check, which flags sessions where the browser is using a software-based graphics renderer (e.g. SwiftShader or llvmpipe) instead of hardware acceleration — a common signal of remote, virtualized, or headless browser environments. Added `recommended_action` to the API and dashboard, providing a suggested action based on the session's risk score. ## April 2026 Added the [events endpoint](/api-reference/events-data) for retrieving the full chronological event log for a session. The `user_logs` field on the session, user, and tag endpoints is now deprecated and will be removed soon — use the events endpoint to fetch session events instead. Updated the `all_pasted` flag to flag on the first paste event instead of waiting for 5 or more pastes. Added a new visualization to session reports to show and explain bot-like scrolling behavior. Added a new visualization to session reports showing click positions for the session. ## March 2026 Released the `agent_behavior` flag, which uses a machine learning model fine-tuned on AI behavior to identify agents and bots to improve predictions. Added the ability to attach tags to each session, and the [Tag API](/api-reference/tag-data) for retrieving tag data. Added summaries for each tag on the dashboard, providing an at-a-glance overview of tag-level data. Added the ability to filter sessions by tag or route directly on the dashboard. Fixed a bug in the `roundtable:ready` event to ensure the session ID is available when this event fires. ## February 2026 Released the `centered_clicks` flag, which detects when a user makes perfectly centered clicks with no natural variation — a signal commonly associated with automated or bot-driven interactions. Added summaries for every route visited during a session on the dashboard, giving a quick overview of user navigation patterns. ## January 2026 Released the `jump_scrolling` flag, which detects when a user scrolls in large jumps with no intermediate or continuous scroll events. Added device and browser information to the dashboard, making it easy to see what device and browser each session used. Added automated action chunking on the dashboard, which groups actions together for easier review of session activity. # Decipher integration Source: https://docs.poh.org/decipher This guide shows how to add Proof of Human to a Decipher (Forsta) survey so that every respondent is tracked throughout their survey. ## Before you start Decipher only makes API calls to whitelisted domains. Contact Forsta support and ask them to whitelist `https://api.poh.org` for your account. ## Loading the tracker Add the following as a top-level element in your survey XML. Placing it at the top level loads the tracker on every page, so behavior is tracked across the entire survey. Replace `YOUR_SITE_KEY` with your site key from the [Integration script](https://app.poh.org/account/integration) page on the Proof of Human dashboard: ```xml theme={null} ``` ## Capturing the session ID To retrieve a respondent's data later, you need their session ID. Add the following ` ``` This gets the session ID with `window.getRoundtableSessionId()` and makes it available server-side as `p.client_roundtable_session_id`. Attach this code to a question the respondent answers and submits — not to a terminal or exit page. ## Retrieving session data The question code above saves the session ID to `p.client_roundtable_session_id`. To pull the risk score and flags for a respondent back into your survey, call the session report endpoint from a Decipher API node. Place this after the last page you'd like to track. ### 1. Call the report endpoint ```xml theme={null} p.Params1 = dict(sessionId=p.get('client_roundtable_session_id', '')) p.Headers1 = dict(Authorization="Bearer YOUR_SECRET_KEY") ``` Pass the captured session ID as the `sessionId` query parameter, and your secret key as a `Bearer` token in the `Authorization` header. You can get your secret key from the [Secret keys](https://app.poh.org/account/api-keys) dashboard page (it starts with `sk-`). Make sure not to put your secret key in client-side JavaScript — it belongs only in the server-side `` and `` blocks. ### 2. Save the response After calling the API, Roundtable\_API.r holds the parsed JSON response. Read the fields you want to track and store them in a hidden text question: ```xml theme={null} def to_ascii(v): if isinstance(v, unicode): for a, b in [(u'\u2014', '-'), (u'\u2013', '-'), (u'\u2011', '-'), (u'\u2018', "'"), (u'\u2019', "'"), (u'\u201c', '"'), (u'\u201d', '"')]: v = v.replace(a, b) return v.encode('ascii', 'replace') return v rt_data.d1.val = Roundtable_API.r.get('risk_score', 'NA') rt_data.d2.val = to_ascii(Roundtable_API.r.get('risk_explanation', 'NA')) rt_data.d3.val = to_ascii(Roundtable_API.r.get('recommended_action', 'NA')) Roundtable risk data risk_score risk_explanation recommended_action ``` The API returns the risk score (0–100), risk explanation, recommended action, biometric checks, and device checks for the session. For the full response shape and all available fields, see the [API Reference](api-reference/session-data). # How Proof of Human works Source: https://docs.poh.org/how-it-works The Proof of Human API provides continuous bot and fraud prevention without adding friction for your users. We solve this by combining two independent signal streams: 1. **Behavioral analytics** analyze user interaction patterns such as typing cadence, mouse velocity, scroll rhythm, and touch gestures. A machine learning model evaluates these signals together to detect automated agent behavior. The ML model only runs on Desktop sessions (Windows, macOS, Linux). 2. **Device & network intelligence** checks for virtual machines, VPNs, datacenter ASNs, headless browsers, and similar flags. These streams feed real-time models that generate a single risk score that continuously updates throughout the user session. ## How we're different from CAPTCHAs Traditional CAPTCHA products evaluate risk at a single moment and then stop collecting data. *Challenge-based CAPTCHAs* (puzzles such as reCAPTCHA v2 or classic hCaptcha) trigger once, usually on form submit. They see only how the user solves the puzzle; after the token is issued, tracking ends until the next challenge. *Score-based CAPTCHAs* such as reCAPTCHA v3 or hCaptcha Enterprise run silently on page load or API call and the score you receive reflects that snapshot alone. Any behavior that happens later in the session is invisible. The Proof of Human API is designed to stay active across the entire user session, with our risk signal improving as the user keeps interacting. If the session spans multiple pages, our tracker can automatically stitch data from each page together, giving you a single uninterrupted view of the session. ## Where to integrate Proof of Human For single-page applications (SPAs), place the script tag in `index.html` so it loads once and tracks the entire app session. This root-level integration is the ideal way to ensure every interaction is captured. Beyond SPAs, add the tracker to any pages where you see fraud, spam, or abuse, as well as pages that sit immediately upstream: * App screens with forms, payments, or account actions * Demo or lead-gen forms if they attract bot submissions * Landing pages only when you need a quick pre-filter ### Automatic session stitching As long as the user remains in the same tab, Proof of Human keeps a stable session ID, even across route changes in an SPA or full navigations to separate pages. We use this ID to continuously stitch the session data together and give you an up-to-date risk score at any point during the session. *** Next steps: see our [Integration Guide](integration) for more details on adding our tracker to your app or page. # Integrating Proof of Human Source: https://docs.poh.org/integration This guide shows how to integrate Proof of Human’s bot detection suite into any web app. ## Quick start ```html theme={null} ``` The Proof of Human tracker dispatches a **`roundtable:ready`** event on `window` as soon as it is done loading. Block 2 listens for that completion event so you can safely call `window.setRoundtableUserId` once the tracker is loaded. ### Script‑tag attributes The tracker recognizes three data‑attributes that let you tailor the tracker's behavior: * `data-site-key` (required) – Your workspace’s site key (find it in the [Dashboard](https://app.poh.org)). * `data-user-id` (optional) – A stable identifier for a logged‑in user to track them over multiple sessions (a hashed value is fine). * `data-tags` (optional) – A comma-separated list of tags that will be associated with this session. Tags help you group and organize sessions. ## React / SPA example The Proof of Human tracker exposes two functions to manually set extra tracking information. These are useful in React or single-page apps. ```ts theme={null} window.setRoundtableUserId(uid); window.setRoundtableTags(["my_tag_1", "my_tag_2"]); ``` First, add the Proof of Human tracking script in `public/index.html`: ```html theme={null} ``` Then wire the user ID in React: ```ts theme={null} // useRoundtableUid.tsx import { useEffect } from 'react'; export const useRoundtableUid = (uid?: string) => { useEffect(() => { if (!uid) return; const send = () => { if (window.setRoundtableUserId) { window.setRoundtableUserId(uid); return true; // tracker ready } return false; // not yet }; if (send()) return; // ran instantly window.addEventListener('roundtable:ready', send, { once: true }); return () => window.removeEventListener('roundtable:ready', send); }, [uid]); }; ``` Call the hook in your auth/provider component; it runs every time `currentUser` changes, so it sets the UID immediately on page‑refresh and again right after a fresh login. ```tsx theme={null} const { currentUser } = useAuth(); useRoundtableUid(currentUser?.uid); ``` ### Using the Session ID Every page‑view (or SPA session) gets a unique **session ID** that can be retrieved with `window.getRoundtableSessionId()`. You can reference this ID to pull risk scores and data from the session in your back end. ```js theme={null} // Access the session ID anywhere in the front end const sessionId = window.getRoundtableSessionId(); console.log('Roundtable session:', sessionId); ``` Because the session ID is stored in *sessionStorage*, the value is scoped to the current tab and cleared automatically when the tab is closed. ### Next steps * Visit your [Account](https://app.poh.org/account) to access your data site key. * Learn about [Accessing Session Data](accessing-session-data) to retrieve risk scores and session data. * Learn how to [Integrate the Proof of Human badge](using-the-badge) on your site # Welcome to Proof of Human Source: https://docs.poh.org/introduction Proof of Human is the world's best bot detection platform. We use advanced behavioral analyses and device checks to help software teams quickly identify and mitigate bot activity. ### Quick start To start using Proof of Human, follow these steps: 1. **Integrate the tracker**: Add our JavaScript tracker to your site with a single line of code: ```html theme={null} ``` 2. **(Optionally) add more tracking info**: Specify the `data-user-id` or `data-tags` parameter to help track users beyond individual sessions. See our [Integration Guide](integration) for more info. 3. **Get session data**: View detailed session data on the [Dashboard](https://app.poh.org) or via our API: ``` GET https://api.poh.org/v1/sessions/{sessionId}/report ``` ### Privacy and data handling Proof of Human is designed with privacy first. All data stays in‑tab for the life of the visit. ### The Proof of Human badge The Proof of Human badge is a small, drop-in widget that indicates whether Proof of Human is running on the page. You are free to include this on any page you are tracking. See [Using the Proof of Human Badge](/using-the-badge). ### Next steps 1. [Book a demo](https://poh.org/book-a-demo) with our sales team to get started with an account. 2. Explore our [Integration Guide](integration) for detailed implementation instructions. 3. Review the [API Reference](api-reference/session-data) for more details on risk scores, sessions logs, biometric checks, and device checks. If you have any questions or need assistance, contact us at [support@poh.org](mailto:support@poh.org). # Privacy & Legal Source: https://docs.poh.org/privacy Privacy, security, and legal information for Proof of Human users. > Proof of Human is committed to protecting your data and ensuring compliance with global privacy regulations. ## Data Collection Proof of Human collects and processes the following types of data: * **Behavioral Data**: Mouse movements, keystroke dynamics, scroll patterns, focus changes * **Technical Data**: Browser information, device characteristics, network details, session metadata * **User Data**: Session identifiers, risk assessments, fraud indicators, activity logs ## Data Handling Our data handling practices include: * **Storage**: End-to-end encryption, secure cloud infrastructure, regional data centers * **Processing**: Real-time analysis, automated risk scoring, behavioral pattern matching * **Retention**: Configurable retention periods, automatic data deletion, data minimization ## Legal Documents > [Terms of Service](https://app.poh.org/terms) | [Privacy Policy](https://app.poh.org/privacy) | [Data Processing Agreement](https://app.poh.org/data-processing-agreement) ## Compliance Proof of Human maintains compliance with: * **Security Standards**: SOC 2 Type 1 * **Privacy Compliance**: Our Data Processing Agreement (DPA) ensures compliance with GDPR, CCPA, and other global privacy regulations ## Support > For privacy or legal inquiries, contact [legal@poh.org](mailto:legal@poh.org) # Qualtrics integration Source: https://docs.poh.org/qualtrics This guide shows how to add Proof of Human to a Qualtrics survey so that every respondent is tracked throughout their survey. ## Setting up the tracker The simplest way to load Proof of Human across your whole survey is through the **Look and Feel** settings. This injects the tracker on every page so you don't have to add it to individual pages. 1. In **Survey Flow**, add an **Embedded Data** element at the top of the flow and create a field named `__js_ROUNDTABLE_SESSION_ID` with no value. The `__js_` prefix is required (see the note below). 2. Open your survey and go to **Look and Feel** → **General** → **Header**. 3. Click the source/HTML (`<>`) button to edit the header as raw HTML. 4. Paste the following, replacing `SITE_KEY` with your own site key from the [Integration script](https://app.poh.org/account/integration) dashboard page (the public key starts with `pub-`). ```html theme={null} ``` The `data-tags` value (`tag1,tag2`) are placeholders — replace it with your own comma-separated tags, or remove this line if you don't need tags. Proof of Human script pasted into the Qualtrics Look and Feel header `RESPONDENT_ID` is the embedded data field holding your identifier for the respondent (for example, a panel or participant ID passed in the survey link). Replace it with whichever field holds your identifier (or leave it blank if you don't have a respondent ID). **The `__js_` prefix is required.** To set embedded data from JavaScript, Qualtrics requires the field declared in **Survey Flow** to be prefixed with `__js_`, while the call to `setJSEmbeddedData` uses the name without the prefix (`"ROUNDTABLE_SESSION_ID"`). ## Retrieving session data The script above saves the current session ID into the `__js_ROUNDTABLE_SESSION_ID` embedded data field. To pull the risk score and flags for a respondent back into your survey, you can call the session report endpoint from a Qualtrics Web Service task. ### 1. Call the report endpoint with a Web Service Proof of Human exposes the session report through a query-parameter route: ``` GET https://api.poh.org/v1/sessions/report?sessionId=${SESSION_ID} ``` In **Survey Flow**, add a **Web Service** element at the end of the survey and set it as follows: * **Method:** `GET` * **URL:** `https://api.poh.org/v1/sessions/report` * **Query parameter:** `sessionId` = `${e://Field/__js_ROUNDTABLE_SESSION_ID}` * **Header:** `Authorization` = `Bearer YOUR_SECRET_KEY` You can get your secret key from the [Secret keys](https://app.poh.org/account/api-keys) dashboard page for the `Authorization` header (the secret key starts with `sk-`). Don't put your secret key in the survey's Look and Feel header or any client-side JavaScript. ### 2. Save the response to embedded data The API returns the risk score, risk explanation, recommended action, biometric checks, and device checks for the session. To save any of these fields into embedded data, add them to the **Embedded Data** section of the Web Service element. Set the name and value for each field to match the JSON path of the field in the API response. For example: * **risk\_score** = `risk_score` * **biometric\_checks.programmatic\_typing** = `biometric_checks.programmatic_typing` Qualtrics Survey Flow with the embedded data field and Web Service element For the full response shape and all available fields, see the [API Reference](api-reference/session-data). # Status Source: https://docs.poh.org/status # Using the Proof of Human badge Source: https://docs.poh.org/using-the-badge Proof of Human's verification badge is a small, drop-in widget that shows whether Proof of Human is running. It auto-renders wherever you place `
`, listens to your tracker’s events, and gracefully handles SPAs and back-navigation. Note that the badge does *not* display any results related to risk score. Instead, it determines success or failure based on whether the Proof of Human tracking is working correctly. Proof of Human badge ## Quick start We recommend adding the tracker and the badge script on the same page, with the badge script after the tracking script: ```html theme={null}
``` After importing the badge script, the badge can be added anywhere by adding a div with the class `roundtable-badge`: ```html theme={null}
``` ## Styling The badge renders inside a Shadow DOM, so your site’s CSS won’t break it (and vice-versa). By default, the badge is collapsed to show just the logo. On hover (or tap, on touch devices), it expands its width to reveal the "Proof of Human" text and links. ## State At any given time, the badge is in one of three states: * **Loading:** shows a spinner and an animating progress bar while the tracker initializes and verifies Proof of Human is running. * **Pass:** displays a check icon. This indicates that Proof of Human is running and gathering user data. * **Fail:** displays an X icon in red. This indicates that Proof of Human is not running. See also: * [Integrating Proof of Human](integration) for adding the tracker * [Accessing Session Data](accessing-session-data) for using the session ID and scores # Using the dashboard Source: https://docs.poh.org/using-the-dashboard The [Dashboard](https://app.poh.org) provides a central location to view all session data, investigate individual user sessions, and manage your Proof of Human account settings. ## Viewing session data Click on `Sessions` in the left-hand navigation bar to see a table of all recorded sessions. By default, this table lists: * **Session ID** – The unique identifier automatically generated by Proof of Human * **User ID** – The user identifier you provided (if any) * **Risk Score** – The numerical risk score (0-100) generated by Proof of Human * **Visitor ID** – A fingerprint of the user's device and browser; sessions with the same visitor ID likely came from the same device. * **Risk Explanation** – A brief description of why the risk score was assigned to the session * **Session Duration** – How long the session lasted * **City** – The user's city (inferred from their IP address) * **Country** – The user’s country (inferred from their IP address) * **Status** – Live or Complete, depending on whether there was any user activity within the last 30 minutes Biometric checks * **Agent behavior** – An ML model detected patterns across biometric data consistent with automated behavior. The ML model only runs on Desktop sessions (Windows, macOS, Linux). * **Programmatic typing** – The user enters text in an extremely consistent way, consistent with programmatic entry * **Teleporting mouse** – The user's cursor jumps large distances with no intermediate movement * **No corrections** – A large amount of text is entered without any backspaces or correction events * **All pasted** – All text is pasted or entered all-at-once * **Jump scrolling** – The user scrolls in large jumps with no intermediate or continuous scroll events * **Centered clicks** – User made perfectly centered clicks with no natural variation * **Programmatic clicking** – User clicks were made programmatically rather than through natural user interaction * **External input** – User left the survey tab and pasted input after returning Device checks * **Bot** – The browser fingerprint matches known automation frameworks such as Selenium and Playwright * **Virtual machine** – Signals suggest the browser is running in a remote, virtualized, sandboxed, or software-rendered environment * **Software renderer** – The browser is using a software-based graphics renderer (e.g. SwiftShader or llvmpipe) instead of hardware acceleration, which may suggest a remote, virtualized, or headless browser environment * **VPN** – The user's IP address belongs to a commercial VPN or hosting provider * **TOR** – The user's connection is routed through a Tor exit node * **Location spoofing** – The user's browser-reported GPS coordinates conflict with the IP-inferred location ### Viewing session details Click on any session row to open a Session Overview modal. Here, you can view the risk scores, risk explanation, complete user action log, and biometric and device checks. Session Detail Modal ## Demo workspace If you want to see Proof of Human in action before fully integrating, switch to the **Demo workspace** on the left-hand account dropdown menu. This workspace is pre-populated with example sessions so you can explore the full feature set before setting up your production environment.