Privacy Policy

This is an English translation provided for convenience. In case of doubt, the German version at /datenschutz is the authoritative one.

This privacy policy explains how personal data is processed in the application “on fleek Social” (onfleeksocial.com), the social media management platform that on fleek GmbH operates for the client companies it serves.

1. Controller

on fleek GmbH, Industriestr. 10, 92360 Mühlhausen, Germany, represented by its managing director Johannes Schmidtmeier · Email: info@agenturonfleek.com · Phone: +49 160 8706068

We have not appointed a data protection officer, as there is no obligation to do so. Questions about data protection are answered by our managing director Johannes Schmidtmeier via the contact details given above.

2. Purpose of the application

on fleek Social is used to plan, coordinate, approve and automatically publish social media content for the client accounts on fleek GmbH looks after, and to evaluate the metrics of the connected accounts and of the published content. The application is used by employees of on fleek GmbH and by designated contacts at our client companies — independent businesses outside on fleek GmbH whose accounts and channels are connected. Logins are set up by us; there is no open self-registration.

3. Data processed

• User accounts: name, email address, password (stored as a hash only), optionally a profile picture, optional security features (two-factor authentication including backup codes and a counter of failed attempts, passkeys), short-lived confirmation codes and links for signing in, passwords and email changes, role, permissions and client assignment, and any suspension. For employees of on fleek GmbH, optionally a phone number. The name, email address, phone number and profile picture of the agency contact assigned to a client are visible to that client's logins in the client portal; replies to approval and reminder emails sent to clients go to that contact's address.
• Session data: one session per sign-in with IP address, browser identifier (user agent), start and expiry time. If someone from the team temporarily takes on the view of a client login, this is recorded on the session.
• Connected social media accounts: when an account we manage is connected (e.g. an Instagram business account, a Facebook Page, a TikTok account, a YouTube channel), we store the account identifier, the account's name and username (for TikTok and YouTube the display or channel name), the address of its profile picture, the follower or subscriber count (for Facebook Pages the number of likes, none for TikTok), the OAuth access and refresh tokens issued by the platform, for Facebook Pages also a page token, together with their expiry and the granted scopes, and the platform identifier and display name of the person or channel through which the connection was made (for Meta, the name of the person connecting). Access tokens are stored encrypted (AES-256-GCM), are never logged and are never passed on to browsers or third parties.
• Content: post drafts, copy, images and videos together with file name, alt text and the person who uploaded them, people and collaborators tagged in Instagram posts (usernames) and location tags, approval comments and change requests together with their authors, version states and scheduled dates created in the tool by the agency or by the client, as well as the client's logo and brand profile (tone of voice, no-gos, example captions, hashtag sets). After publishing we store the identifier and address of the post on the platform and, if publishing fails, the platform's error message.
• Insights/analytics: aggregate metrics for the connected accounts and published posts — per account the follower or subscriber count (for Facebook Pages the number of likes), for Instagram additionally the number of posts, for YouTube the channel views and the number of videos; per published post likes and comments, for Facebook additionally the number of shares, for YouTube the views. If Meta grants the permission for it, the daily reach of each Instagram account and Facebook Page is added (the number of accounts or people reached). We do not retrieve any metrics for TikTok accounts. We retrieve these values through the platforms' official application programming interfaces and store them as historical values.
• Notifications: the email addresses that receive a client's approval requests and reminders (including people without a login of their own), and a record of the emails sent (section 9).
• Log data: technical server logs, a change log of business actions (audit log), an error log and, when someone reports a bug, the content of that report (section 9).

We receive the data of our clients' contacts from the client company concerned, and the data of connected accounts and the metrics from the platform concerned. Without a name and an email address we cannot set up a login.

4. Legal bases

Processing takes place in order to perform the contracts with our clients (Art. 6(1)(b) GDPR) and on the basis of our legitimate interest in handling social media services efficiently and securely (Art. 6(1)(f) GDPR). Session data, logs and bug reports are processed on the basis of our legitimate interest in secure and stable operation and in keeping approvals traceable (Art. 6(1)(f) GDPR). The data of on fleek GmbH's employees is processed in order to carry out the employment relationship (Art. 6(1)(b) GDPR). Social media accounts are connected on behalf of the client concerned. A connection can only be started by an on fleek team login with the permission to do so; it is only ever established through the platform's own OAuth dialog, in which the account holder or a person authorised by them signs in and consents to the access. We do not receive the passwords of client accounts. No automated decision-making within the meaning of Art. 22 GDPR takes place.

