Privacy and obligations

Clubs entrust CheckCourt with their members' data. An app that gets access to this data takes on part of that responsibility. This page summarizes what the platform requires and what is expected of you. It is not legal advice.

Club apps: data processing on behalf of the club

If your club app processes personal data on behalf of the club, you are its processor. Then:

1. Set "avvRequired": true in the manifest.
2. Under Organisation (organization), in the Auftragsverarbeitung (AVV) (data processing agreement) section, upload an AVV template as a PDF of up to 10 MB. Only owners of the organization can do this.
3. During installation, the club sees the notice „Bei der Installation schließt ihr einen Auftragsverarbeitungsvertrag mit dem Anbieter ab.“ (By installing, you enter into a data processing agreement with the provider.) and can open the template. Whoever installs confirms: „Ich schließe für den Verein den Auftragsverarbeitungsvertrag mit … ab.“ (I enter into the data processing agreement with … on behalf of the club.) CheckCourt stores who agreed to which version and when.

Without a template, such an app cannot be set to Privat (private), cannot be enabled through a link, cannot be submitted and cannot be installed. Only in your own sandbox club does it work without one, because that club holds nothing but test data. There, CheckCourt also does not ask for the AVV on installation or update and stores no consent.

If you upload a new template, it applies to future installations. If a new version changes avvRequired from false to true, the club has to consent to the update and enter into the AVV as part of it.

Member apps: the member's consent

A member app acts on behalf of the member. It sees what the member sees in CheckCourt, never more. This includes other people's data, as the member sees it. The consent dialog says so explicitly, depending on the scopes, for example:

• who plays on which court, with partners and guests
• the players on your teams
• club members the app can search for by name
• other members' fees
• invite links and who created them
• the helpers at work sessions
• posts, announcements and events, including their authors

Anyone who hides their name in a booking stays hidden from other members' apps as well. CheckCourt enforces this for all apps, see API for apps.

What the club and the member see before consenting

From the manifest, CheckCourt shows in German:

• the permissions, with the German name and description of each scope
• the processed data (categories), the purpose (purpose) and the storage location (storageLocation). Outside the EU, „außerhalb der EU“ (outside the EU) is clearly marked.
• the provider, with the website and privacy policy from your organization's profile
• for club apps, the events the app is notified about and the places where it appears in CheckCourt

Keep this information honest and complete. The review compares it with what the app actually does.

Deletion after uninstalling

When your app is removed from a club or a member disconnects it:

• All tokens of this installation become invalid immediately.
• Your app receives app.uninstalled with the installation_id.
• You then delete the data of this club or this member that you received through the installation. When removing the app, the club and the member are told that the provider is being asked to delete it.

app.uninstalled also arrives when a member leaves the club or deletes their account: all of their connections in that club, or everywhere, are then disconnected. When a club removes a club app, its members' user links under it are disconnected too.

A paused installation, by contrast, is not removed. Keep the data until app.uninstalled arrives.

Data minimization

• Only ask for scopes you need. Fewer permissions mean fewer questions at installation and a faster review.
• Use the events as they are. They contain no names. Only fetch personal data when you really need it, and then fetch it fresh from the API.
• Only store what you need, and only as long as you need it.
• Pseudonyms instead of user IDs: If your interface does not need an identity, the stable pseudonym ID in the context token helps you recognize returning people without knowing who they are. Member apps get a pairwise user_id from GET /me for the same purpose.
• Member count without the directory: GET /members/count needs only members:read.

Storage location

Specify in storageLocation where the data is stored: "EU" or "non-EU". Apps that store data outside the EU are marked at installation and consent, and clubs also see this in their list of member apps. If a new version switches from "EU" to "non-EU", the club and members have to consent again.

Developer terms

The terms themselves are in German. This summary is no replacement for them; the points that matter most for your app's data:

• Your app processes data only for the purpose its manifest and listing state, and only as much as that purpose needs. You don't sell data, pass it on or use it for advertising or profiling.
• You reach members only through CheckCourt's notifications, not through contact data you received through an app.
• After an uninstall or disconnect, you delete the club's or member's data within 30 days, unless the law requires you to keep it.
• For club apps that handle personal data, you are the club's processor and provide a data processing agreement (Art. 28 GDPR). Member apps need a privacy policy linked in the listing.
• You report data breaches that affect CheckCourt data to CheckCourt without delay, at the latest within 24 hours.
• In the sandbox club you use invented test data only.
• CheckCourt reviews apps before publishing and can suspend an app or organization at once in case of violations or danger to clubs, members or the platform.