Privacy & GDPR¶

Kamerplanter is built on the principle of Privacy by Design. You have full control over your personal data: you can export, correct or have it deleted at any time. All data subject rights under GDPR Art. 15–21 are available as self-service features.

For Technical Users / Self-Hosters¶

This section is aimed at technical users and self-hosters. All GDPR features described below are available as REST endpoints under /api/v1/privacy/. Some of them are also directly usable in the graphical interface (see the relevant sections below); a few endpoints — objection, granting/revoking consent with a click, lifting a restriction, export status/download — are currently reachable only via the API. A logged-in session (bearer token) is required, except for GET /api/v1/privacy/policy and the two email-change endpoints that confirm via a token (confirm, revert).

curl -X POST https://<your-instance>/api/v1/privacy/export \
  -H "Authorization: Bearer <your-access-token>"

Opening Privacy Settings¶

Here's how to open the privacy area:

1. Click your profile picture or initials in the top right
2. Click Privacy in the menu

The privacy area has four tabs: Consents, Data Export, Delete Account and Restrict Processing.

Exporting Your Data (GDPR Art. 15 & 20)¶

You have the right to know what data the system has stored about you and to receive it in a machine-readable format.

Requesting a Data Export¶

1. Navigate to Privacy > the Data Export tab
2. Click Request Export
3. The interface confirms the request with its current status

The export then runs asynchronously in the background (takes 1–5 minutes depending on data volume); the resulting download link is valid for 72 hours.

The export contains the data Kamerplanter attributes to you as a person:

• your account: profile, sign-in methods, sessions, API keys (without the secret key itself), personal preferences, setup progress, favourites
• your memberships in gardens, invitations and your personal garden
• your privacy requests: consents, restrictions, erasure, export and email-change requests
• what you recorded: tasks and comments, diary entries, harvests and quality assessments, inspections and treatments, plant identifications and diagnoses, pest detections, attachments and contributed reference images, imports
• your conversations with the AI assistant, dismissed tips and the related logs
• notifications and their settings, calendar feeds, weather sources and manual device overrides
• your personal garden: sites with their GPS coordinates, beds and slots, plants, planting runs, all tasks, the diary and the details of photos and files (not the files themselves) — including entries other members created in your personal garden, but without their account identifiers.
• readings and logs of your personal garden: tanks with their measurements, fills and maintenance, watering and feeding logs, your sensors and their readings — the individual values of the last 90 days, hourly averages of the last 2 years and daily averages of the last 5 years. If a section holds more than 100,000 readings, it contains the newest and states how many older ones it leaves out; the hourly and daily averages cover the same sensor over the longer period. Readings the Home Assistant connection stored before 4 October 2026 are included as long as the sensor still exists in your garden. Notes and additional details that invited members left on these entries are included unchanged — you already see them in the app; the export does not name who wrote them.

In an organization (community garden), plants, locations and sensor data belong to the group, not to one person, so they are not part of your personal export — only your membership and what you recorded yourself. Location assignments hang off your membership; your garden's lead can show you which locations are assigned to you.

Changing Your Email Address (GDPR Art. 16)¶

You have the right to have your data corrected.

The Change Process¶

1. In account settings, go to the Profile tab and enter the new address in the Change Email Address section
2. Click Request Change and confirm yourself in the dialog — with your current password, if your account has one, otherwise via a fresh sign-in at your linked provider or, only for accounts linked exclusively to GitHub/Apple, via the code emailed to you
3. The interface confirms that a confirmation link was sent to the new address
4. Open the link in the email at the new address and click Confirm New Address there

For details on the form, see Account & Sign-In — Changing Your Email Address.

Like account deletion, the request is behind a step-up: your current password, if your account has one — otherwise a fresh sign-in at your linked provider, or, only if you sign in exclusively through GitHub/Apple, the confirmation code (see API documentation). Your current email address is notified as soon as the change is requested.

The new address becomes active only after the explicit click on Confirm New Address — merely opening the email confirms nothing. Once confirmed it becomes your sign-in address, and all active sessions are ended.

Undoing the Change¶

If the change wasn't made by you, or you want to take it back: your previous address receives an email with an undo link once the change is confirmed. It is valid for 7 days (default, configurable by the operator via RETENTION_EMAIL_CHANGE_REVERT_DAYS) and can be used once.

Opening the link shows what will happen and requires an explicit click on Restore Previous Address — merely opening the email confirms nothing here either. Afterwards:

