Privacy policy of the app

Version: datenschutz-2026-22
As of: November 2026

This is a translation for your convenience. Only the German version is legally binding.

New compared with version datenschutz-2026-21: this notice now also describes Android notifications through Google's Firebase Cloud Messaging (FCM), its technical delivery identifier, neutral notification data and Google's processing. Google Analytics is not used. This addition does not withdraw existing guardian consents or children's existing features.

This notice describes what the CoParity app does with your data, on iPhone, Android and in the browser. It describes what has been built, rather than an intention: where something is not stored, the technical design does not provide for storing it either.

1. Controller

Datargo GmbH
Omniturm
Neue Mainzer Straße 52-58
60311 Frankfurt am Main

Represented by Andreas Mallek
Local Court of Friedberg (Hessen), HRB 9742
Email: [email protected]

No data protection officer has been appointed; the conditions of Section 38 BDSG are not met. Please send data protection enquiries to the address above.

2. What is processed, why, and on what basis

Data	Purpose	Legal basis
Name, email address, login credentials and your optional phone number	Account, sign-in and contact by your own children or on approved emergency cards	Article 6(1)(b) (contract)
Care plan: pattern, handover days, times, handover locations, holiday periods	The purpose of the app: where the child is, when, and with whom	Article 6(1)(b)
Deviations from the plan, with a period and a response deadline	Agreeing a particular exception	Article 6(1)(b)
Marker for a completed changeover: reference to the specific changeover, scheduled time, place, children and parents involved, the marking person (only the parent handing over), and the server time of marking	Showing that a changeover occurred in the current day; neither mutual confirmation nor an assessment	Article 6(1)(b)
Notice of a different time: the child, the scheduled handover, the notified time on the same day, an optional reason from a fixed selection (on the way, work, appointment, other reason), who sent it and when. No free text	Telling the other household that today's handover will take place at a different time, without changing the plan	Article 6(1)(b)
Starting alone: a plan entered by one parent before the other has joined, marked as entered but not yet agreed	Using the app before the other parent agrees	Article 6(1)(b)
Earlier purchases through the App Store (legacy records): an account identifier issued by our server for each account and included by Apple in the purchase; the purchase's original Apple transaction identifier, product (monthly or yearly), end of term, status (active, grace period, payment problem, expired, revoked), environment (test or production) and time of the last message from Apple; the previously associated family and stored end of term; records of messages received from Apple. No payment details	Reconciling earlier transactions with Apple and handling refunds and enquiries about legacy records; not a requirement for access to free use	Article 6(1)(b); for retention after the end of the term, Article 6(1)(f) (resolving refunds and enquiries); where tax or commercial law obligations apply, Article 6(1)(c)
Sign-in: a device session with a refresh token that changes on every refresh; for 60 seconds afterwards, the previous token remains recognisable as a verification value	Staying signed in without two simultaneous refreshes signing the device out	Article 6(1)(b)
Protection against password guessing: for each login name used in a failed sign-in, a verification value (SHA-256 of the login name, never the address itself), the number of failed attempts, and the times when counting and blocking began. Five failed attempts within 15 minutes block sign-in with that name for 15 minutes. Counting works the same whether or not an account exists for the name	Protecting accounts against someone trying different passwords	Article 6(1)(f) (legitimate interest: account security, Article 32)
Protection against password guessing per network address: for the IP address from which a sign-in fails, a verification value hashed with a secret key (HMAC-SHA-256, never the address itself; the key is not kept with the data; for IPv6, covering the connection's entire address block), the number of failed attempts, and the times when counting and blocking began. 20 failed attempts within 60 minutes block sign-in from that address for 60 minutes, for every login name. The verification value is not associated with an account	Preventing someone from trying a small number of passwords against many accounts	Article 6(1)(f) (legitimate interest: account security, Article 32)
A child's appointments: title, start, end, location, whether both parents must agree, the deadline for agreement and whether agreement has been given, plus who entered the appointment	Doctor, parents' evening, report card: what is in a child's day, for both households	Article 6(1)(b); a title can be health data, as explained in the paragraph on appointments below
Calendar subscription: a secret link for each parent and child, the child and family it applies to, when it was created, and whether titles and locations are included	Your own care times and the child's appointments in a calendar of your choice	Article 6(1)(b)
Calendar on the device: which entries the app wrote to which calendar (on the device, not on our servers), and an appointment you import from one of your calendars: title, start, end, location	Seeing the plan where your everyday schedule already is, without entering it twice	Article 6(1)(b)
Child's first name and date of birth	The plan relates to a particular child	Article 6(1)(b), and for accounts of children under 16, additionally Article 8(1)
People authorised to collect a child: name, relationship, scope	Answering the question at the school door	Article 6(1)(b)
Shared agreements: family, participating parents, current text, any open text or ending proposal, response deadline and technical revision; while a proposal is open, also its proposer and the parents who have agreed	Jointly wording, changing or ending everyday arrangements	Article 6(1)(b)
Tasks and whether they are completed	Everyday life between two households	Article 6(1)(b)
Lists for a day: title, items, the child and expressly selected preparation day they apply to, who created them, and optionally a reference to a specific appointment or changeover; templates belonging to the parent who created them. Not which items are ticked off	What is needed on a day, readable by both households and the child	Article 6(1)(b), and for accounts of children under 16, additionally Article 8(1); where an item contains the child's health data, Article 9(2)(c), as for free text relating to a care arrangement
Documents relating to a child: the file (PDF or photo), title, category (health, school, identity documents, care), the children concerned, who uploaded it and when; also when a parent consented to processing	Documents relating to the children in one place, for both parents	Article 6(1)(b), and because such documents often contain health data, additionally Article 9(2)(a) (explicit consent, see below)
A child's school: school name, class, federal state	Associating the timetable and holidays with the correct federal state, the same for both households	Article 6(1)(b), and for accounts of children under 16, additionally Article 8(1)
A child's timetable: school terms (label, start, end), subjects (name, colour), lesson times and the allocation for each weekday and lesson, optionally with a room and short note. No author, no grades	When the child has which lessons, the same in both households, also available to print	Article 6(1)(b), and for accounts of children under 16, additionally Article 8(1)
Timetable sharing links: child, term, internal label, creating parent, selected additional dates, expiry, technical revision, and verification hashes for the link secret and optional password	Make selected school information readable by third parties at a parent’s request	Article 6(1)(b); for protection against password guessing, Article 6(1)(f) (security of sharing links)
Tests and study sessions: a child's appointment as above (title, day, time, who entered it), plus the subject and, for a study session, the test it prepares for. No grade, no household, no record of who practised	Knowing school dates before they arrive	Article 6(1)(b), and for accounts of children under 16, additionally Article 8(1)
Report cards: a scan (PDF or photo) as a document in the report-card category, title, the children concerned, who uploaded it and when; also when a parent authorised storage, with the identifier of the authorisation text. The app extracts nothing, no grades	The children's report cards in one place, for both parents	Article 6(1)(b); insofar as the other parent sees it, Article 6(1)(f) (legitimate interest of both parents with parental responsibility). Not consent, see below
Browser access: a cookie containing the sign-in, encrypted and readable only by our server, plus when the session began and was last used. No other cookie, nothing in browser storage	Staying signed in while working in the browser	Article 6(1)(b); storing the cookie in the browser is strictly necessary under Section 25(2), no. 2 TDDDG and therefore requires no consent
Notifications to the phone: the technical delivery identifier (an APNs device token on iPhone or an FCM registration token on Android), the device language, your switches for each category (including important parent messages), and a delivery log containing category, day and outcome. Also the silent trigger: a delivery with no sentence and no content that wakes the app in the background to reconcile the calendar on the device; nothing about it is stored	Letting you know when something is waiting for you, without content on the lock screen, and keeping the calendar on the device up to date	Article 6(1)(b)
Free text relating to a care arrangement (for example, instructions for a caregiver)	Handover to a third person	Article 6(1)(b), and where it contains the child's health data, additionally Article 9(2)(c)
Messages between parents in a family: text of up to 2000 characters, author, time and whether the author marked it as important. No read status	Coordinating everyday family life	Article 6(1)(b); where messages contain health data, processing additionally requires a basis under Article 9(2) (see the paragraph on free-text fields)
Messages between a child's account and one parent (private channel)	Enabling a child to contact one parent alone, without having to use a service outside this app	Article 6(1)(b), and for accounts of children under 16, additionally Article 8(1)
Health note about a child: a sentence of no more than 280 characters, written by a parent, plus who wrote it and when	Handover to the person caring for the child: what they need to know in an emergency (allergy, auto-injector, medication)	Article 6(1)(b) and Article 9(2)(c) (the child's vital interests)
A child's objection to a sentence about their body: the time and the child's account that pressed the button, attached to the health note and to the free text of a care assignment. No free text, no reason	Enabling a child to object to a sentence about their own body without having to talk about it	Article 6(1)(c) in conjunction with Article 16, and for the sentence itself, the same basis as in the row above

For the health note, we also need to explain what it is NOT based on. The app does not obtain separate explicit consent under Article 9(2)(a) for it, and that would also be the wrong basis here: a child under 16 cannot give it independently, and a basis that may have been withdrawn in an emergency is unsuitable for information that a caregiver needs in that very emergency. It therefore rests on Article 9(2)(c). The limits that accompany this are part of the software's design: one line per child, no more than 280 characters, no previous version. The child notice explains to the child, in their own language, that the sentence exists, who reads it and that they can object to it.

Special categories under Article 9 arise in three places, and only those three. One is the health note above: the field exists for that purpose, and the app does not analyse it. The second is free-text fields (for example, an instruction for a caregiver, an item on a list or a parent message). The third is documents relating to a child; the paragraph on documents below applies to them.

Free-text fields are not intended for these data, but the data may still appear in them. “EpiPen in the outside pocket” is health data regardless of which field someone types it into, and the software can neither prevent nor recognise this. A controller who knows this and does not name the permission for it is processing without one; the Regulation does not provide for shifting responsibility onto the user (Article 24, Article 25(2)). These fields therefore rest on the same basis as the health note, Article 9(2)(c), and are subject to the same access window (Section 4).

Naming a basis does not change this: the intended field remains the health note because there is exactly one line per child, because it can carry an expiry date, and because both parents and the child can read it at any time. A sentence in the free text of a care assignment has none of these properties: it applies without an end date, does not replace the note but stands alongside it, and reaches the people with access during the relevant window. Like the health note itself, it can carry the child's objection (Section 4).

For documents, we need to explain their basis. A vaccination record or doctor's letter is not an emergency, and the basis of the health note (vital interests) does not support it. The app also cannot recognise what a file contains. Before a parent uploads their first document, it therefore explicitly asks whether they consent to documents relating to their children being stored here, even if they contain health data (Article 9(2)(a)), and records when they agreed. They can withdraw consent in the app at any time. The documents they uploaded are then deleted; the app first offers to save them on their own device.

For report cards, we need to explain their basis. A report card is generally not health data, and consent for documents under Article 9(2)(a) does not apply to report cards. Before a parent uploads their first report card, they authorise storage; this authorisation has its own text (identifier zeugnisfreigabe-2026-1), which the app shows beforehand and which remains accessible at any time. It is not consent: storage rests on Article 6(1)(b), and the other parent's access rests on Article 6(1)(f). A parent who withdraws this authorisation can no longer upload report cards; report cards already uploaded remain, until the parent who uploaded them deletes them individually, because they are available to both parents. The same applies when consent for documents is withdrawn. If a report card contains information about a child's health, such as an accommodation for a disability, it belongs in the health document category and is therefore covered by consent; the app does not recognise this itself.

For holidays, we need to explain that the dates do not concern individuals. The holiday dates of the 16 federal states are a general table served identically to everyone; they are not personal data. Only the federal state entered for a child is personal data (the child's school, above).

For browser access, we need to explain what is stored in the browser. Exactly one cookie. It contains the encrypted sign-in, cannot be read by scripts on the page, is sent only over an encrypted connection and only to our server, and is valid only for the ongoing browser session. The server holds the login credentials themselves; neither the password nor readable access tokens are stored in the browser. The pages load nothing from third-party servers and store nothing in browser storage. Because this cookie is strictly necessary for sign-in, the page does not ask for consent to it (Section 25(2), no. 2 TDDDG), and there is no other cookie for which it would need to ask. If a browser sign-in fails, the server also counts this in memory for no more than 15 minutes and does not write it anywhere.

CoParity is free to use. No purchase or subscription is required for the features currently offered. For earlier purchases: Apple is the merchant. Apple processes payments and refunds under its own terms. We do not see your payment details or your Apple ID. Where earlier purchases or test transactions exist, we receive their term and status from Apple and continue to reconcile them. This is not a prerequisite for access to features. The app does not show other members who in the family pays or paid previously: the association between a purchase and an account is visible only to the person who owns the purchase, including in the access response (Section 8).

For a notice of a different time, we need to explain what it is not. It is not an agreement: the plan remains unchanged, nobody responds, and whether or when the other person read it is not recorded. A new notice for the same handover replaces the old one, and how often someone sent one is not counted.

For appointments and calendars, we need to explain what leaves the app and where it goes. Appointment titles and locations are included in a calendar subscription or an existing calendar only after an explicit choice; only a dedicated “CoParity” calendar created by the app includes them by default. A child's account does not export its plan to any calendar. Within the app, appointments appear for both parents and, where they apply, for the child (Section 4). They can reach a calendar outside the app in two ways, each chosen by a parent:

The calendar subscription is a secret link. Anyone who has it can read, without signing in, your own care times, the handovers at their boundaries and the child's appointments, up to 90 days ahead. It extends 30 days into the past, and a stay that began earlier retains its actual start time even if that lies further back; an appointment remains in it until it is deleted two days after its end. It never includes the other household's care times, a parent's name or an appointment still awaiting a decision. Without an explicit choice, it contains the neutral version: “Noah is here” and “Appointment for Noah”, without the appointment title or location. The link is stored in your calendar program's settings and in the logs of every service through which it is retrieved; creating a new subscription makes the old link unusable.
The calendar on the device. The app writes the same entries into a calendar on your iPhone. This requires full access from iOS, which opens all calendars on this device, including shared and work calendars: iOS does not offer a narrower permission allowing an app to change or delete its own entries. On every reconciliation, the app reads the calendar it writes to in order to find its own entries; when importing, it reads the calendars you select for that purpose. The only appointment from your calendars that leaves the phone is one you explicitly import: it becomes an appointment in the app like any other, and its title appears in the other household exactly as entered. If the app creates its own “CoParity” calendar for its entries, titles and locations are included; an existing calendar initially receives the neutral version, and titles and locations only after an explicit choice.

On Android, the app uses the Android Calendar Provider. It needs the READ_CALENDAR and WRITE_CALENDAR system permissions, which allow access to calendars on the device, including shared and work calendars. During reconciliation, it reads appointments only in the selected target calendar to find its own entries; it writes, changes and deletes only its own entries. The target is a local “CoParity” calendar or a writable calendar you select. This reconciliation does not send data from other calendars to CoParity.

Appointments may come from the other parent. The person entering an appointment writes its title and location, and the full version includes both verbatim in your calendar. If you choose the full version for a calendar that other people can read, such as your employer's calendar, they can also read what the other parent wrote. The neutral version contains no words typed by anyone.

A title can be health data. “Paediatrician” or “Vaccination” says something about a child's health, and the app can neither prevent nor recognise this. The basis supporting free text relating to a care arrangement (Article 9(2)(c)) is tied to its access window, and an appointment has no such window: both parents and the child can read it until it is deleted two days after its end. We therefore do not cite that basis for appointments. What the app does is keep use of the title narrow: it does not analyse it, shows it only within the family, and outside the app includes it only in the dedicated “CoParity” calendar or where you explicitly choose the full version. Include in a title only what the other household needs for planning; information that protects a child in an emergency belongs in the health note.

Your own phone number belongs to your account and therefore applies to all its families. Only the signed-in parent can add, change or remove it. The app checks its format, not whether the number can be reached or belongs to you. Children with permitted access can use it to contact their active parents. Emergency-card approval remains separate for each family: saving or changing a number does not override a withheld approval. Cards are delivered only during the intended care window to people with permission. The number appears in your own data export and is removed when the account is deleted. No history of earlier numbers is kept.

Shared agreements

Agreements are visible only to the active parents in the same family, not to children or caregivers. Submitting a proposal expresses the proposing parent's agreement to that wording. A new agreement, change or ending takes effect only when all participating parents expressly agree to the same revision. Silence is not agreement. During a proposed change the existing text remains in place. The app shows no individual response times, read receipts or rejections. Data exports include the agreement and any open proposal, but no list of individual approvals and no proposer.

This free-text feature is intended for everyday organisational arrangements. Health information, medication and other sensitive information do not belong in agreements. Use the designated child health area for necessary health information. The app does not analyse the wording and cannot automatically detect or filter such information.

3. What is expressly NOT processed

These are properties of the software, not promises about the future:

No location, no location tracking. There is no field for it.
No log of who failed to keep which agreement. A rejected or expired proposal is deleted, not marked as rejected. The data model has no “rejected” status and no version history of a plan.
No read status, no counters, no presence indicator.
No tracking, no analytics tools, no advertising identifiers. The app includes no third-party libraries for these purposes.
No record of whether a child called the anonymous counselling service.
No tick marks on the server. Items ticked off on a list remain on that person's device. Neither parent sees what has been ticked off in the other household or by the child.
No recycle bin for documents. A deleted document is deleted, including for the other parent, and is not recorded anywhere as deleted.
No payment details. Card numbers, bank details and billing addresses remain with Apple.
No history of time-change notices. How often a parent notified a different time is not recorded anywhere.
No capture location in photos. Before storing a photo, the server removes embedded metadata, including capture location, time and device.
No grades. There is no field for a grade, and the app extracts nothing from a report card: no text recognition, no analysis.
No record of who practised or signed, and no association of a test or study session with a household. Who entered an appointment is stored, but is not shown to anyone.
No second cookie in the browser, no browser storage, no content or scripts from third-party servers.

4. Who sees which data

Within a family, access is determined by role, not curiosity:

Both parents see the plan, deviations and the collection list.
A child with their own account sees where they are and when they move between homes, and expressly does not see what the adults are currently negotiating.
Grandparents and caregivers see only what they need for their own care assignment, not the family's plan.

Parent messages can be read and written only by active parents in the same family. This also applies to messages written by the other parent. Children, grandparents and caregivers have no access. Whether a message has been read is not stored. The channel creates neither a plan change nor an appointment or task; it is also not a child's private channel.

A notice of a different time is visible to the other parent in the plan, as a phone notification if enabled, and as a rescheduled handover entry in their calendar. A child, grandparents and caregivers do not receive it. After that day, the calendar retains only the time at which the handover entry stood, without who sent the notice or the reason.

A plan entered by one parent alone is initially visible only to that parent, in the app and in their calendar. The other parent sees it once they join, as entered but not yet agreed.

All features currently offered are accessible free of charge, according to the person's role in the family. Data about earlier purchases is visible only to the person whose account the purchase belongs to.

A child's health note can be read by both parents and the child themselves at any time and without a particular occasion; only a parent can write or delete it. A caregiver can read it only during the access window for their own care assignment, beginning two hours before an agreed assignment and ending one hour afterwards. Outside this window, it is not served to them. The same window applies to free text relating to a care arrangement and to the emergency card, and it also applies to a parent: information attached to an assignment is readable during the period when the plan places the children with that parent, not beyond it.

There is one exception, and it is the reason this processing exists at all. If several sentences about the same child's body apply on one day and they do not say the same thing, the person currently caring for the child receives all of these sentences within their own window, including a sentence from an assignment earlier that day belonging to another person. Without this exception, they would read a sentence that the software knows is contradicted by another, without receiving either the second sentence or any indication that it exists. This is the case in which a caregiver looks for emergency medication in the wrong place, and it is what this processing addresses (Article 9(2)(c)).

Its limits are narrow, and all four are enforced on the server:

Only where sentences contradict each other. If only one sentence applies to the child on a day, there is nothing to compare and the exception does not apply.
Only within the reader's own window. It begins two hours before their own assignment and ends one hour afterwards. Outside it, they receive nothing, not even their own sentence.
Only about the child they are caring for. A sentence about a child not included in their assignment does not reach them. A text is indivisible: if it also mentions a sibling, that mention is included because the text cannot be split without losing its meaning.
Without the author. As soon as several sentences about the same body apply, the author of none of them is disclosed, including the health note itself. What remains is the day. Otherwise, two named adults and a reported contradiction could make it possible to infer who is blamed for the error, and this software does not decide that.

A child's objection appears wherever the statement it concerns appears: for both parents and, in the same window as the statement, for the caregiver. It names the child and nothing else.

Documents are visible to both parents, every document regardless of who uploaded it; there is no private compartment. A child, grandparents and caregivers see no documents, even during a care assignment's window. Only the person who uploaded a document can change or delete it; the other parent can keep their own copy. Title and contents are encrypted, and the master key needed to read them is not stored in the database.

Markers for completed changeovers are visible only to the family's active parents. Only the parent handing over can set or remove their marker. The app shows who marked the changeover as completed and when; this does not imply confirmation by the receiving parent. Silence and the passage of time do not set a marker. A later plan change does not move the marker to another changeover. After the end of the local day, the marker and associated technical retry records are deleted. The app keeps no history of removed markers or statistics about them.

A link from a list to an appointment or changeover does not extend the list's retention period. A changed or removed event is indicated without automatically moving the preparation day. Children receive only the kind of list, not additional appointment details or parents' changeover markers.

Lists for a day are visible to both parents and the child they apply to, provided that the child's account has consent based on the text explaining lists. Templates are visible only to the person who created them.

School, timetable, tests and study sessions are visible to both parents for every child in the family. A child with their own account sees only their own, provided that every consent attached to their account is based on the text explaining school; they do not see a sibling's. Only a parent can enter or change them. Grandparents and caregivers have no access through their family role. A parent can, however, give them a timetable sharing link:

Each link covers exactly one child and one term. It displays the first name, school, class, term, lesson times, subjects, rooms and notes. Tests and study sessions can be selected separately and are excluded initially. Only dates within the term that are no more than one day in the past and begin before the link expires are shown. Report cards, other documents, private information and the names of people who entered items are excluded.
No account is needed to read the browser view. Anyone who has the secret link and, if enabled, the password can see the selected information. Forwarding them gives other people access. Optional password protection is initially enabled when creating a link. Share the password separately from the link.
All active parents in the family can manage and individually revoke links. Each link expires, at most 366 days in the future; the suggested expiry is the end of the term. Each family can have at most 50 active links.
On each data request, the server checks the selected scope, expiry, revocation and the creating parent’s continuing access. The browser view also checks regularly and before printing. This cannot recall an already saved PDF, printout or another person’s copy. Copies may become outdated after changes.
Only verification hashes are stored, never the readable link secret or password. The secret is in the URL fragment, is removed from the address after opening, and is sent in the request body for verification. The view uses no account session, cookies or persistent local storage. There is no visitor list or read status. Failed password attempts are limited through verification values per link and network address: five attempts in 15 minutes or 20 attempts in one hour respectively. Counters are removed no later than 30 minutes or two hours after the first failed attempt, respectively.

Report cards are visible to both parents, like every document. A child, grandparents and caregivers do not see them.

A child's appointments (Section 2) are visible to both parents regardless of who entered them, without the name of the person who entered them. A child sees appointments that apply, not ones the parents are still deciding on. Grandparents and caregivers do not see them.

Only a parent can export a plan to a calendar outside the app, and only their own care times with handovers and the child's appointments: a child's account, grandparents and caregivers can neither create a calendar subscription nor use the calendar on the device.

These limits are enforced on the server, not in the app: what someone is not allowed to see is not served to them, rather than merely hidden.

5. Recipients

We use Cloudflare (Cloudflare, Inc., 101 Townsend St., San Francisco, CA 94107, USA) to technically provide the app and browser access. As a technical service provider, Cloudflare also processes personal request contents: for example, sign-in information, account data and family data that you send or retrieve through the app or browser. The access boundaries described in section 4 continue to apply.

Processing through Cloudflare Workers. Workers execute the server functions for the app, API and browser access. For a request, Cloudflare processes technically necessary connection data such as the IP address, requested address and time, as well as the contents needed for the relevant function. Workers can process requests worldwide, including outside the European Union and in the USA. Execution exclusively in Europe is not promised.
Storage in D1 and R2. Accounts and family data are stored in Cloudflare D1 with EU jurisdiction. File objects, including documents and bedroom photos, are held in private Cloudflare R2 buckets with EU jurisdiction. This boundary concerns the storage location; it does not prevent Workers outside the EU from accessing and processing the data for a request. Documents and report cards are encrypted on the server before storage. Server functions use the necessary keys when an authorised request retrieves them. This is not end-to-end encryption against the technical service provider.
Processing in third countries. Besides the Apple, Google and personally connected calendar routes described below, technical provision through Cloudflare may involve processing outside the EU. Cloudflare publishes information about data processing and the safeguards provided for such transfers, including standard contractual clauses, in its Data Processing Addendum. The technical boundaries of EU storage are explained in the documentation for D1, R2 and Workers.
Notifications through Apple. Notifications to your iPhone are delivered by Apple Inc.'s Apple Push Notification service; there is no other route for a notification to an iPhone. Apple receives your phone's device token, the category, the notification sentence, and a link into the app containing a numerical family identifier and, for child-related occasions, a numerical child identifier. For an important parent message, the link contains only the family identifier, never the message text or its identifier. No sentence names a child, a parent, a day or any content, and no number appears on the app icon. A silent calendar trigger carries only the device token, with no sentence, link or category. Apple also processes these data in the USA; according to its own statements, Apple safeguards such transfers using the European Commission's standard contractual clauses. You control which categories reach you in the app, and iOS lets you disable notifications entirely.
Android notifications through Google. We use Google's Firebase Cloud Messaging (FCM) as a notification delivery provider. Only after you allow notifications and an active parent or caregiver membership is available does the app request an FCM registration token and associate it with your CoParity session. Google creates a Firebase installation ID (FID); the SDK also sends technical app, device and configuration information. The app remains usable without Android push. Google Analytics, advertising identifiers and analysis of your notification interactions are not used for this. Google receives the token, a neutral category and sentence, a link containing technical identifiers for the family and the relevant app entry (depending on the occasion, also a child identifier), and delivery controls such as expiry and collapsing. Names, message texts, school, health and appointment contents are not included. A silent calendar trigger contains only a technical calendar-sync marker, with no sentence or family link. Transport is encrypted; this does not provide end-to-end encryption against Google. The app retrieves the contents directly from CoParity after sign-in. Google processes these technical data globally, including outside the EU and in the USA; the EU storage boundaries of D1 and R2 do not apply to this delivery route. Details of data types, retention and contractual terms are available in the Firebase privacy information, Android SDK disclosures and Firebase terms. You can disable notifications in Android and categories in CoParity. This stops further CoParity notifications; deleting a CoParity device registration does not mean the Firebase installation ID is immediately deleted at Google.
Apple as merchant and the App Store Server API (legacy records). Earlier purchases were made through Apple (for customers in the European Union, to our understanding, Apple Distribution International Ltd., Ireland). Apple sends our server signed messages about purchase, renewal, refund and expiry. To reconcile records, our server asks Apple's App Store Server API for a subscription's status and sends only the original transaction identifier. Apple's terms and privacy notice apply to the purchase itself. Apple also processes data in the USA; according to its own statements, Apple safeguards such transfers using the European Commission's standard contractual clauses.
Sheets you share yourself (such as the collection list for the school) leave the app through your own action. You decide what happens to them.
Calendars you choose to connect. You decide where the calendar subscription or on-device calendar sends the entries: iCloud, Google, your employer's Exchange account or a calendar only on your iPhone. That calendar's provider receives the entries, and with a work calendar your employer may read them, a substitute may see them, and its retention arrangements may keep them. If the provider is outside the European Union, for example in the USA, the entries reach a third country: with a subscription, because its service retrieves the link from our server; with an on-device calendar, because the iPhone synchronises the calendar with that provider. Both happen because you keep your calendar there, and that provider's terms also apply to the data. We do not send anything to any calendar provider on our own initiative.

6. Retention periods

Shared agreements retain the current text until their jointly approved ending or a change in the family's active parent group. Deleting a participating account also deletes these agreements. Open proposals last at most 14 days. Expiry or dismissal removes the proposal and individual approvals; any previously agreed text remains. Full approval also removes individual approval data and the proposer. A change replaces the old text without an archive. Agreements for a changed parent group are immediately withheld and deleted during the next cleanup. Technical write-retry receipts last at most 48 hours and contain no agreement text.
A proposal for a deviation is deleted as soon as its response deadline expires, leaving no record behind.
An accepted deviation leaves the agreement process two days after its end. It remains as a period and a side until 45 days after its end, without who proposed it, its response deadline or the time when it was accepted: otherwise, the plan and calendar would show past weeks as if the deviation had never existed. After that, this is deleted too.
A notice of a different time is deleted at the end of the day of the handover, no later than 25 hours after the scheduled handover. A new notice for the same handover replaces it immediately. What remains in the calendar afterwards is only the time of the past handover entry, without who sent the notice, the reason or the sending time; this too is deleted 31 days after the handover. Delivery of this notice remains in the delivery log for one hour.
A superseded care plan is deleted when replaced. There is no previous version.
Account and plan data remain for as long as the account exists.
A health note about a child remains until a parent replaces or deletes it. There is one line per child: replacing it overwrites it without creating a previous version. If the note specifies a day until which it applies, it disappears at the end of that day without anyone having to remember. A child's objection belongs to the version it concerns and disappears with it: if a parent rewrites the note, the objection is gone.
Messages in the private channel are deleted no later than 48 hours after being written. The period is a constraint in the database schema; longer storage cannot be entered there. A service deletes expired messages every quarter of an hour. A reply inherits the expiry of the message it replies to and disappears with it. The child can delete their private channel themselves at any earlier time.
Parent messages are stored for no more than 30 days. This period is a constraint in the database schema. Expired messages are no longer served even if the quarter-hourly deletion run has not yet taken place. When an account is deleted, parent messages written by that account are removed immediately; the other parent's messages remain until their own expiry.
A list for a day is deleted after the end of that day. If someone opens the app, deletion happens then; otherwise, a service removes it once the day has ended in every time zone, in Germany no later than the afternoon of the following day. Templates remain until their parent deletes them.
A document remains until the parent who uploaded it deletes it, withdraws consent or has their account deleted.
A report card remains until the parent who uploaded it deletes it or has their account deleted. Withdrawing authorisation or withdrawing consent for documents does not delete a report card.
Timetable sharing links are deleted when revoked or when the term is deleted. Expired links and links whose creating parent no longer has active parent access are removed and are already invalid on every request. Account deletion removes links created by that account. Data access exports include the account’s own sharing settings, without link or password hashes. Technical retry records remain for at most 48 hours.
School and timetable remain until a parent changes or deletes them; deleting a school term also deletes its lesson times and allocations. Tests and study sessions, like every appointment, are deleted two days after their end. If the parents have the data of a child without their own account deleted, this also removes that child's school, timetable, tests and study sessions, and report cards that concern only that child.
An appointment is deleted two days after its end. Cancelling it earlier deletes it immediately; if it had applied, the other parent is told that an appointment was cancelled and nothing else. A pending appointment that does not go ahead leaves the person who asked with a closure of their request for seven days; this does not say whether it was declined or nobody responded.
A calendar subscription remains until you revoke it, create it again or have your account deleted. If your family membership ends, the link serves an empty calendar.
Notifications: The delivery log is deleted after 30 days; a delivery identifier on our servers is deleted 30 days after its revocation or 180 days after the device's last contact; the switches are deleted with the account.
Entries in the calendar on the device are deleted by the app when you turn off reconciliation, sign out, have your account deleted or lose access to a child. It deletes stays and handovers 30 days after their end, and an appointment when it is deleted two days after its end. An entry may be out of date between reconciliations. What the app cannot reach: copies already created by your calendar provider or employer, and entries after the app has been uninstalled or its calendar access revoked. They remain in your calendar until you delete them yourself.
Purchase data from legacy records remain while an earlier subscription is running and are deleted 90 days after the end of its term; a refunded or revoked subscription is deleted 90 days after revocation. The historical family association is removed with them; free use remains unaffected. Records of messages received from Apple are deleted after 30 days. The account identifier for purchases remains for as long as the account exists.
Sign-in: The previous refresh token ceases to be valid 60 seconds after it changes; the session ends on sign-out or account deletion.
Protection against password guessing: The count for a login name is deleted no later than 30 minutes after the first failed attempt; a successful sign-in or a newly set password deletes it immediately. The count for a network address is deleted no later than 2 hours after the first failed attempt; a successful sign-in does not delete it, otherwise someone could lift the block with their own account. Because it is not associated with an account, it does not appear in the access response and is not covered by account deletion.
The silent trigger is not stored.
The browser cookie ends with the browser session, after 30 minutes without use, no later than 30 days after sign-in or on sign-out; in the latter three cases the server session also ends.
After deletion, see Section 8.

7. Children's accounts

A separate account for a child under 16 requires the consent of a person with parental responsibility (Article 8(1) GDPR). Without it, the account has no functionality.

Before using the app, the child receives their own text in language they can understand; it is accessible at any time under the identifier kinderhinweis-2026-18, even without signing in. Earlier versions remain accessible under their own identifiers so that it remains possible to read what an earlier consent referred to.

The child can switch off their own view themselves at any time, without giving a reason, and only the child can switch it back on. Parents learn that it is off, not why or how often. Switching it back on deletes that record completely.

The private channel. A child with their own account can write to one parent alone. The other parent learns nothing about this, not even that a message was sent, and not as a number either. These messages do not appear in any plan, create no case or process, and, while they are still stored, are included in both participants' access responses under Article 15. There are no read receipts, no search across older messages and no way to forward them from within the app. What a recipient does with a received message is beyond what software can prevent; the child notice explains this in language the child can understand.

Their own school. A child with their own account sees their timetable, tests and study sessions, read-only and only their own. This requires every consent attached to their account to be based on the text explaining school; until then, school remains unavailable to the child, but the rest of the account does not. A child does not see report cards.

No calendar. A child's account can neither create a calendar subscription nor write its plan into a calendar on the device: no text shown to a child before use explains a calendar. A subscription created for a child's account before this version serves an empty calendar.

Any person with parental responsibility can withdraw consent at any time; the account immediately loses its functionality.

8. Your rights

Under the GDPR you have rights of access (Article 15), rectification (Article 16), erasure (Article 17), restriction (Article 18), data portability (Article 20) and objection (Article 21).

You can request access and portability directly in the app, under Settings. You receive a machine-readable file containing everything stored for your account. The documents you uploaded are listed in it; you save the files themselves in the app under Settings, Documents, individually or all at once. Parent messages are included while they are stored if you wrote them yourself or are entitled to read them as an active parent in the family.

You can also initiate deletion in the app. Two things need to be explained beforehand:

What concerns only you is deleted. Parent messages you wrote, your pending proposals, calendar retrievals, invitations and entries on the collection list that apply only to you. Also your list templates, documents and report cards you uploaded, and your authorisation for report cards; the other parent can keep their own copy beforehand. First, the app deletes the entries it wrote to the calendar on this device; it cannot reach copies held by your calendar provider (Section 6).
What also concerns others remains. A care plan is an agreement between two households and concerns a child; deleting it unilaterally would interfere with others' rights (Article 17(3)(e)). The same applies to jointly entered people authorised to collect a child.

Any earlier subscription that is still running does not end when the account is deleted. You can cancel it only through Apple, in your Apple account settings. After deletion, the purchase remains stored without association with a person until the end of its retention period (Section 6). Free use by the other family members depends neither on that purchase nor on its term.

For complete deletion of your account, write to [email protected]. We respond within the period specified in Article 12(3) GDPR.

Right to complain: You can complain to a supervisory authority. The authority responsible for us is the Hessian Commissioner for Data Protection and Freedom of Information (Hessischer Beauftragter für Datenschutz und Informationsfreiheit), Postfach 3163, 65021 Wiesbaden.

9. Changes

This notice has an identifier. If something material changes, a new version with a new identifier is created; the old version remains accessible under its identifier so that it is possible to establish what applied when consent was given.