Privacy Policy

Last updated: August 29, 2026

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 follows Google Cloud’s documented zero data retention requirements by not using Gemini features that require additional prompt or output retention, such as Grounding with Google Search, Grounding with Google Maps, or Gemini Live session resumption. The remaining exception is Google abuse-monitoring prompt logging that applies 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, but is turned on by default in most integrations. 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. Without the full PIN, including the numeric suffix, the stored payload cannot be decrypted.

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

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, 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.
• 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 extraction_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 extraction_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.webapp, 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 and is used transiently where required for public rate limiting and abuse controls.

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. BiomPIN records are encrypted at rest using a zero-knowledge design: the numeric PIN needed to derive the encryption key is not stored on the server, and patient name/initials plus patient ID are excluded from the stored encrypted payload.

This zero-knowledge model applies to stored BiomPIN records. It does not mean the service cannot see data during active processing, but that plaintext processing context is discarded immediately after processing is complete.

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 that form with only the extraction request ID, app version, and a question about what was incorrect or missing. Opening it does not send a message. No report, extracted measurements, patient identifiers, filename, or BiomPIN is attached or prefilled. Please do not enter patient identifying information in your message.

Selecting Send Message sends the name, email address, and message you provide through Web3Forms to the BiomAPI developer. Contact messages are separate from analytics; giving a rating does not require your name or email. Ratings are voluntary user reports, not a measured extraction accuracy rate; an unrated result is not treated as correct.