Reference
Data handling
What happens to a recording sent to the hosted API, stated as the system's technical behaviour. Whether a deployment meets a given jurisdiction's requirements is a compliance assessment made with the partner, not a claim this page can make.
API v1 · docs 1.0 · updated 2026-09-22
A recording’s life
| Uploaded bytes | Parsed from a temporary file and discarded. Never written to storage. |
|---|---|
| Parsed record | Kept so later calls can name it by cpet_id. Deleted 24 hours after upload by default. |
| Longer retention | Only when the caller asks (retain_hours), up to 168 hours. retain_hours: 0 expires it immediately. |
| Where it lives | Amazon Web Services, region eu-central-1 (Frankfurt, Germany): the service on AWS App Runner, parsed records and models in Amazon S3. AWS is the only infrastructure provider that holds uploaded data. |
| Encryption | HTTPS in transit. AES-256 server-side encryption at rest. Public access to the storage is blocked. |
| Deletion on demand | DELETE /v1/cpet/{id} or the MCP tool delete_cpet, at any time. |
| After expiry | The record reads back as CPET_NOT_FOUND. Expired records are swept hourly. |
| Isolation | Records are partitioned per API key. One key cannot read another’s uploads. |
| What persists | A monthly count of analyses per API key, with the key’s name and a timestamp. It holds nothing from any recording. Logs record the record id, the detected format and the byte count, never file contents or filenames. |
| Results | Returned to the caller and not stored server-side. |
| Failed parses | An unreadable file returns a structural probe (byte and delimiter counts) that carries none of its content. |
| Upload URLs | One-shot, valid 5 minutes, carrying their own credential, so a script that posts a file handles no API key. |
Training data
Nothing a customer uploads enters the training corpus. There is no path from the service’s storage into it: the corpus is built only from files supplied for research and loaded by hand.
Research cohorts shared under a data transfer agreement are pseudonymised before they enter the corpus, and what a contributed dataset may then be used for is chosen in that agreement, use by use: evaluation only, representation learning without labels, supervised training, generative models, or nothing at all.
Identifiers
Oxynet needs no patient identifiers, and none should be sent. CPET exports routinely carry the patient's name in the filename and the file header: remove names and dates of birth before uploading. A neutral filename is enough for most formats, since Oxynet ignores the name and never stores the bytes. Agents connected over MCP are instructed to say this before every upload and never to go looking for files on their own.
Sharing a research dataset rather than using the service is covered by a data transfer agreement: our template, or yours.
When data must not leave the institution
The hosted API sends recordings over HTTPS to app.oxynet.net. For environments where that is not acceptable, the same engine can be deployed on the partner's infrastructure or embedded in a product. That is scoped with each partner, not a self-service option: see deployment options or ask about it.
Regulatory status
Read this
Oxynet is research software. It carries no CE mark and no FDA clearance, is not registered as software as a medical device in any jurisdiction, and must not be the basis of a diagnosis or treatment decision.
No certification or regulatory compliance is claimed on this page. Deployment-specific requirements (data protection, hosting location, clinical use) are evaluated with the partner concerned.
Not yet documented
Access logging and standard processor terms (Annex B of the data transfer agreement). Hosting, encryption and deletion are stated above and in Annex C of the agreement.