Data handling

This page summarises how the Opis Nutrition API handles the data you send. Your contract and Data Processing Agreement (DPA) are the binding documents; contact opis for copies.

Roles

For the images, descriptions and items you submit, you are the controller and opis is your processor (UK GDPR / EU GDPR Article 28). We process that data only to provide the service to you, on your instructions.

Dietary data can reveal health information. We treat everything you send as potentially special-category data, and we recommend you do too.

No training on your data

We do not use your images, items, results or metadata to train or evaluate models — ours or anyone else's. Doing so would require a separate written agreement.

Minimise what you send

• Pseudonymous references only. external_id and confirmed_by must be opaque references, not names, email addresses or phone numbers. confirmed_by values that look like an email address or phone number are refused.
• No identifiers in images. Avoid faces, name tags and receipts in meal photos.
• Metadata stays with us. metadata is returned to you unchanged and is never sent to any model or sub-processor beyond our own hosting.
• We strip image metadata. EXIF, GPS and camera serial numbers are removed on upload, and filenames are never stored. See Uploading images.
• Webhooks are thin. Event payloads carry identifiers and status, never nutrients or metadata.

Retention

Your organization has a retention class, set in the console's Settings (owners and admins).

Images are always kept while an analysis that uses them is waiting for confirmation (at most 7 days), even under zero, because the nutrition stage may need them. They are deleted on schedule when the workflow finishes.

Erasure on demand. DELETE /v1/meal-analyses/{id}, DELETE /v1/nutrition-estimates/{id} and DELETE /v1/files/{id} erase the resource, its images and results, including the copies held by the nutrition engine. Use them to honour your users' erasure requests.

Where data is processed

• The platform — API, databases, file storage, queues and the nutrition engine — runs on AWS in eu-west-2 (London), in an AWS account dedicated to this platform and isolated from opis's other systems.
• Image identification and food matching use OpenAI models. Request content (images and item names) is sent to OpenAI for inference. See the sub-processor list below.

Sub-processors

We give notice before adding or replacing a sub-processor, as set out in the DPA.

Audit trail

• Every workflow keeps an append-only timeline of its transitions — who confirmed, how, and when — without payloads (GET …/events).
• Results record the pinned pipeline release and profile hash that produced them.
• Console actions (keys created or revoked, members and roles changed, webhook changes, retention changes) are written to an append-only audit log, visible to owners and admins in the console.
• If opis staff ever need to look at your organization to resolve an incident, the access is read-only, time-boxed, needs a recorded reason, and appears in your audit log.

Security

• TLS everywhere; HSTS on platform.opis.health.
• API keys are stored as hashes; secrets are shown once. Keys sent in query strings are revoked automatically.
• Webhooks are signed (Standard Webhooks, HMAC-SHA256); signing secrets are encrypted at rest.
• Tenant isolation is enforced in the database with row-level security, and test data is separated from live data.

Not a medical device

The Opis Nutrition API provides nutrition estimates. It is not a medical device and must not be the sole basis for medical decisions without appropriate clinical oversight.