5. Disclosure to platforms

When approved posts are published and when analytics are retrieved, we transmit content and account identifiers to the platform concerned (Meta Platforms Ireland Ltd. for Instagram/Facebook, TikTok Technology Ltd., Google Ireland Ltd. for YouTube). When Instagram posts are edited, the search terms of the location and music search are also sent to Meta. The platforms' own privacy policies apply to the processing they carry out. For media retrieval by Meta and, for photo posts, by TikTok we make files available through short-lived signed addresses that expire after a few minutes. Apart from the platforms named here, the AI provider described under section 6 and the service providers named under section 7, we do not pass this data on.

6. AI-assisted text features

The application includes features that produce text suggestions: captions from a brief, adapting a text to a particular channel, optimisation suggestions, and the analysis of a client's brand voice. They are available only to agency logins with the corresponding permission. For these features we transmit the content needed for the respective task to Anthropic PBC, 548 Market Street, San Francisco, CA 94104, USA, the provider of the language model we use.

Depending on the feature, the following is transmitted:

• when a caption is generated, the brief that was entered, up to three images of the post and the client's brand profile;
• when a text is adapted to channels and for optimisation suggestions, the caption text, the selected target platforms and the client's brand profile;
• for the brand voice analysis, up to 50 post texts of the client of at most 1,500 characters each: first the texts of the most recently published posts of the client's connected Instagram accounts and Facebook Pages (up to 25 per account), then, as far as there is room, the base texts of the 30 posts most recently created in the tool that are not archived, drafts included.

The brand profile consists of the stored tone of voice, the no-gos, up to three example captions and the hashtag sets. Briefs, post texts and images may contain personal data, such as names or people shown in pictures. User accounts, credentials, access tokens and metrics are not transmitted. We do not store the transmitted content or the responses with the requests. For each request we record: the feature, the model, the volume and the cost, the time, the client concerned and, where applicable, the post. If the request produces a usable suggestion, the change log additionally records who used the feature, when, and for which post or client (section 9).

The legal basis is our legitimate interest in producing content efficiently (Art. 6(1)(f) GDPR) and the performance of the contract with the client concerned (Art. 6(1)(b) GDPR). The transfer to the United States takes place on the basis of the European Commission's standard contractual clauses. Under the terms of the interface we use, the transmitted content is not used to train the models. Suggestions made by the AI are never published automatically: every post is decided on by people in the approval process.

7. Service providers (processors)

To operate the application we use service providers that process data on our behalf. A data processing agreement under Art. 28 GDPR is in place with each of them.

• Hosting: Hetzner Online GmbH, Industriestr. 25, 91710 Gunzenhausen, Germany. The application, the database and the media storage run together in an environment of their own on a Hetzner server in the Nuremberg data centre (Germany). The data listed under section 3 is held there; copies of the emails sent are also held by Google (next item). On the same server we operate the bug reporting system bugs.9of.de together with its database (section 9).
• Email delivery: notifications and sign-in emails are sent through the mail server of Google Workspace (SMTP). The provider is Google Ireland Limited, Gordon House, Barrow Street, Dublin 4, Ireland. Google receives the sender, recipients, subject and content of each email. The emails sent are also kept in the mailbox of the sending account (“Sent” folder). A transfer to the United States is possible in this context; it is safeguarded by the EU-US Data Privacy Framework, under which Google LLC is certified, and by the European Commission's standard contractual clauses.
• AI text features: Anthropic PBC, see section 6.

The bug reporting system bugs.9of.de is operated by on fleek GmbH itself; it is not a service provider in this sense.

8. Cookies, browser storage and third-party content

The application sets only technically necessary cookies:

• the session cookie for signing in (valid for at most seven days from when it is set);
• during a two-factor sign-in, a cookie for the sign-in in progress (ten minutes at most) and, on request, a cookie that marks the device as trusted for 30 days from the last sign-in on it;
• when signing in with a passkey and when setting one up, a cookie for the security challenge (five minutes);
• when a social media account is being connected, a cookie that secures the connection process (ten minutes);
• inside the agency area, a cookie that remembers the client last selected for one year;
• when someone from the team takes on the view of a client login, a cookie holding their own session so they can return to it afterwards. Like the session cookie it is valid for seven days and is deleted via “Zurück zur Agentur-Ansicht” (back to the agency view); if the view ends in any other way, for example by closing the browser or because it expires after one hour, it remains until it expires;
• when a view is taken on, also a cookie that keeps the sign-in valid only until the browser is closed. It may remain after the view has ended until the browser is closed or the person signs out; until then their own session is not extended with use either.

In browser storage the application keeps, inside the agency area, the AI model last selected (local storage) and, in the client portal for the browser tab concerned (session storage), whether the bug reporting tool was switched on with “?debug”. What the bug reporting tool itself stores in the browser is set out in section 9. No tracking takes place.

Fonts and the content of the application are served from our own servers. This also applies to the profile pictures of connected social media accounts: our server fetches them from the platform concerned (Meta, TikTok, Google/YouTube) and passes them on to the browser without storing them. In doing so it sends only the address of the image — no user data, no cookies and no tokens — and the browser makes no connection to the platforms for them. There are two exceptions: the browser loads the bug reporting tool from bugs.9of.de, which we operate ourselves on the same server (section 9). And the music preview for Instagram Reels in the post editor, which only the agency team uses, is loaded by the browser directly from a Meta server, and only once someone plays a track. Meta receives the IP address, the browser identifier and the address of our application (without path) for technical reasons.

9. Bug reports and logs

• Bug reporting tool: inside the agency area the application loads a reporting tool from bugs.9of.de, the bug reporting system of on fleek GmbH, for on fleek team logins without a client assignment; in the client portal only if the page was explicitly opened with the addition “?debug”, and then for that browser tab. When it is loaded, bugs.9of.de receives the IP address and browser identifier for technical reasons. The tool keeps the page's last 20 console errors and warnings, including unhandled errors, and last ten failed network requests (method, address, status) in the browser. Data is transmitted only when someone explicitly submits a report: the description, the email address of the signed-in login (while a team member has taken on a client view, that of the client login), the full address of the page including all parameters and the address of the previous page, browser identifier, language, window and screen size, pixel density, the application version, for each marked element its HTML excerpt (up to 2,000 characters), CSS selector, classes, ID and data attributes, the names of the related React components, its visible text (up to 200 characters) and its position and size, the console messages mentioned above including stack traces and the network requests, each with a timestamp, a screenshot of the visible area together with a reduced-size copy of it, and up to three attachments added by the person reporting, each of 5 MB at most. The screenshot, the attachments, the HTML excerpt and the text of the elements show what is on the page at that moment or what was attached, and may therefore contain personal data. Cookies are not sent. If a report cannot be sent straight away, the browser puts it in local storage without the screenshot and attachments (three at most) and resubmits it on the next visit; after 24 hours it is no longer sent and is discarded the next time a report is made. bugs.9of.de runs on the same server as the application (section 7).
• Error log: unexpected errors of the application, on the server and in the browser alike, are stored with the error message, the technical trace (stack), the path requested, the request method and the browser identifier. A short version (path, error identifier and error message) is emailed to the agency team, at most one email per 15 minutes and source (server or browser). The path is stored without query parameters and without fragment, and segments carrying access codes (for example from invitation or password links) or user identifiers (for example in the address of a profile picture) are masked. We do not record the IP address or the user account with it; the error message and the technical trace may, however, contain technical parameters of the request concerned, such as record identifiers.
• Email log: for every email we store the purpose, recipient addresses and the address actually written to, subject, delivery status, the mail server's response including the message ID, rejected addresses, where applicable the error text or the reason a send was skipped, the duration of the send, the environment and the client concerned, not the content.
• Change log (audit log): business- and security-relevant actions, such as status changes and approvals of posts, the management of logins and account connections and the use of the AI features, are recorded with the acting person, the kind of actor, the time, the record concerned and, where applicable, the status change. If someone from the team takes on the view of a client login, the person actually acting is recorded as well. Some entries carry additional details — when logins are managed, for example, the email address of the person concerned. We do not write names or usernames of connected platform accounts to the log; older entries that still contain them are stripped of them no later than 30 days after the entry.
• Server logs: the application writes technical operating messages, for example about scheduled jobs and errors, to the log of its container on the server. Access tokens are never logged. To prevent abuse, the application briefly counts requests per IP address in memory without storing them. The upstream web server (reverse proxy) keeps no access log.

