Privacy policy

Last updated: September 10, 2026

At a glance

Activity	Where the data goes
PDF or image processing	BiomAPI and Google Gemini; raw uploads are not retained by BiomAPI after processing
JSON validation or manual entry	BiomAPI, without a Gemini call
Phone-to-computer transfer	An encrypted browser-to-browser connection, with a disclosed relay fallback when needed
BiomPIN sharing	Temporary encrypted storage, excluding patient initials and ID; other report fields remain
Browser History and saved keys	Local storage on that browser/device

Removing initials and ID does not anonymize the full report. Read the details below before uploading or sharing patient data.

BiomAPI is an interoperability and data transport service for optical biometry data. It extracts, validates, normalizes, exports, and temporarily shares structured biometry data so users can move data between systems more easily.

BiomAPI is not a medical device. It does not diagnose, recommend treatment, calculate clinical decisions, or replace professional review. It does not intentionally alter clinical measurements; manual edits are user-directed, and automated processing is limited to extraction, validation, normalization, formatting, and transport.

LLM-based processing is not error free. BiomAI may misread a report, omit data, assign values to the wrong eye, misunderstand device-specific formatting, or produce otherwise incorrect structured output. Other processing modes are designed to be deterministic, but may still produce incorrect or unexpected results because of invalid input, user entry errors, schema constraints, software defects, or integration issues. In all scenarios, and especially when automated extraction is used, the user is responsible for independently reviewing and confirming the data before relying on it.

User responsibility

You are responsible for ensuring that you have the individual, institutional, contractual, and legal rights needed to upload and process any report or data submitted to BiomAPI. This includes obtaining any required consent, authorization, institutional approval, or other lawful basis; complying with local health-data and privacy rules; and anonymizing or redacting printouts before upload when required.

BiomAPI helps minimize stored identifiers, but it does not make an upload lawful by itself.

What BiomAPI processes

BiomAPI handles two input types:

Input	Processing path
PDF or image	BiomAI extracts structured data using Gemini
JSON	BiomJSON validates and normalizes the submitted structure

JSON inputs may be previously stored BiomAI results, user-edited results, manually entered data from the web app, device integrations, EHR exports, or other directly formed payloads. BiomDIRECT is not a separate processing engine; it is the provenance label used when the submitted or edited data was directly formed rather than extracted by BiomAI. BiomDIRECT data is still validated through BiomJSON.

Responses can include biometer details, patient demographics, eye measurements, optional notes, optional posterior keratometry, metadata, and optional BiomPIN information.

In ordinary processing responses and browser-local context, patient names are forcibly converted to all-caps initials/acronyms by the schema validator. For example, John Douglas Doe becomes JDD. This acronym and the patient ID are not stored in the BiomPIN database: before a BiomPIN payload is encrypted and stored, BiomAPI removes both patient name/initials and patient ID.

BiomAPI does not store raw uploaded files after processing. During live processing, the service necessarily sees submitted content in plaintext so it can validate files, call Gemini when BiomAI is used, build the response, and optionally create an encrypted BiomPIN record.

Phone upload

When enabled, Phone Upload uses a one-time QR code to pair a phone browser with the desktop browser. The QR pairing credential is placed in a URL fragment, is not included in the phone page’s normal HTTP request, and is removed from the phone address immediately after the page reads it.

BiomAPI’s WebSocket signaling service exchanges only temporary WebRTC connection metadata, including session timing, IP addresses, SDP descriptions, and ICE candidates. It does not receive the selected report or photo bytes, rejects binary WebSocket messages, keeps pairing state only in memory, and deletes the session when it succeeds, is cancelled, disconnects, or expires.

The file itself is transferred through an encrypted WebRTC data channel. Browsers first attempt a direct peer-to-peer connection. Cloudflare’s STUN service may process peer IP addresses and connectivity metadata while establishing that path. If NAT or firewall restrictions prevent a direct connection, Cloudflare Realtime TURN may relay the encrypted WebRTC packets. Cloudflare can then process the peer IP addresses, connection timing, and encrypted relay traffic needed to provide that service, but WebRTC encryption prevents the TURN service from reading the file content. The interface identifies whether the selected path is direct, relayed, or unknown when the browser exposes enough connection statistics.

When analytics is enabled for a deployment, BiomAPI records one privacy-minimized reliability event when a phone-upload session ends. It contains only the terminal outcome, session duration, the failure stage when applicable, whether relay fallback was available, an allowlisted technical failure reason when applicable, the direct, relay, or unknown transport classification, the UDP, TCP, TLS, or unknown relay protocol when a relay was used, the deployment environment, and the app version. Completed transfers also include the file size in bytes and client-measured connection-setup, transfer, and WebRTC send-buffer wait durations. It uses a generic phone-upload analytics identity and does not include participant IP addresses, pairing or session identifiers, QR URLs, filenames, MIME types, file dates, file hashes, SDP descriptions, ICE candidates, or file content.