• Your previous address becomes your sign-in address again — unless another account has since claimed it
• All sessions of the account are signed out, including on other devices
• A password-reset link sent to the new (now discarded) address becomes invalid
• A still-pending email change is also revoked
• Sign-in providers such as Google, GitHub or Apple that were newly linked to your account since the change was requested are unlinked again — your local password is unaffected
• API keys created since the change was requested are revoked — older API keys stay active
• If the change was made again and confirmed in the meantime, that confirmation's own undo link becomes invalid — a later revert can no longer override this restore
• The address this restore is now moving the account away from receives a fixed-text email about it

Once the revert window closes, the link no longer works — the previous address is then cleared from the change record (see Data Retention — Revert Window). If another account claims the previous address in the meantime, the page reports that (422) instead of performing the restore. If the account has since been closed and queued for deletion, the page reports that too (an error, not a success) — the link itself stays valid and unspent; contact the operator of the instance in that case.

Restricting Processing (GDPR Art. 18)¶

You can restrict the processing of your data for certain purposes — for example if you dispute the accuracy of your data or consider the processing unlawful.

1. Navigate to Privacy > the Restrict Processing tab
2. Enter the affected data scope (e.g. sensor_data, harvest_records, treatment_records) and choose a reason
3. Click Restrict

The created restriction then appears in the Active Restrictions list on the same tab. During a restriction the affected data is no longer actively processed.

Managing Consents (GDPR Art. 7)¶

No optional consent is needed for the core functions of the system. However, some additional features require your agreement.

Types of Consent¶

Error reports from your browser are asked for separately: if the operator has switched error tracking on, a notice with Accept all, Necessary only and Settings appears at the bottom on your first visit. Only once you consent to error analysis does your browser report crashes to the tracker — without form contents, cookies or email address. The decision applies to this browser. You can change it in the Consents tab with the switch Allow error analysis; it takes effect immediately, without a reload. In Light mode the notice does not appear and your browser reports no errors.

A password check against known breaches and a consent for external master-data enrichment are no longer in the list: the password check does not exist, and enriching species master data (GBIF, Perenual) sends species names only, no data about you. If you had granted either, the entry stays visible in your data export and is deleted with your account.

Revoking Consent¶

The Consents tab in the privacy area shows an overview of all processing purposes with your current status (Granted / Not granted) and, for required consents, a Required label.

Every granted optional consent has a Revoke button. One click revokes it immediately; the status changes to Not granted. Required consents have no such button.

Photo Identification (plant_identification)¶

Plant recognition by photo sends your image to Pl@ntNet (CIRAD/INRIA, France/EU) for analysis. Consent is required because the photo briefly leaves the Kamerplanter instance.

What happens when you revoke:

• All camera buttons are immediately hidden
• New photo requests are rejected with HTTP 403 (Full mode) or blocked in the browser (Light mode)
• Your identification history is retained (it contains no photos, only results)
• You can grant consent again at any time

Data flow when consent is active:

All EXIF metadata is removed before transmission to Pl@ntNet (GPS coordinates, camera model, capture time).

Cloud-Based Pest Detection (pest_detection_cloud)¶

Pest detection by photo sends your image — depending on the operator's configuration — either to a self-hosted recognizer (no consent required) or to the Kindwise plant.health cloud service. This consent is only required when the cloud adapter is active. As with plant identification, the photo is stripped of EXIF metadata before sending and is not stored permanently.

Photo Contribution to Plant Recognition (reference_contribution)¶

The Use as recognition reference switch when creating a plant is this consent: if you switch it on and save, Kamerplanter grants it before the photo is contributed. After review by the administrators, a numerical fingerprint (embedding) of the photo goes into the installation's shared recognition index; the photo itself is not stored and does not leave the installation. You revoke it here in the Consents tab. If it cannot be saved, Kamerplanter does not create the plant and shows an error. In Light mode the switch does not appear.

Photo Contribution to Pest Recognition (pest_reference_contribution)¶

A pest photo you contribute on the pest detail page first stays private in your garden. If an administrator makes it visible to everyone, it can additionally enter the installation's shared pest recognition index as a reference — but only with this consent. What is stored then is a numerical fingerprint (embedding) of the photo and its provenance (which contribution, which garden); the photo itself does not leave the installation. Without consent the promotion stays in the gallery, but the photo does not enter the recognition. In Light Mode nothing is ever indexed.

This consent is a purpose of its own and not an extension of "Photo contribution to plant recognition" (reference_contribution): if you shared reference photos of your plants before, you have not agreed to the pest index and need to consent anew. There is no place in the interface to grant it yet; you can grant it via POST /api/v1/privacy/consents with purpose: pest_reference_contribution and revoke it in the Consents tab.

AI Knowledge Question to the Knowledge Base (ai_knowledge_question)¶