10. Retention periods

The application's automatic deletions run daily. Where a period below says “no later than”, this daily rhythm is already taken into account.

• User accounts exist until we delete the login. Deleting an account deletes its sessions, passkeys, two-factor data and profile picture, and removes its email address from the change log entries concerning it. The identifier of a device marked as trusted expires no later than 30 days after the last sign-in.
• Sessions are valid for seven days and are extended with use. Expired sessions, including IP address and browser identifier, are deleted 30 days after they expire.
• Content and account connections are stored for the duration of our work with the client concerned; individual posts and media can be deleted earlier. When a client is deleted, we remove in one step (a single database transaction) all of its posts together with their approval history, comments, versions and publishing jobs, its media, its logo, brand profile and settings, its account connections together with their tokens, and the logins of its contacts. Immediately afterwards we delete the associated files in storage (media, logo, profile pictures); if this fails for individual files, they remain and are logged, and they can then no longer be retrieved through the application. Change log entries remain until their 24-month period ends, without the email addresses of the deleted logins. Deletion requires that all accounts have been disconnected first and that no publishing is in progress. Posts already published on Instagram, Facebook, TikTok or YouTube stay online there; we do not delete them along with the client.
• Tokens are deleted immediately when an account is disconnected inside the application. For Meta, where several accounts can share one connection, this applies to the page token of a Facebook Page; the shared token of the connection is deleted once all of its accounts are disconnected. We also delete the tokens of a connection as soon as we detect that the grant was revoked at the platform or has expired; if someone removes only individual accounts from the grant at Meta, the tokens are kept until the accounts are disconnected or reconnected (section 12).
• Disconnected or failing accounts: no later than 30 days after disconnection or the last check, we clear the account's name, username, profile picture address and follower count, and for disconnected or failing connections their display name as well. Disconnected accounts with no posts attached are then deleted entirely together with their metrics, as are disconnected connections without an account. Failing accounts and connections are only cleared, even if no posts are attached to them; they are deleted only after they have been disconnected. Failing Meta accounts of a connection that is still valid continue to be checked every hour; their details therefore remain until they are disconnected. The identifiers of account and connection are kept for as long as posts are attached to them. For YouTube channels a shorter rule applies in addition, even while they are connected (section 13). Usernames of the targets in post version snapshots are removed no later than 30 days after the snapshot was created.
• Metrics: YouTube metrics are deleted no later than 30 days after retrieval. Instagram and Facebook metrics are kept as history until the account, the post concerned or the client is deleted in the application, or a data deletion request via Facebook removes them (section 12).
• Change log: 24 months.
• Email log: 90 days.
• Publishing jobs: successfully completed and cancelled jobs 90 days after their last change; failed jobs remain as a record until the post is deleted.
• Error log: 30 days.
• AI usage data (section 6) is kept for the cost overview without a fixed period. When a client is deleted, its link to that client and the client's posts is removed.
• Server logs: the container logs are rotated by size: at most three files of 10 MB each per service. Once this limit is reached, the oldest entries are overwritten; there is no fixed period in days.
• Bug reports in bugs.9of.de, including screenshots and attachments, are kept until they are deleted there; there is no automatic period.
• Emails sent are kept in the mailbox of the sending account at Google Workspace according to that mailbox's retention rules; the application itself does not delete them.

Statutory retention obligations remain unaffected.

11. Your rights

Data subjects have the right of access, rectification, erasure, restriction of processing, data portability and objection (Art. 15–21 GDPR), and the right to lodge a complaint with a data protection supervisory authority (Art. 77 GDPR). The competent authority is the Bavarian Data Protection Authority (Bayerisches Landesamt für Datenschutzaufsicht, BayLDA) in Ansbach. Please address requests to info@agenturonfleek.com.

12. Deletion of connected platform data