BiomAI and Gemini

When BiomAI is used, the uploaded PDF or image is sent to Google Gemini with an extraction prompt so that it can return structured biometry data.

Server-managed BiomAI uses Google Cloud managed Gemini models through the Gemini Enterprise / Gemini Enterprise Agent Platform family of services. Google Cloud states in its Service Specific Terms and Cloud Data Processing Addendum that customer data is not used to train or fine-tune Google AI/ML models without the customer’s prior permission or instruction.

BiomAI does not use Grounding with Google Search, Grounding with Google Maps, or Gemini Live session resumption. Avoiding those features does not by itself establish zero retention: Google’s retention requirements also depend on applicable abuse-monitoring rules and project settings. Google abuse-monitoring prompt logging may apply to the deployment. Google also describes Gemini in-memory caching as not-at-rest storage, project-isolated, used only for performance, and subject to a 24-hour TTL.

If you provide your own Gemini API key, BiomAPI uses that key for the extraction request. BYOK overrides deployment-managed routing for that request and does not fall back to server-managed credentials if it fails. That BYOK processing path is governed by your own Google account, project, billing status, region, and data-processing terms, and responsibility for that part of the processing pipeline falls on you.

BiomPIN and browser storage

BiomPIN is optional through the API. The web app requests it for single reports, its dataset workflow enables it through Add to history by default, and the CLI enables it unless --no-pin is used. When requested, BiomAPI creates a temporary encrypted copy of the standardized response for later retrieval with a code such as lunar-rocket-731904.

BiomPIN uses a two-part design: lunar-rocket is the stored share ID, and 731904 is the numeric PIN, which is never stored. The encryption key is derived from the numeric PIN using Argon2id, and the payload is encrypted with AES-256-GCM. Retrieval derives the decryption key from the supplied numeric PIN. The service does not persist that PIN in BiomPIN storage.

Before a BiomPIN payload is encrypted and stored, BiomAPI removes patient name/initials and patient ID. A BiomPIN retrieved from another browser or device therefore returns the biometry data without those two identifiers.

The web app may restore patient context locally for convenience. Browser localStorage may contain BiomPIN history, patient initials/acronym, patient ID, BiomPIN expiry time, saved BiomAPI API key, saved Gemini BYOK key, and UI state. This data remains on that device/browser until cleared by the user, the browser, or app cleanup logic.

Integrations may pass patient context in a URL fragment such as #biomctx=.... URL fragments are not sent to the server in normal HTTP requests, but this fragment is reversible rather than encrypted. Anyone who receives the complete URL can decode the patient acronym and ID contained in it, and page scripts can access the fragment. Treat a complete URL containing #biomctx as patient-identifying data. Patient identifiers should not be placed in query parameters.

For web-app BiomPIN links and QR codes, choosing Anonymous beside the BiomPIN heading removes this fragment. Patient identity is selected by default for each result.

The standalone CLI can store BIOMAPI_KEY, GEMINI_API_KEY, BIOMAPI_URL, and ESCRS_IOL_CALCULATOR_URL in ~/.config/biomapi/config. The file is plain text. On POSIX systems, the CLI restricts the configuration directory to mode 0700 and the file to mode 0600; on Windows, access follows the user profile’s ACLs. Environment variables avoid persistent CLI configuration but may still be exposed to local processes or shell configuration, depending on the operating system.

BiomPIN records expire automatically after the configured expiry period, 744 hours or 31 days by default. Expired records are pruned when new BiomPIN records are stored. A BiomPIN record is also permanently deleted after the configured number of failed PIN attempts, 3 by default.

Logs and analytics

Persistent quota accounting

BiomAPI stores timestamped credit charges in its SQLite database so quotas survive server restarts. Each record contains a keyed hash of the quota bucket identity, its credit cost, and accounting timestamps. Raw client IP addresses, API user IDs, API keys, and report content are not stored in quota records. The stable hashing key is stored separately in the same database; these identifiers are pseudonymous, not anonymous.

Charges stop counting outside the rolling 24-hour window even if their records have not yet been deleted. Successful reservations opportunistically remove up to 1,000 expired records, at most once every five minutes per application process. Without further activity, expired records may remain until requests resume. Database backups and disk snapshots follow their own retention periods; deleting live records does not immediately remove those copies.

Operational logs and events

BiomAPI processes operational information needed to run the service, protect the API, troubleshoot issues, and enforce quotas. Depending on the operation and outcome, server logs may include the IP address, request ID, authenticated user ID when an API key is used, engine type, file extension, error category, device model/name, BiomAI processing time, and BiomAI token usage metadata.

Operational logs do not store raw uploaded files, response payloads, clinical measurements, patient demographics, patient names, patient IDs, notes, or model output.

BiomAPI analytics, when enabled for a deployment, use a small set of operational and user-action events:

• One biom_process event per processing attempt, with its outcome, engine, file extension, request ID, matching process_request_id, BiomPIN outcome, duration, and error category and stage when applicable. Successful BiomAI events can also include the selected service tier, credential source and backend, model, device name, token counts, retry count, LLM response time, and limited preprocessing diagnostics such as status, byte counts, PDF type, and page count.
• One biom_retrieve event per retrieval attempt, with its outcome, request ID, duration, device name on success, and error category when applicable. Successful retrievals also include the process_request_id stored in the decrypted BiomPIN payload so they can be correlated with the processing event that created the BiomPIN. Failed retrievals omit it when the payload cannot be decrypted.
• One biom_export event after a successful export, with the selected format set, response count, request ID, and duration.
• The terminal phone_upload_session event described in Phone Upload above.
• One biomai_feedback event when a user rates a BiomAI extraction as accurate or inaccurate through the web app or feedback API. It contains the rating as outcome, feedback HTTP request_id, and original process_request_id, with the deployment environment and app version. It uses a generic feedback identity, not an API user ID, and does not include report content or contact-form text. The process_request_id allows correlation with the existing processing event.

Processing and retrieval events include only the affected quota bucket’s cost, limit, usage after the attempt, whether credits were consumed, and, for rejected attempts, the limiting scope and retry delay. This makes quota use observable without sending periodic snapshots of every quota. Calls to the usage endpoint do not emit analytics events.

Processing, retrieval, export, and feedback events may include integrator_id, integrator_origin_host, or both. The first is a short, caller-declared client or integration identifier. Official clients conventionally use the reserved biomapi.* namespace: biomapi.biomweb, biomapi.cli, biomapi.browser-sdk-demo, and biomapi.biomfill. The namespace is not authenticated. A missing or invalid ID remains absent rather than being stored as unknown.

integrator_origin_host is the validated host from a declared logical integration origin when accompanied by a valid ID, otherwise from the standard browser HTTP Origin. It can therefore be retained without an integrator ID. It may be a domain, localhost name, browser-extension ID, or numeric IP literal when the page itself was served from a numeric address. BiomAPI does not retain the origin scheme, port, path, or the connecting client’s source IP in analytics.

These properties are soft operational attribution and can be spoofed by non-browser clients. They do not change request authorization, processing, quotas, billing, or other security decisions. Connection IP remains separate: public quota accounting stores a keyed hash as described above, while other abuse controls can use the address transiently. Operational logs may include the address as described in this section.

Authenticated API events use the configured API user ID as api_user_id and as a namespaced analytics identity, so activity remains attributable to the API account without sending the API key. Public API, export, feedback, and phone-upload events use deployment-level, non-person identities. They do not send the client IP as an analytics property, disable GeoIP enrichment, and do not create PostHog person profiles. All events include the deployment environment and app version.

Analytics events do not include raw uploaded files, response payloads, clinical measurements, patient demographics, patient names, patient IDs, notes, model output, filenames, raw Gemini keys, assigned credential secret values, or API keys.

Phone-upload reliability analytics follow the narrower limits described in Phone Upload above and are not tied to an HTTP request or IP-based analytics identity.

Security and deletion

BiomAPI uses HTTPS encryption in transit. Stored BiomPIN records are encrypted, and the numeric PIN used to derive the key is not persisted in BiomPIN storage. The service necessarily handles plaintext during processing and retrieval.

Wrong-PIN limits and record deletion protect online retrieval. They cannot protect a database copy already taken from storage; offline guessing remains possible, with Argon2 increasing the cost of each guess. See BiomPIN encryption and its limits.

BiomPIN records are temporary and expire automatically. They can also be destroyed by failed PIN attempts. Browser-local history and saved keys can be cleared from the web app or by clearing the browser’s site data.

Contact

For privacy, security, or compliance questions, contact the BiomAPI developer using the contact form on the website.

After a negative extraction rating, Let us know what went wrong. optionally opens a separate feedback form with a read-only Request ID plus required Name, Email, Biometer, and Message fields. Opening it does not send a message. When you select Send, Web3Forms sends an email whose subject and body contain the processing request ID and whose body also contains the values you entered. You may be contacted by email for follow-up. You can also explicitly choose to include a de-identified JSON snapshot of the original extraction. The exact JSON is shown in a read-only field before submission. Patient name, patient ID, date of birth, gender, exam date, free-text notes, BiomPIN information, and patient identity context (biomctx) are removed from that snapshot. The snapshot remains the original extraction even after editing. The original report is never included. Do not enter patient-identifying information in the message.

The general contact form remains separate. Selecting Send Message there sends the name, email address, and message you provide through Web3Forms to the BiomAPI developer. Contact and feedback emails are separate from analytics. Ratings are voluntary user reports, not a measured extraction accuracy rate; an unrated result is not treated as correct.