When you ask a freely formulated knowledge question in the AI Assistant inside your garden, your text goes — attributed to your account — to the knowledge base and the language model connected to it. This consent is required for that. The text you type yourself is transmitted. Plant values (species, phase, substrate, EC/pH) are only included if you add them to the question yourself — then the consent "AI access to your plant data" (below) is required as well. Light Mode has no consents; the knowledge question works there without one.

This consent is a purpose of its own, not an extension of ai_tenant_data_access: granting "AI access to your plant data" earlier did not agree to the knowledge question.

AI Access to Your Plant Data (ai_tenant_data_access)¶

As soon as an answer is meant to use your specific plant context — for chat, future tip cards, the tip of the day, "why?" explanations, and a knowledge question to which you add plant values yourself — this consent is required. For a knowledge question without plant values, ai_knowledge_question (above) is enough.

Only master values are transmitted: scientific plant name, current phase, substrate, EC/pH readings, and aggregated counters (e.g. "3 overdue tasks"). Your name, e-mail address, and free-text notes from your plant diary are never transmitted.

AI Processing via Cloud Provider (ai_cloud_processing)¶

Required in addition to the previous consent when your instance uses an external cloud provider (e.g. Anthropic, OpenAI) instead of a locally run model (Ollama) for the AI Assistant — this is decided by the platform operator. Cloud providers may involve a third-country data transfer. Local providers do not need this consent.

For the knowledge question, what counts is the model the knowledge base answers with — the one the platform operator configured, not your garden's provider. If that is a cloud model, you need this consent in addition to ai_knowledge_question, and your garden must allow cloud providers; otherwise the question is refused before it leaves the instance.

Releasing Diary Entries for AI Analysis (diary_ai_analysis)¶

Lets you release individual diary entries, including free text and photos, for analysis. The analysis is performed by an AI agent that you operate yourself, which fetches the data using your own API key — Kamerplanter itself never calls a language model. Nothing is ever analysed automatically: you have to mark every single entry yourself. Only downscaled image renditions without capture location or device identifier are transmitted.

This path is independent of the ai_tenant_data_access consent above: ai_tenant_data_access covers only master values sent server-side to the knowledge base, and explicitly excludes free text from your diary. diary_ai_analysis is the only path through which diary content ever leaves a Kamerplanter instance at all — and even then it does not go to a service Kamerplanter operates, but to your own agent.

AI Disease Diagnosis (plant_diagnosis)¶

Analyses your leaf photo to produce a suspected-cause list for diseases and nutrient deficiencies — distinct from Pest Detection. Unlike plant identification and cloud-based pest detection, this analysis runs exclusively self-hosted on your own Kamerplanter infrastructure: there is no cloud adapter, and your photo never leaves the instance. Consent is still requested because a photo of yours is processed. As with pest detection, the photo is stripped of EXIF metadata before processing and is never stored permanently — only a SHA-256 fingerprint is retained for traceability. Every result is explicitly only a hypothesis; a treatment is never triggered automatically.

Objecting to Processing (GDPR Art. 21)¶

You can object to the processing of your data for certain purposes where processing is based on legitimate interest.

The system reviews the objection. For processing based on GDPR Art. 6(1)(f) (legitimate interest), processing will cease unless compelling legitimate reasons are present.

Deleting Your Account (GDPR Art. 17)¶

You have the right to erasure of your data.

Deletion Process¶

1. Navigate to Privacy > the Delete Account tab
2. Click Delete Account — already on the tab, and again in the dialog, you see which personal gardens are deleted with your account and how many other members this affects
3. In the confirmation dialog, type your own email address back in. For accounts with a local password, also enter your current password (to authorize the deletion). If you sign in through Google or a generic OIDC provider, you instead click Sign in again and confirm with a fresh sign-in at that provider; only if you sign in exclusively through GitHub or Apple, click Send code by email and enter the confirmation code it mails you.
4. In the confirmation dialog, click Yes, Delete Account

The same action can also be triggered directly via the API: POST /api/v1/privacy/erasure expects the same request body as DELETE /api/v1/users/me (see Deleting Your Account) — {"confirm_email": "...", "password": "..."}, where password is only required for a local password. GET /api/v1/privacy/erasure/{erasure_key} returns the status (see For Technical Users / Self-Hosters).

What happens next:

Immediately:
- Soft-delete of the account (status: deleted)
- All active sessions are terminated
- You can no longer log in
- Pending invitations into your personal garden
  (email and link invitations) are revoked, and new ones can
  neither be created nor redeemed during the 90 days;
  nobody can join it during the 90 days any more
- If you were the last person with the management right in an
  organization, the longest-serving lead takes over now, or the
  organization is orphaned (deleted after the grace period);
  its members get an email right away

Personal data (GDPR Art. 17):
- Anonymised immediately or deleted after 90 days