If the application's grant is revoked at the platform or expires, we delete all tokens stored for that connection as soon as we detect it. Nothing is published through the connection after that. If someone removes only individual accounts from the grant at Meta while the connection itself stays valid, we mark those accounts as failing and publish nothing further through them. The connection's tokens are still needed by the remaining accounts; they are therefore kept until the accounts are disconnected or reconnected. Likewise, the page token of a Facebook Page removed in this way is kept until the Page is disconnected or reconnected.

• Meta (Facebook, Instagram): Meta reports the revocation of the grant through a callback, upon which we disconnect the connection straight away and delete its tokens. In addition, the application checks every hour whether the stored tokens are still valid and which accounts the grant still covers. Invalid or expired tokens are deleted and the connection is set to “Error”; accounts no longer covered are set to “Error”.
• TikTok: at the next token renewal, which is due at least once a day; the connection is then set to “Error”.
• YouTube: at the next token renewal, for example during the nightly metrics run or at the next publishing attempt; the connection is then set to “Error”.

If someone requests the deletion of their data via Facebook, we immediately remove, for every connection of their Meta identity and across all clients: the tokens, their name, their Meta user ID and the granted scopes, and, for the accounts connected through it, the metrics and the profile data (name, username, profile picture address, follower count), including in the version snapshots of posts that list these accounts as targets. Accounts with no posts attached are deleted entirely. The agency's post planning, including the references to published posts, remains; posts published on Facebook and Instagram stay there unchanged. A status page shows the state of the request; its confirmation code bears no relation to the Meta user ID.

Beyond that, the deletion of all data stored for an account can be requested at any time at info@agenturonfleek.com.

13. YouTube API Services

To publish videos to connected YouTube channels, on fleek Social uses the YouTube API Services. By using this feature you agree to the YouTube Terms of Service. The Google Privacy Policy applies in addition.

Through the YouTube Data API we process data belonging to the connected channel only: the channel identifier, the channel name and the address of the channel image in order to display the connection, the videos we upload together with their title, description and video identifier, the metrics of the channel and of those videos (views, likes, comments, subscriber count and number of videos), the processing status YouTube reports for an upload and, if YouTube rejects a video, the reason it gives, the address of the published video, the short-lived upload address Google issues while an upload is in progress, and the access and refresh tokens together with their expiry and the list of granted scopes. The refresh token allows the application to reach the API without a user present — required for publishing at the agreed time and for the nightly metrics run. All tokens are stored encrypted, never logged and never passed on to browsers or third parties. Scopes used: youtube.upload to upload approved videos and youtube.readonly to read the channel and video metadata and those metrics. No access to any other channel takes place.

Access can be revoked at any time — either in the security settings of the Google account (third-party apps), or by disconnecting the channel inside on fleek Social or sending an informal message to info@agenturonfleek.com. When the channel is disconnected inside on fleek Social, we delete the stored tokens immediately and also ask Google to revoke the grant. If that request fails, we log it; the grant can then still be removed in the Google account settings. After a revocation in the Google account, we delete the tokens as soon as Google reports it to us at the next token renewal (section 12).

Retention of YouTube data: channel name, channel image and subscriber count of connected channels are refreshed daily through the API; if a channel hides its subscriber count, we delete the stored value in the process. Channel and video metrics are deleted automatically no later than 30 days after retrieval. If channel name, channel image and subscriber count are no longer refreshed — because the channel is disconnected or failing, or because the daily retrieval fails — we clear them no later than 30 days after the last successful retrieval, connected channels included; disconnected channels with no posts attached are deleted entirely no later than 30 days after disconnection. We remove the channel name from post version snapshots no later than 30 days after the snapshot was created. Beyond that, the following is kept for as long as the post planning exists: the channel identifier, the identifier and address of published videos, any error or rejection reason reported by YouTube, and the title and text of the post from which the video's title and description are created. We replace the upload address with the video identifier once the upload is complete; if an upload is abandoned for good or the video identifier cannot be determined afterwards, it stays stored with the post. On the connection, the encrypted tokens are kept until the channel is disconnected or the grant is revoked, their expiry and the list of granted scopes for no longer than the connection itself exists, together with the channel name, which we refresh daily and, as described above, clear no later than 30 days after the last successful retrieval. On request we delete the data belonging to a channel earlier.