Legally protected data (GDPR Art. 17(3)(b)):
- Harvest documentation and IPM treatment records:
  Are anonymised (user reference removed),
  the data itself is retained (CanG, PflSchG)

After 90 days:
- Hard-delete of all remaining personal data

Photos and Attachments (Object Storage)¶

Kamerplanter stores photos and files through a storage adapter configured by the platform operator. As a user, the following points are relevant to you:

EXIF Data¶

When uploading photos, the backend removes all EXIF metadata by default before storing the file. This includes:

• GPS coordinates (location where the photo was taken)
• Camera model and serial number
• Timestamp (from the EXIF header)

The operator may enable EXIF retention per category — this will be noted in the instance's privacy notice when enabled.

Photos and Account Deletion¶

When you delete your account, the system distinguishes between two photo types:

Files are retained because they belong to the plant record and may be subject to statutory retention obligations (CanG, PflSchG). Your name is no longer linked to the photos after anonymization.

If you contributed your own photos as reference images for plant recognition, those contributions are removed on account deletion too: the system deletes the feature vector computed from them from the recognition base. Curated reference images contributed by other users are unaffected.

The same applies to your own contributed pest photos: if such a photo was ever promoted by a platform admin for pest recognition, account deletion removes the recognition vector computed from it — regardless of whether the promotion was still active or had already been reverted at the time of deletion.

Tenant Deletion¶

When a tenant is deleted (by the platform admin or by a member with the Management extra permission), the system first creates a deletion record and immediately deactivates every membership — nobody has access to the tenant anymore after that — and answers 202 Accepted. A background worker then carries out the actual deletion (issue #1792), no longer the request itself. Every reference-image and pest-image vector contributed by a member of that tenant is then removed from the recognition base, followed by all binary data for that tenant — regardless of the backend in use (local-fs or S3) — by deleting all objects with the prefix t/{tenant_key}/ — and every sensor reading of the tenant from the time-series database.

Several small database transactions (at most 1000 records each, one collection after the other) then remove every domain record the tenant holds: sites, plants, planting runs, diary entries, tasks, tanks, sensors, feeding and watering logs, notifications, calendar feeds, its own master-data entries (e.g. species, fertilizers or nutrient plans it created itself), memberships, invitations, location assignments and API keys restricted to the tenant — together with every link to a deleted record — and finally the tenant record itself.

One exception applies: harvest and treatment documentation (harvest batches, quality assessments, treatments, inspections) must be kept for several years under statutory law (CanG, German Plant Protection Act; see Statutory Minimum Retention Periods). On these records, each member's account reference is replaced by the same tombstone hash account erasure uses, and name fields (harvester, applicator, inspector, assessor) are emptied — the records themselves remain. The AI call log and the MCP call log are likewise retained until their own retention window expires.

Between the batches the worker reports a heartbeat on the deletion record; a worker that crashes is replaced by the daily run after six hours without a heartbeat, a slow but living one is not. After the last batch, the system checks that nothing still references the tenant. If not everything could be removed, or a step failed (e.g. an external service was unreachable), the deletion stays recorded and is retried automatically every day with a growing delay, until it completes fully; the third unsuccessful attempt already raises an operator alert (log event tenant_erasure.escalated, timestamp escalated_at on the record). The result is documented in the deletion record.

The members' own accounts are not affected — they keep their account and their memberships in other tenants. A member's personal tenant is not removed by a tenant deletion.

Data Portability (GDPR Art. 20)¶

Your data export includes all stored attachments as a ZIP archive. The archive contains:

• All files in the relative folder structure of the storage schema
• A manifest.json with the mapping attachment_id → file path → metadata

Data Retention and Retention Periods¶

Kamerplanter stores different data categories with different retention periods:

Sensor Data Downsampling¶

Sensor data is automatically compressed in stages:

0–90 days:       Raw data (every measurement)
90 days–2 years: Hourly aggregates (Min/Max/Avg)
2–5 years:       Daily aggregates (Min/Max/Avg)
After 5 years:   Automatic deletion

IP Anonymization¶

IP addresses are generally only stored in plain text for 7 days. After that they are anonymized to the /24 subnet (the last 8 bits set to 0), so that individual assignment is no longer possible.

Sensor Data and Privacy (DPIA)¶

Certain sensor data can allow inferences about presence patterns (CO₂ concentration, motion detectors, manual overrides). A Data Protection Impact Assessment (DPIA) has been carried out for such data. The key measures:

• Sensor data is fundamentally not shared with other tenants or third parties
• The platform operator can only view sensor data after an explicit support request and with your consent
• Aggregated statistics (without personal reference) may be used for system improvement — you can disable this in the consents

Frequently Asked Questions¶

See Also¶

• Account & Sign-In
• Tenants & Gardens
• AI Assistant