Data Processing Agreement
The agreement under Article 28(3) GDPR between you (controller) and plugwith.me (processor). It covers every piece of personal data we handle on your behalf: the click events from your links, the entries your visitors send through your forms, the logins you create for your team, and the personal data you put into your link pages. It includes the transfer clauses, the full annexes, and the country-specific terms. In German law this document is the Auftragsverarbeitungsvertrag (AVV).
This agreement is already in force. You do not have to sign anything. It is part of the Terms of Service and applies on every plan, including the free plan, from the moment you create your first link. It is the complete agreement, not a summary — Annexes I to IV are the processing description, the security measures, the subprocessor list and the non-EU terms. If your compliance process needs a countersigned PDF, write to info@plugwith.me and we will send one within five business days, free of charge.
Which version applies to you. Version 3.3 was published on 21 October 2026 and takes effect on 20 November 2026. The gap is the 30 days' notice section 18.1 and section 2.3 of the Terms promise before a change binds an existing account: version 3.3 adds a new processing stream — the entries your visitors send through forms — and section 7.9 places new obligations on you for it. Until then, version 3.2 continues to govern accounts that existed on 21 October 2026. Accounts created on or after that date accept this version at signup, so it binds them from the day they sign up. You can accept it early from the dashboard; you can object in text form to info@plugwith.me before the effective date, and either party may then terminate at that date with a pro-rata refund.
What applies to every account at once. Changes that are purely to your advantage take effect immediately under section 2.3 of the Terms, whichever version governs your account: the storage of your data in the European Union since 21 October 2026 (sections 14.1, 14.5 and 14.7 and Annex III), the exclusion of form entries from our statistics (section 5.1), and the descriptions of the API, webhooks and the MCP endpoint in sections 3.2 and 6.5, which state how we already act on your instructions and add no obligation for you. Everything else in this version, including section 2.7, binds an existing account from 20 November 2026 or from your earlier acceptance.
Forms need this version. The form block can be used on an account only once version 3.3 applies to it — from your acceptance in the dashboard, or otherwise from 20 November 2026 if you have not objected. Entries are only ever received under an agreement that describes them.
1. Who this agreement is between
1.1 This agreement ("DPA") is between:
- the natural or legal person holding an account at plugwith.me, as controller ("you", "Customer"); and
- Eray Yilmaz, sole proprietor trading as plugwith.me, Europaring 90, 53757 Sankt Augustin, Germany, as processor ("we", "Provider").
1.2 Subject matter. We host short links and link-in-bio pages for you, serve them to your visitors, record traffic statistics about them, receive and store for you the entries your visitors send through forms you place on your pages, and make your data available to you and to the systems you connect. Providing that service is the subject matter of the processing.
1.3 Duration. This DPA starts when you first create a link and runs for as long as we process personal data for you. Sections 12, 15, 16 and 18 survive its end.
1.4 Who determines what. You determine the purposes of the processing. You also determine the essential means: which links exist, where they point, which countries are blocked, how visitors are routed, which pixels and embedded players run, which forms ask for what and for how long the entries are kept, which systems you connect, who on your team gets a login. We determine the non-essential technical means — the database layout, the classification logic, the caching, the field names — as any processor does under Article 28. Deciding how to implement your instruction does not make us a controller.
1.5 Precedence. Where documents conflict: the Standard Contractual Clauses in section 14 come first, then this DPA, then the Terms of Service. The Privacy Policy describes our own controller processing and does not change this DPA.
1.6 Form. This DPA is concluded electronically. Article 28(9) GDPR allows electronic form, and neither party needs to sign it for it to bind. Your own supplier terms, procurement DPA or security questionnaire do not apply and do not amend this DPA unless we accept them in a separate document signed by us.
2. What this covers — and what it does not
2.1 Covered ("Customer Personal Data"). Four streams, all described in Annex I:
- Visitor click events — what we record when someone opens one of your links, clicks a button or completes a quiz.
- Team logins — the people you give access to your account (Agency plan and above).
- Personal data inside your content — creator names, photos, background videos, profile text, destination URLs and anything else you type or upload, including copies of it we send to the endpoints you connect.
- Form submissions — what a visitor sends through a form block on one of your pages.
2.2 Not covered — our own controller data. Your account, your billing data and your support emails are processed by us as controller, not as processor. That is covered by the Privacy Policy, not by this DPA. Stripe is an independent controller for payment data, not our subprocessor for it.
2.3 Not covered — marketing pixels and embedded players. If you switch on a Meta, Google, TikTok or Snap pixel, that pixel runs in the visitor's browser and sends data straight to that provider. The same is true of a YouTube or Spotify player you embed, once the visitor has clicked to load it. Nothing passes through our systems, we get nothing back, and we have no contract with them for it. For that processing you are the controller — in some setups jointly with the provider under Article 26 GDPR — and you need your own arrangements. We are not a processor, controller or joint controller for it. See Cookie Policy §§ 3 and 4.
2.4 Not covered — where your links point. Once a visitor leaves our page, the destination site processes their data on its own account. We have no control over it and are not a processor for it.
2.5 Purely private use. If you use the Service for a purely personal or household activity, Article 2(2)(c) GDPR means the GDPR does not apply to your processing and no processor relationship arises. This DPA then has no subject matter. It applies as soon as your use is professional or commercial, however small.
2.6 If you are yourself a processor. Where you act for someone else (for example, an agency acting for a creator), you warrant that you are authorised to appoint us as subprocessor on your client's behalf and to give us the instructions in this DPA. Module Three of the Standard Contractual Clauses then applies (section 14.2).
2.7 Data you send onwards. Through the API, webhooks and the MCP endpoint you can have your Customer Personal Data delivered to systems you choose — your own servers, a service you use, or an AI assistant you connect. Configuring a key or an endpoint, and every request made with a key, is your documented instruction to make that delivery, including to a recipient outside the European Economic Area (Article 28(3)(a) GDPR). The recipient is chosen by you and is not our subprocessor; you are responsible for having a legal basis for the disclosure and, where the recipient is in a third country, for the transfer instrument with it. We deliver only over HTTPS to public addresses, sign every webhook message, and send no data about an individual visitor and no form entries by webhook (Annex I, B.3).
3. Your instructions
3.1 We process Customer Personal Data only on your documented instructions, including for transfers to a third country, unless Union or member-state law requires otherwise. If a law requires it, we tell you before processing, unless that law forbids us from telling you on important grounds of public interest.
3.2 What counts as an instruction. Together, these are your complete documented instructions: this DPA, the Terms of Service, and everything you configure in the dashboard — the links you create, the settings you choose, the forms you place and the retention period you set for them, the team logins you issue, the exports you ask for, the API keys and webhook endpoints you create and every request made with one of those keys, and the support requests you send. Nothing else is needed for an instruction to be documented.
3.3 Extra instructions. Any instruction beyond that must be sent in text form to info@plugwith.me. Where an instruction needs work the Service does not provide as standard, we may charge a reasonable fee, agreed with you in advance, and we may set a reasonable deadline.
3.4 Unlawful instructions. If we believe an instruction breaches the GDPR or other Union or member-state data protection law, we tell you without undue delay. We may suspend that instruction until you confirm or change it. Suspending it is not a breach of the Terms and does not entitle you to a refund or to damages.
3.5 Our own legal duties are not your instruction. Removing illegal content, answering a valid order from a court or authority, and meeting our duties under the Digital Services Act are acts we perform as controller under a legal obligation. Doing them is not a breach of this section. Our notice-and-action mechanism is at plugwith.me/report.
4. What we never do
4.1 We do not process Customer Personal Data for our own purposes, apart from the anonymous statistics in section 5.
4.2 We do not sell it, share it for cross-context behavioural advertising, rent it, or use it for advertising of any kind.
4.3 We do not combine it with personal data we hold from any other source.
4.4 We do not use it to train, fine-tune or evaluate any machine-learning model, and we require the same of every subprocessor (section 6).
4.5 We run no analytics vendor, no CRM, no session recording, no advertising network and no data broker on any surface that touches Customer Personal Data. No third-party script is loaded into any page of this service; the only third-party content that can appear is what you choose to add — a pixel, after the visitor accepts, or an embedded player, after the visitor clicks (section 2.3).
5. Anonymous statistics
5.1 You instruct and permit us to produce anonymous, aggregated statistics from Customer Personal Data — for example, how many taps arrive from inside an in-app browser, split by app and device class. We may use and publish those statistics, including for research, security and marketing, during and after the term. Form submissions are never used for this, not even in aggregated form.
5.2 What "anonymous" means here. Only counts and percentages leave the aggregation. No output identifies, names or allows the identification of a visitor, of you, of one of your links or of one of your destinations. Small groups are not published: a bucket must contain at least 50 records before it is reported separately, and a whole sample must contain at least 2,000 records before any figure from it is published at all. Buckets below the floor are merged into an "other" line.
5.3 We do not attempt, and do not permit anyone else to attempt, re-identification of the underlying records. Recital 26 GDPR applies to the result: once anonymous, it is no longer personal data and no longer subject to this DPA.
5.4 You can object to the use of your account's data for published statistics at any time by writing to info@plugwith.me. We will exclude your links from future aggregation. Figures already published are not recalculated, because they contain nothing traceable to you.
6. No artificial intelligence in the processing
6.1 The Service contains no AI system within the meaning of Article 3(1) of Regulation (EU) 2024/1689 (the AI Act). We are neither a provider nor a deployer of an AI system in delivering it. Bot detection, device classification and geo-blocking are fixed, rule-based filters — pattern matches written by hand, with no model, no inference and no learning.
6.2 There is no automated decision-making producing legal or similarly significant effects on any individual within the meaning of Article 22 GDPR, and no profiling. A blocked bot or a geo-blocked visit is a technical filter on a request, applied on your instruction, not a decision about a person.
6.3 No Customer Personal Data is used for AI training, fine-tuning, evaluation or retrieval augmentation, by us or by any subprocessor.
6.4 If any of this changes, we will notify you under the subprocessor procedure in section 11.2 before the change takes effect, and you may object on the same terms.
6.5 AI assistants you connect. The MCP endpoint lets an AI assistant you choose read and change your links and read your aggregated statistics, using an API key you created. That assistant, and the provider behind it, are your choice and your recipients under section 2.7, not our subprocessors; what it receives is what it asks for with your key. Offering the endpoint does not make us a provider or deployer of an AI system, and our servers do not contact any AI provider.
7. Your obligations and warranties as controller
This section is what lets us process lawfully. Each point is something only you can guarantee.
7.1 Lawfulness. You are responsible for the lawfulness of the collection and of your instructions. You warrant that you have a valid legal basis under Article 6 GDPR for every processing operation you instruct, including the click statistics and any pixel you enable, and that you meet your own information duties towards visitors under Articles 12 to 14.
7.2 Consent. Where consent is the basis — in particular for marketing pixels, and for any storage or access on the visitor's device that is not strictly necessary — obtaining, recording and being able to prove that consent is your duty. Our consent banner is a technical aid: it stores the visitor's choice in that visitor's own browser and sends us no record of it, so we cannot supply you with evidence of consent and do not claim to. The same applies to the click-to-load placeholder of an embedded player: it keeps the player unloaded until the visitor clicks, and records nothing. The consent box of a form is different — its wording, its link and the time of sending are stored with the entry (section 7.9).
7.3 No special categories. You must not instruct processing of data in the special categories of Article 9 GDPR, of data on criminal convictions under Article 10, or of data relating to children. The Service is built for adults and is not designed, secured or priced for any of that. If you do it anyway, you do it outside your instructions and section 16.4 applies.
7.4 Uploads are public. Images and background videos you upload are stored in publicly readable buckets, because they have to be fetched by every visitor's browser and used as share previews. Anyone who has the URL can open them. You warrant that you hold the rights and, where a person is shown, the consents needed to publish them, and you must not upload anything you would not publish on an open web page.
7.5 Your team. If you create logins for your staff, you are their controller. You must have a legal basis for it, tell them their data is processed here, choose passwords that meet the rules the dashboard states, hand them over securely, and remove people who leave. We cannot know when someone leaves your company; only you can.
7.6 Your account details. Keep your account email address current. It is where breach notices under section 12 and subprocessor notices under section 11 are sent. A notice sent to the address on your account counts as delivered.
7.7 You have assessed our measures. You confirm that you have reviewed Annex II and consider the measures appropriate to the risk of the processing you instruct, as Article 28(1) GDPR requires of you when choosing a processor. If your processing needs a higher level of protection than Annex II describes, do not instruct it here; tell us instead, and we will say whether we can meet it and on what terms.
7.8 Indemnity. You will hold us harmless against third-party claims, fines and reasonable legal costs to the extent they arise from (a) your breach of this DPA or of your duties as controller, (b) an instruction that infringes data protection law, (c) content, uploads or destinations you supplied, or (d) processing you carried out outside these instructions. This does not apply to the extent the claim is caused by our own breach of this DPA, by our negligence, or by processing we carried out contrary to your lawful instructions. We will notify you of any such claim without undue delay, will not settle it without your consent (not to be unreasonably withheld), and will give you reasonable opportunity to take over the defence at your cost.
7.9 Forms. If you place a form on a page, you decide which fields it asks for, why, and for how long the entries are kept, and you are responsible for those decisions. In particular you warrant that:
- (a) you have a valid legal basis for collecting and using each field, and that the consent wording and the privacy-notice link you enter are accurate and lead to your own privacy notice, which meets Articles 13 and 14 GDPR for this collection. The wording the editor suggests for a new form is a starting point only; you must adapt it to what you actually do with the entries, and where your legal basis is not consent, you must not present it as consent;
- (b) you do not use a form to ask for data in the special categories of Article 9 GDPR, data on criminal convictions under Article 10, data relating to children, passwords or other login credentials, payment card or bank account numbers, or government identification numbers (section 7.3 applies);
- (c) where you use the entries for advertising by email, phone or message, you obtain and can prove any consent the law requires for it, including a confirmation of the address (double opt-in) where that is needed. The form's consent box records what the visitor was shown and ticked; it does not confirm that an email address belongs to the person who entered it;
- (d) you choose a retention period no longer than your purpose needs, and you delete entries earlier when that purpose has been served or a person asks you to;
- (e) you answer requests from the people who sent entries. The dashboard lets you find, export and delete every entry; we forward to you without undue delay any request that reaches us (section 10.3).
The Service requires an unticked consent box, your wording and your privacy-notice link on every form that contains a field able to hold personal data, and stores that wording, that link and the time of sending with each entry so that you can demonstrate what the visitor was shown (Article 7(1) GDPR). It sends no notification of an entry by email or webhook, and the entries are not part of the JSON export of your settings; you retrieve them from the dashboard, form by form.
8. Confidentiality
8.1 Every person we authorise to process Customer Personal Data is bound by a confidentiality obligation that survives the end of their engagement, or is under an appropriate statutory duty of confidence.
8.2 Access is limited to the people who need it to deliver the Service. Today that is the proprietor and any staff or contractor expressly authorised in writing.
8.3 Everyone acting under our authority processes Customer Personal Data only on our instructions, as Article 32(4) GDPR requires.
9. Security
9.1 We implement and maintain the technical and organisational measures in Annex II. They meet Article 32 GDPR having regard to the state of the art, the cost of implementation, and the nature, scope, context and purposes of the processing as well as the risk to individuals.
9.2 We may change those measures as technology and threats change, provided the overall level of security is not reduced. Material changes are published in Annex II with a new date.
9.3 Annex II describes the measures for the Service as offered. It is not a promise of measures a specific plan does not include, of a bespoke configuration, or of any control we have not described there.
9.4 Security within your own sphere is yours: your credentials, your team's credentials, your second factor, your devices, your API keys and webhook signing secrets, the systems you connect and what they do with the data they receive, the destinations you link to, and the pixels and players you enable. Revoke a key you suspect has leaked; we cannot tell a stolen key from yours. We enforce a second factor at our API once you enable it, but we cannot enable it for you.
10. Help with your own duties
10.1 Requests from individuals. Taking into account the nature of the processing, we help you meet requests under Chapter III GDPR by appropriate technical and organisational measures, so far as that is possible. Because the click events contain no identifier for any visitor, we are technically unable to find, export, correct, restrict or delete the records of one specific visitor inside them. We will confirm that in writing to you or to a supervisory authority on request. This is a consequence of data minimisation, not a refusal.
10.2 For the data we can locate — your team logins, your content and your form submissions — the dashboard gives you direct control, which is normally faster than asking us. Form submissions carry the details the visitor entered; the dashboard lists them per form, exports them as a CSV file and deletes them one by one or per form.
10.3 If a visitor contacts us. We do not answer on your behalf. We pass the request to you without undue delay and tell the person we have done so.
10.4 Articles 32 to 36. Taking into account the nature of the processing and the information available to us, we help you with security, breach notification, data protection impact assessments and prior consultation. This DPA, its annexes and the Privacy Policy are designed to give you what a DPIA needs; you do not have to ask for them.
10.5 Article 28(3)(h) information. We make available all information necessary to demonstrate compliance with Article 28 GDPR.
10.6 Fees. The help described above is free. Where your request goes beyond it — bespoke reports, filling in a supplier questionnaire, an unscheduled audit, forensic work beyond what section 12 requires — we may charge our reasonable time at a rate agreed in advance.
11. Subprocessors
11.1 General authorisation. You give a general written authorisation for us to engage subprocessors. Those engaged today are listed in Annex III and, in current form, at plugwith.me/subprocessors, which is the authoritative version.
11.2 Notice. We tell you in text form at least 30 days before we add or replace a subprocessor. Notice goes to your account email address; you can also subscribe a compliance mailbox at plugwith.me/subprocessors.
11.3 Objection. You may object within 30 days of that notice, on reasonable grounds relating to data protection, stating them. We will then make reasonable efforts to offer the Service without that subprocessor, or to propose a change that resolves your concern. If we cannot within a reasonable period, either party may terminate the affected part of the Service on 30 days' notice, and we refund prepaid fees for the unused period pro rata. That refund is your sole remedy for an objection. Using the Service after the effective date without objecting counts as approval.
11.4 Flow-down and liability. We impose on every subprocessor, by contract, data protection obligations that are in substance the same as ours here — in particular sufficient guarantees of appropriate technical and organisational measures. Where a subprocessor fails to meet its data protection obligations, we remain fully liable to you for its performance (Article 28(4) GDPR).
11.5 Emergency replacement. If a subprocessor has to be replaced at short notice for security or continuity reasons, we may do it immediately and will tell you without undue delay, with reasons. Your right to object then applies afterwards.
11.6 Not subprocessors. A vendor that never receives Customer Personal Data is not a subprocessor. That includes the pixel and player providers in section 2.3, the destination sites in section 2.4, the recipients you choose under section 2.7, and our own mailbox and accounting providers, which touch only our controller data.
12. Data breaches
12.1 We notify you without undue delay and in any event within 48 hours of becoming aware of a personal data breach affecting Customer Personal Data. That gives you a day to meet your own 72-hour deadline under Article 33 GDPR.
12.2 "Becoming aware" means having a reasonable degree of certainty that a security incident has led to personal data being compromised, in line with EDPB Guidelines 9/2022. A period of investigation to reach that certainty is not delay.
12.3 Content. The notice goes to your account email address and states, so far as known: the nature of the breach; the categories and approximate number of data subjects and records concerned; the likely consequences; the measures taken or proposed; and a contact point. Where we cannot give everything at once, we give it in phases without further undue delay.
12.4 Who notifies whom. We do not notify supervisory authorities or data subjects on your behalf unless you instruct us to and we agree. We help you with any notification you make.
12.5 Not an admission. Notifying you is not an acknowledgement of fault or liability.
12.6 Costs. Investigation, containment and notification on our side are at our cost. Forensic work, reports or support you request beyond that is chargeable under section 10.6, unless the breach was caused by our breach of this DPA.
13. Audits
13.1 We make available all information necessary to demonstrate compliance with Article 28 GDPR, and allow for and contribute to audits, including inspections, by you or an auditor you mandate.
13.2 How this works in practice. In the first instance we satisfy it with this DPA and its annexes, the current subprocessor list, our security page at plugwith.me/security, and the independent audit reports and certifications of our subprocessors where we are allowed to pass them on. Where that is genuinely not enough to demonstrate compliance, you may audit on site or remotely, subject to all of the following:
- once per calendar year;
- at least 14 days' written notice;
- during normal business hours, without unreasonably disrupting our operations;
- under an appropriate confidentiality agreement;
- the auditor must not be a competitor of ours;
- at your cost, including our reasonable time at a rate agreed in advance;
- no access to data of other customers, to our source code, or to credentials.
13.3 Extra audits are allowed where a supervisory authority requires one, or after a personal data breach affecting your data. Those are not counted against 13.2 and, in the breach case, are at our cost.
13.4 Data centres. We do not operate any, so we cannot grant physical access to one. For our subprocessors we pass on the reports and certifications they make available.
14. International transfers
14.1 Where the data is. Since 21 October 2026, Customer Personal Data is stored in the European Union, in AWS region eu-central-1 (Frankfurt, Germany), by our subprocessor Supabase. Until that date it was stored in the United States (AWS us-east-2, Ohio); the former project is deleted once the move has been verified, and in any event by 20 November 2026. Pages are served from a global edge network, so processing also happens wherever the visitor is. Supabase is a group of companies established outside the EU — our contract partner is Supabase Pte. Ltd. in Singapore — and its staff may access the systems for support and operations from outside the EU; that access is a transfer and rests on the Clauses below. We do not rely on the EU–US Data Privacy Framework for Supabase. Netlify is certified under it.
14.2 Standard Contractual Clauses. Where Customer Personal Data is transferred to a country without an adequacy decision, the parties incorporate by reference the Standard Contractual Clauses annexed to Commission Implementing Decision (EU) 2021/914, as follows:
- Module Two (controller to processor) where you are a controller, and Module Three (processor to processor) where you are yourself a processor;
- Module Four (processor to controller) where you are established in a country without an adequacy decision and we make Customer Personal Data available to you — in the dashboard, as an export, through the API or by webhook;
- Clause 7 (docking clause): applies;
- Clause 9: Option 2, general written authorisation, with the 30-day notice period in section 11.2;
- Clause 11: the optional independent dispute-resolution body is not used;
- Clause 17: governed by the law of Germany;
- Clause 18(b): the courts of Sankt Augustin, Germany;
- SCC Annex I.A, I.B and I.C are populated by parts A, B and C of Annex I below; SCC Annex II is populated by Annex II below; the list of subprocessors under Clause 9 is Annex III below.
14.3 United Kingdom. Where UK GDPR applies, the parties incorporate the International Data Transfer Addendum to the EU SCCs issued by the Information Commissioner (version B1.0). Tables 1 to 3 are populated by this DPA and its annexes; Table 4 selects "neither party" as the party that may end the Addendum under section 19; the ICO is the competent authority.
14.4 Switzerland. Where the Swiss FADP applies, the SCCs apply with references to the GDPR read as references to the FADP, "member state" read so that Swiss data subjects can enforce their rights in Switzerland, and the FDPIC as competent authority.
14.5 Transfer impact assessment. We have carried one out for the transfers in Annex III. It is published in full in Privacy Policy § 7.1 and forms part of this DPA. In summary: the data is stored in Frankfurt, so what remains is remote access by provider staff and access a foreign authority could compel from a provider with a US group company or US infrastructure operator. The click events contain no IP address, no raw user agent, no cookie or device identifier and nothing linking two events by the same visitor, so a compelled disclosure would produce records that identify nobody. Form submissions are the identifying part — names, email addresses, phone numbers and messages of your visitors — and are why the storage moved to the EU before forms were offered. Special-category data is excluded (sections 7.3 and 7.9). Team logins and content are a small volume of business-contact and published-content data. On that basis we consider the safeguards adequate. We will tell you without undue delay if we become unable to comply with the Clauses, and you may then suspend the transfer or terminate.
14.6 Government access. Unless legally prohibited, we will: tell you about any legally binding request from a public authority for Customer Personal Data; challenge requests that look unlawful or excessive, including under the Clauses; and disclose only the minimum permitted. We maintain no direct or indirect back door, and no authority has ever asked us for one. Where notification is prohibited, we will use best efforts to obtain a waiver and will document the request for later disclosure. We publish moderation and disclosure actions in the register linked from plugwith.me/report.
14.7 Region change. Moving the stored data to another region changes the transfer situation. A move out of the European Economic Area is notified at least 30 days before it takes effect, under section 11.2, and you may object under section 11.3. A move into the European Economic Area, or within it, is notified in text form before it takes effect; because it can only improve your position, it is not held back by a notice period. The move to Frankfurt on 21 October 2026 was notified on that basis.
15. Deletion and return
15.1 At your choice, we delete or return all Customer Personal Data when we stop providing the Service, and delete existing copies, unless Union or member-state law requires us to keep it.
15.2 The default is deletion. If you do not instruct otherwise within 30 days of termination, we delete.
15.3 Timing. Account data, team logins, link configuration and uploads are deleted from production within 30 days of termination. Raw click events are deleted by the automated retention job described in Annex I, at the latest within 90 days. Form submissions are deleted when the retention period you set for the form ends, and in any event together with the account data. Webhook delivery records are deleted after 30 days. Encrypted backups holding the data expire on their normal rotation, in any event within a further 90 days, and are not accessed in the meantime except to restore service.
15.4 Return. You can download your links and settings yourself from the dashboard as a JSON file, and the entries of each form as a CSV file, at any time and also during the 30-day window. On request within that window we supply anything else we hold for you — including your analytics — in a structured, commonly used, machine-readable format, free of charge. After the window, a restore is only possible if a backup still holds the data, and we may charge our reasonable time for it.
15.5 Legally required retention. Data we must keep by law — in particular invoices and accounting records, which German law requires us to keep for ten years — is kept and blocked from every other use.
16. Liability
16.1 Liability under this DPA follows Article 82 GDPR and, in all other respects, the liability provisions of the Terms of Service, including any cap and any exclusion of indirect and consequential loss agreed there. This DPA does not create a second, separate liability regime.
16.2 Article 82(2). As processor, we are liable for damage caused by processing only where we have not complied with obligations the GDPR directs specifically at processors, or where we have acted outside or contrary to your lawful instructions.
16.3 Rights of individuals are untouched. Nothing here limits a data subject's rights under Article 82 GDPR or under the Standard Contractual Clauses, and no allocation between us affects them.
16.4 Allocation. Between us, each party bears the part of any fine, claim or damage that corresponds to its own share of responsibility. To the extent a claim results from your instruction, your content or your breach of section 7, you bear it, and section 7.8 applies. To the extent it results from our breach of this DPA, we bear it.
16.5 No double recovery. Where the same loss could be claimed under both this DPA and the Terms of Service, it can be recovered once.
16.6 Nothing in this DPA excludes liability that cannot be excluded by law, including for injury to life, body or health, for intent, and under the German Product Liability Act.
17. Records, contact and supervision
17.1 Records. We keep the record of processing activities carried out on your behalf required by Article 30(2) GDPR, and make the entries relevant to you available on request.
17.2 Data protection contact. info@plugwith.me, Eray Yilmaz, Europaring 90, 53757 Sankt Augustin, Germany, +49 156 79 729 585. Please put "Data protection" in the subject line.
17.3 Data protection officer. We have assessed Article 37 GDPR and § 38 BDSG and are not required to designate one: our core activity is not large-scale regular and systematic monitoring — the click events carry no identifier that would allow any individual to be monitored — we process no special-category data on a large scale, and we do not employ 20 or more people on automated processing. The contact point in 17.2 answers data protection matters. If a designation becomes mandatory, we will make it and publish the details.
17.4 EU representative. Not required. We are established in the European Union, so Article 27 GDPR does not apply.
17.5 Supervisory authority. The authority competent for us is named in Annex I.C. You may always complain to the authority of your own member state.
18. Changes and general terms
18.1 Changes. We may amend this DPA where a change in the law, a decision of a supervisory authority, a court ruling or a change in the Service requires it, following the notice procedure in section 2.3 of the Terms. An amendment must never reduce the level of protection. The version and effective date at the top of this page always show what is in force; we keep the change history in the table at the end.
18.2 Governing law. German law applies, excluding the UN Convention on Contracts for the International Sale of Goods.
18.3 Jurisdiction. The exclusive place of jurisdiction is Sankt Augustin, Germany, so far as mandatory law permits and without prejudice to Clause 18 of the Standard Contractual Clauses. Where you are a consumer, the statutory rules on jurisdiction apply instead.
18.4 Severability. If a provision is or becomes invalid, the rest stays in force, and the invalid provision is replaced by a valid one that comes closest to what the parties intended.
18.5 No waiver. Not enforcing a right on one occasion does not waive it.
18.6 Assignment. You may not assign this DPA without our written consent. We may assign it to a successor in a merger, reorganisation or sale of the business, on notice to you; your right to terminate under the Terms is unaffected.
18.7 Notices. Text form (email) is enough for every notice under this DPA. Ours go to your account email address; yours go to info@plugwith.me.
18.8 Language. English is the binding version. Any translation is for convenience. Where German law prescribes a specific wording, that German wording prevails for that passage only.
18.9 Entire agreement. This DPA and the Terms of Service are the entire agreement on the processing of Customer Personal Data and replace every earlier arrangement on it, including earlier versions of this document.
Annex I — Description of the processing
A. List of parties
Data exporter / controller: the account holder, identified by the registration details in their plugwith.me account. Contact: the account email address. Activities relevant to the transfer: publishing short links and link-in-bio pages, collecting entries through forms on those pages, giving team members access to the account, connecting its own systems, and reviewing traffic statistics. Role: controller (Module Two), or processor (Module Three) where acting for a third party.
Data importer / processor: Eray Yilmaz, trading as plugwith.me, Europaring 90, 53757 Sankt Augustin, Germany. Contact: info@plugwith.me, +49 156 79 729 585. Activities relevant to the transfer: hosting and serving the Customer's link pages, receiving and storing form submissions, operating the account and its team logins, delivering data to the endpoints the Customer connects, and recording aggregate traffic statistics. Role: processor.
B. Description of the processing
Four streams. Each is described separately because the data, the people and the retention differ.
B.1 Visitor click events
| Categories of data subjects | End visitors who open a URL of the form plugwith.me/<slug>, or the same page on a custom domain the Customer has connected. |
|---|---|
| Categories of personal data | Per page open and per button click: the slug; a timestamp; a coarse device class (ios, android, desktop, other); a coarse browser or in-app-browser class (e.g. safari, chrome, instagram, tiktok); an ISO 3166-1 alpha-2 country code derived at the edge from the IP address; flags recording whether bot protection or the geo-block filtered the request and why; for button clicks, the button label and the destination URL; for a visit served under a routing rule or split test the Customer configured, the number of that rule or variant; and, when a visitor finishes a quiz, which quiz and which of its results was reached — never the answers given. |
| Held only in the request, never stored | The IP address and the full user-agent string, used to derive the country, detect bots and apply rate limits. The first language of the browser's language preference, used only to apply the Customer's routing rules. The city, used only to render a "near <city>" badge in the page sent back to that same visitor. None of these is written to our database. Netlify holds them in its own access logs as our subprocessor. |
| Stored on the visitor's device, not by us | The consent choice for marketing pixels (browser local storage, key pw_consent, no identifier, expires) and, where an age gate is used, a per-session confirmation flag. Neither is transmitted to us. |
| Not an identifier | Analytics beacons carry a short token so that only a page we served can report a click. The token is a keyed hash of the slug and a time window. It is identical for every visitor of that page in that window, so it identifies the page, never the person. No cookie, device identifier, fingerprint, session id or account id is set or stored, and nothing links two events by the same visitor. |
| Special-category data | None is requested or intentionally processed. Slugs and destinations are chosen by the Customer, so a destination may reveal an interest in adult content; the Customer is responsible for the lawfulness of that (section 7.3). No health, biometric, genetic, political, religious or trade-union data is processed. |
| Data concerning children | None. The Service is for adults. See section 14 of the Privacy Policy. |
| Frequency | Continuous, on each request. |
| Nature of the processing | Collection, classification, structuring, storage, aggregation, retrieval for display in the Customer's dashboard, and erasure. |
| Purpose | Giving the Customer reach and click statistics for their own links, including the results of its split tests and quizzes, routing visitors to the destination the Customer set for their kind of request, and protecting those links against automated and geographically excluded traffic. |
| Retention | 90 days for raw rows, enforced by an automated deletion job that runs daily; rows whose link no longer exists are deleted in the same run. On plans sold with a full analytics history (currently Business), raw rows are kept for the contract term instead and deleted on termination under section 15. Statistics derived from these rows are anonymous and are kept indefinitely (section 5). |
B.2 Team logins (Agency plan and above)
| Categories of data subjects | The people the Customer authorises to use its account — its employees, freelancers or agency staff. |
|---|---|
| Categories of personal data | Email address; display name, if given; role (manager, staff, viewer); active or suspended; whether a verified TOTP second factor exists; who created the login; timestamps. Authentication credentials are held by our subprocessor's authentication service as a bcrypt hash; the password the Customer chooses is passed straight to it and is never stored by us in readable form. |
| Special-category data | None. The Customer must not enter any. |
| Frequency | On creation, on each change by the Customer, and on each request the person makes. |
| Nature of the processing | Collection, storage, authentication, authorisation, suspension and erasure. |
| Purpose | Letting the Customer share its account with named people, at a role it chooses, and withdraw that access. |
| Retention | Until the Customer removes the person, or the account ends. Removal deletes the authentication user first, so access stops immediately, and the membership row second. |
B.3 Personal data inside the Customer's content
| Categories of data subjects | Anyone the Customer chooses to feature or name — typically the creators whose pages the Customer builds, and any person shown in an uploaded image or video. |
|---|---|
| Categories of personal data | Creator and profile names; profile photographs; background images and short videos; images placed in page blocks; profile text, block texts, button labels and alt text; destination URLs and the addresses of embedded videos or tracks; the questions of forms and quizzes; routing rules, UTM values and geo-block lists; pixel identifiers. Whatever the Customer types or uploads. |
| Sent onwards on the Customer's instruction | Through the API and the MCP endpoint, the link configuration and aggregated statistics the request asks for. By webhook, the configuration of a link when it is created or changed, its slug when it is deleted, and a daily count of visits and clicks per link — never data about an individual visitor and never form submissions. A copy of each webhook message is kept for 30 days for retries and the delivery log, together with its status and the HTTP status code returned; the body of the recipient's answer is never stored. |
| Public by design | Uploaded images and videos are stored in publicly readable buckets and are reachable by anyone with the URL, because every visitor's browser and every share preview has to fetch them. Limits: images up to 2 MB (JPEG, PNG, WebP); background media up to 20 MB (JPEG, PNG, WebP, MP4, WebM). |
| Frequency | On each change by the Customer; read on each visitor request. |
| Nature of the processing | Storage, publication, retrieval, transmission to the endpoints the Customer connects, and erasure. |
| Purpose | Rendering the pages the Customer has configured, and making the Customer's data available to the Customer's own systems. |
| Retention | Until the Customer deletes it, or the account ends (section 15). Webhook delivery copies: 30 days. |
B.4 Form submissions
| Categories of data subjects | End visitors who send a form the Customer has placed on one of its pages. |
|---|---|
| Categories of personal data | The values entered in the fields the Customer configured — depending on the form: name, email address, telephone number, short or long free text, a choice from a list, a ticked box — with the field labels as shown; the page and form; the time of sending; where the form asks for consent, the consent wording and privacy-notice link shown, the time of sending being the time of consent; where a quiz on the same page leads into the form, the title of the result reached; and the date on which the entry will be deleted. |
| Pseudonymised, for abuse prevention only | A keyed hash of the visitor's IP address and the calendar day (HMAC-SHA-256 with a secret held only by us), used only to limit how often one visitor can send a form. It changes every day and is removed by a daily job once it is two days old, so it exists for at most three days. In addition, the edge server keeps the IP address in memory for up to ten minutes to count submissions; it is never written to the database. |
| Not stored | The IP address, the user agent, any cookie or device identifier. |
| Special-category data | None may be requested (sections 7.3 and 7.9). The field types the Service offers are not designed for it. |
| Data concerning children | None. The Service is for adults, and the Customer must not use a form to collect data from children. |
| Frequency | On each submission. |
| Nature of the processing | Collection, validation, storage, display in the Customer's dashboard, export to the Customer as a CSV file, erasure. |
| Purpose | Letting the Customer collect sign-ups, enquiries or answers from its visitors on its own page, for the purpose the Customer determines. We use the entries for no purpose of our own, including statistics (section 5.1). |
| Who can see them | The account owner and the team members whose role allows editing links. Not the operator console, and not any subprocessor beyond storage and hosting. |
| Retention | The period the Customer chooses for each form — 30, 90, 180 or 365 days, by default 90 — enforced by an automated deletion job that runs daily; earlier where the Customer deletes an entry or all entries of a form; in any event with the account (section 15). Removing a form or a link does not delete entries already received; they remain available to the Customer until their period ends. |
B.5 Subprocessor processing
Subject matter, nature and duration as set out in Annex III. No subprocessor receives more than what the row describes.
C. Competent supervisory authority
Bayerisches Landesamt für Datenschutzaufsicht (BayLDA), Promenade 27, 91522 Ansbach, Germany.
This is the authority for the processor's main establishment in the sense of Article 4(16) GDPR — the place of central administration, which is in Bavaria. The postal address in the imprint is in North Rhine-Westphalia; competence follows the establishment, not the correspondence address, which is why the two name different states. Where the exporter is established in another member state, the authority of that member state is competent for the exporter, and a data subject may in any case complain to the authority of their own habitual residence (Article 77(1) GDPR).
Annex II — Technical and organisational measures
Measures as at 21 October 2026, implemented under Article 32 GDPR. Where a measure is delivered by a subprocessor, that is stated. This annex populates Annex II of the Standard Contractual Clauses.
| Area | Measures |
|---|---|
| Pseudonymisation and minimisation | Event records are designed to carry no identifier of any individual: no IP address, no raw user agent, no cookie, no device identifier, no account identifier, and no field linking two events by the same visitor. The user agent is reduced at the edge to one of four device classes and a short browser class, and the IP address to a two-letter country code, before anything is written. Analytics beacons are authenticated by a keyed hash of the page and a time window, which is deliberately identical for every visitor of that page. Routing and split tests add only the number of the rule or variant applied, and quizzes only which result was reached. Form submissions carry only the fields the Customer configured and the consent record; no IP address, user agent, cookie or device identifier is stored with them, and the per-visitor rate limit uses a keyed, daily-changing hash that is removed after two days. Nothing that is not needed for the stated purpose is stored. |
| Encryption | TLS 1.2 or higher on all connections, with HSTS (max-age one year, includeSubDomains, preload). Data at rest is encrypted by the database and object-storage providers (AES-256). Account passwords are stored only as bcrypt hashes by the authentication provider; operator console passwords only as PBKDF2-SHA-256 with 210,000 iterations and a per-row salt; API keys only as SHA-256 hashes, shown to the Customer once. Every webhook message is signed with HMAC-SHA-256 under a per-endpoint secret, so the recipient can verify that it came from us and was not altered. Secrets live in the hosting provider's encrypted environment store, never in source control. |
| Access control — people | Production access is limited to the proprietor and to persons expressly authorised in writing, each under a confidentiality obligation. Multi-factor authentication is required on every provider console that offers it (hosting, database, payments). Access rights are reviewed when a role changes and withdrawn on the day an engagement ends. |
| Access control — system | Every database table has row-level security enabled with no public policies, so no browser can reach the database directly; all access runs through server-side edge functions holding the service-role key. Customer sessions are signed JWTs verified server-side on every request; where the customer has enabled TOTP, every API call below aal2 is refused, not merely the login form. The operator console uses an HttpOnly, Secure, SameSite cookie carrying an HMAC-SHA-256 session token with a server-side expiry, and its login is rate-limited to 10 attempts per 15 minutes per IP address. Team access is re-read from the database on every request, so removing somebody takes effect immediately rather than when their token expires. Form submissions can be read, exported and deleted only by the account owner and team members whose role allows editing links. API keys carry explicit scopes, are limited to 120 requests per minute each, are checked against the plan on every request, and can be created and revoked only by the account owner; revocation takes effect on the next request. |
| Separation | Every multi-tenant query is scoped by tenant_id, including analytics, which is scoped by an explicit slug list because event rows are keyed by slug. Creation and update paths are separated so that no write can move a record between accounts. The account a form submission belongs to is derived from the link that received it, never from the request, and is checked a second time inside the database before the entry is written; an API key acts only within the account that created it. Development and production run as separate projects with separate credentials; production data is never copied into development. |
| Input and transmission integrity | Slugs are validated against a strict pattern; injection and path-traversal attempts are rejected at the edge, with the screening bounded so that it cannot be used to burn CPU. The click beacon is origin-checked, token-checked, slug-validated, capped at 2 KB and sanitised before storage, with a per-IP and per-link ceiling on top of the general limit. Values that will be navigated to pass a scheme deny-list; values embedded in HTML, in attributes and in inline scripts each pass the escape appropriate to that context. Uploads are limited by type and size per bucket. Form submissions are accepted only as same-origin requests carrying the page's token, are capped at 16 KB per request with fixed limits per field, are checked against the form as stored on the link rather than against anything the request claims, and are stripped of markup and control characters before storage; values are escaped again wherever they are displayed and neutralised against spreadsheet formulas in the CSV export. Automated submissions are filtered by a honeypot field and a minimum filling time, and limited per connection, per page, per link and per account. Webhooks are sent only to HTTPS addresses on port 443; addresses written as a private, loopback, link-local or otherwise reserved IP address, and internal host names, are refused; the check is repeated before every delivery, each attempt times out after five seconds, and redirects are not followed. Embedded players are created only for the YouTube privacy-enhanced domain and Spotify's embed address, and only after the visitor's click; a page carrying one allows frames from exactly those two origins. A Content Security Policy enumerates every permitted script and connection host, and is set both at the edge and on statically served paths; X-Frame-Options: DENY, X-Content-Type-Options: nosniff, a restrictive Permissions-Policy and Referrer-Policy: strict-origin-when-cross-origin are set globally. |
| Availability and resilience | Serverless deployment across a global CDN with automatic failover between points of presence (Netlify). Managed Postgres (Supabase); see Restoration below for what is backed up, by whom, and against which failure. Rate limiting of 60 requests per IP per minute. Analytics writes are fire-and-forget, so a logging failure can never break page delivery. Static assets are immutable and cacheable, so cached pages keep serving through a database incident. |
| Restoration | Two independent layers, because they fail differently. (1) Ours: a scheduled job takes a daily logical export of every table except the analytics events, the form submissions and the webhook delivery records — accounts, team logins, link configuration, subscriptions, invoice records, API keys (as hashes) and webhook endpoint settings — into a private, service-role-only bucket, retained 35 days and rotated automatically. Form submissions are excluded so that an entry the Customer deletes, or whose period ends, is gone from our export at once rather than surviving in it for another 35 days. It covers the common failures: a bad migration, a mistaken deletion, a write that corrupted rows. It is held in the same project as the live data, so it does not cover loss of that project. (2) The provider's: Supabase's own backups of the database cluster cover infrastructure failure, under its documented restore procedure and the retention of our plan. Restoration is exercised when the schema changes materially. Infrastructure and application code are in version control and can be redeployed from source. The analytics events are deliberately excluded from (1): they are deleted after 90 days in any case, so backing them up daily would mean storing what we have promised to destroy. |
| Testing and evaluation | An automated suite runs the real edge handlers against a stubbed database before each release, covering routing, cacheability, access gates, tenant scoping, escaping, the API authentication paths and the whole role matrix for both employee systems. It also asserts published commitments — that no third-party script is loaded, that the consent gate ships inert, that the retention period in these documents matches the deletion job. Production is re-checked after each deployment. The application runtime has no third-party runtime dependencies, which is the cheapest supply-chain control available. |
| Purpose limitation and instruction control | Processing happens only through the documented application paths, which implement the instructions in section 3.2. There is no ad-hoc export path, no analytics vendor and no support tool with access to Customer Personal Data. The operator's own console is scoped to the operator's own organisation, so browsing a customer's links, destinations or statistics is not something the software permits. Staff, where engaged, get written instructions and a confidentiality undertaking. |
| Subprocessor governance | Each subprocessor is engaged on Article 28-compliant terms with flow-down of these obligations, including the prohibition on AI training. The list is published and versioned, with 30 days' notice of change and a right of objection. |
| Deletion | Raw events are deleted by a scheduled daily job after 90 days, together with rows whose link no longer exists; the period is held in one place in the code and the test suite fails if these documents stop naming the same number. Form submissions carry their deletion date from the moment they are written and are deleted by a daily job when it is reached; the same job removes the rate-limit hash after two days, and fails closed — if its database function is missing it deletes nothing and reports the fault. Webhook delivery records are deleted after 30 days. Account data is deleted from production within 30 days of termination and expires from backups within a further 90 days. Data under statutory retention is blocked from every other use. |
| Incident response | Documented procedure: detect, contain, assess within 24 hours, notify affected controllers within 48 hours, notify the supervisory authority within 72 hours where required, remediate, record. A responsible-disclosure channel is published at plugwith.me/security, with a target of 30 days to fix a critical or high-severity issue. |
| Governance | Record of processing under Article 30(2). Data protection assessed at design time for each feature, with the reasoning kept in the repository next to the code it constrains. Published commitments are asserted by tests rather than remembered, so a document and the software cannot drift apart silently. |
Annex III — Subprocessors
Authorised subprocessors as at 21 October 2026. The current version, with change history and a notification subscription, is at plugwith.me/subprocessors and is authoritative. A row marked with a date takes effect on that date and not before — the notice period in section 11.2 runs first.
| Subprocessor | Processing carried out | Location of processing | Transfer safeguard |
|---|---|---|---|
| Netlify, Inc. 512 2nd Street, San Francisco, CA 94107, USA |
Hosting, global CDN, execution of the edge functions that serve link pages, receive click events and form submissions, answer API and MCP requests, and of the scheduled jobs that delete expired data and deliver webhooks; rate limiting, access logs, derivation of the country code from the IP address | Global edge network; EU points of presence (including Frankfurt and Amsterdam) serve EU visitors. Company established in the USA. | EU–US Data Privacy Framework; EU SCCs Module Three; UK Addendum |
| Supabase Pte. Ltd. 65 Chulia Street #38-02/03, OCBC Centre, Singapore 049513 — part of the Supabase group with Supabase, Inc., Delaware, USA |
Managed Postgres storing accounts, team logins, link configuration, click events, form submissions, API keys and webhook settings and delivery records; authentication and session issuance; object storage for uploaded images, background media and invoice PDFs; delivery of authentication emails | European Union — AWS eu-central-1 (Frankfurt, Germany), since 21 October 2026; previously the United States (us-east-2, Ohio). Support and operations access possible from outside the EU, including the USA and Singapore. |
Storage in the EU. For access from outside the EU: EU SCCs Module Three; UK Addendum; Swiss annex. The Data Privacy Framework is not relied on — the Clauses are the sole instrument. See 14.5. |
| Resend, Inc. 2261 Market Street #5039, San Francisco, CA 94114, USA From 30 September 2026 — announced 30 August 2026 under section 11.2 |
Delivery of the single confirmation email sent to an account holder after their account has been erased on request. No Customer Personal Data passes through it. Resend also delivers emails for which we are controller in our own right — our newsletter and the confirmations of cancellations and withdrawals — which are outside this DPA (section 11.6) and listed at plugwith.me/subprocessors. | USA | EU SCCs Module Three; Resend DPA |
| Stripe Payments Europe, Ltd. 1 Grand Canal Street Lower, Dublin 2, Ireland — with Stripe, Inc., USA |
Payment processing, subscription management, invoicing and tax determination. Relates to Customer account data, never to visitor data. Stripe acts as an independent controller for payment data. | Ireland and the USA | EU–US Data Privacy Framework; EU SCCs; Stripe DPA |
Not subprocessors. Meta, Google, TikTok and Snap are not our subprocessors. Where you enable one of their pixels, their scripts run in the visitor's browser and send data to them directly; nothing passes through our systems and we have no contract with them for it. The same holds for Google (YouTube) and Spotify when a visitor clicks to load a player you embedded. See section 2.3. Nor are the recipients you connect through the API, webhooks or MCP (section 2.7).
No other content delivery network is involved. The Supabase browser client used by the customer area is served from our own domain at a pinned version with a recorded checksum; the esm.sh dependency disclosed in earlier versions of this DPA was removed in July 2026. No third-party script is loaded into any page of this service; an embedded player you add runs in a separate frame from its provider, and only after the visitor has clicked it.
No AI or machine-learning vendor is engaged, and none receives Customer Personal Data. See section 6.
Annex IV — Country-specific terms
plugwith.me is sold worldwide. These terms apply in addition, and only where the law named applies to your use of the Service. Where they conflict with the main body, they prevail for that law only.
IV.1 United States — California and comparable state laws
Where the California Consumer Privacy Act as amended by the CPRA, or a comparable state law (including Virginia, Colorado, Connecticut, Utah, Texas, Oregon, Montana, Delaware and their successors), applies, we act as your service provider or processor as those laws define the term. We:
- process personal information only for the business purposes in this DPA and your instructions;
- do not sell it and do not share it for cross-context behavioural advertising, as those terms are defined;
- do not retain, use or disclose it outside the direct business relationship or for any purpose other than performing the Service, including not for our own commercial purposes;
- do not combine it with personal information from another source, except as those laws permit;
- comply with the applicable obligations and notify you if we determine we can no longer do so;
- flow the same restrictions down to every subprocessor.
You may take reasonable and appropriate steps to stop and remediate unauthorised use. This section is the contract required by § 1798.100(d) and § 1798.140(ag) CCPA. Deidentified or aggregated information under section 5 is outside these restrictions; we will not attempt to reidentify it and will contractually forbid recipients from doing so.
IV.2 United Kingdom
References to the GDPR are read as references to the UK GDPR and the Data Protection Act 2018. The transfer mechanism is in section 14.3. The competent authority is the Information Commissioner's Office.
IV.3 Switzerland
References to the GDPR are read as references to the revised Federal Act on Data Protection. "Personal data" includes data about legal entities where the FADP so provides. The competent authority is the Federal Data Protection and Information Commissioner. The transfer mechanism is in section 14.4.
IV.4 Brazil
Where the Lei Geral de Proteção de Dados (Law 13,709/2018) applies, you are the controlador and we are the operador. We process personal data only on your instructions, keep it secure, help you answer requests from titulares, and report security incidents to you without undue delay so that you can notify the ANPD and affected individuals. International transfers rest on standard contractual clauses of equivalent effect to those in section 14.
IV.5 Canada
Where PIPEDA or a substantially similar provincial law applies, we act as a service provider processing personal information on your behalf, use contractual and technical means to give it a comparable level of protection, and will tell you of any breach of security safeguards involving it without undue delay. You remain accountable for the information you transfer to us.
IV.6 Australia
Where the Privacy Act 1988 and the Australian Privacy Principles apply, we handle personal information only for the purposes you instruct, and will notify you of any eligible data breach involving it in time for you to meet your own obligations under the Notifiable Data Breaches scheme.
IV.7 Everywhere else
Where a data protection law applies that is not named here, the parties will negotiate in good faith any additional term that law requires. Until then, the standard in the main body of this DPA applies, because it is drafted to the GDPR — in practice the strictest of them.
Change history
| Date | Change |
|---|---|
| 20 November 2026 published 21 October 2026 | Version 3.3. Storage in the EU: since 21 October 2026 the data is stored in Frankfurt (eu-central-1) instead of the United States; sections 14.1, 14.5 and Annex III say so, and say plainly what remains outside the EU — remote access by provider staff, covered by the Clauses, and the reach of US law over a provider with US group companies. Supabase's contracting entity is named as it now appears in Supabase's terms. Section 14.7 now distinguishes moves out of the EEA (30 days' notice and a right to object) from moves into or within it. Forms: a fourth processing stream, form submissions, added to sections 1.2 and 2.1 and described in Annex I B.4, with its measures in Annex II and its deletion in section 15; new section 7.9 sets out what you warrant when you place a form on a page; form entries are excluded from our anonymous statistics (5.1). Quizzes, routing and split tests: recorded as part of the click events, without answers and without any new identifier (Annex I B.1). Embedded players added to section 2.3 next to marketing pixels. API, webhooks and MCP: section 2.7 on data you send onwards, section 6.5 on AI assistants you connect, Module Four added to section 14.2, keys and webhooks in sections 3.2 and 9.4 and in Annex II. Annex II Restoration names the tables left out of our own export. Annex III: the Resend row no longer says that no other message passes through it, which stopped being true with our newsletter; it now says that no Customer Personal Data does. The storage move, the exclusion from statistics and the descriptions in sections 3.2 and 6.5 apply to every account from 21 October 2026 because they are purely to the Customer's advantage (Terms § 2.3); the rest binds existing accounts from 20 November 2026 or their earlier acceptance. The level of protection was not reduced. |
| 21 September 2026 published 21 August 2026 | Version 3.2. Annex II — Restoration rewritten. The previous wording named "automated daily backups by the provider", which is true only on some plans and was therefore a claim nobody could check. There is now a daily logical export of our own, described with what it does and does not cover, and the provider's backups are named separately as the layer that covers infrastructure loss. The level of protection was not reduced; the description was made accurate. |
| 21 September 2026 published 21 August 2026 | Version 3.1. Link password protection was discontinued. It was a shared secret a visitor could pass on, so it protected nothing, while storing it made us hold a password on the Customer's behalf and obliged this agreement to warn about reuse. Removing the feature removed the warning. The clause that described it, and the mention of link passwords in Annex I.B.3, are gone. |
| 21 September 2026 published 21 August 2026 | Version 3.0. Team logins and uploaded media added to Annex I as processing streams of their own — the previous version described only click events, so two categories of data subject were undocumented. New controller warranties and indemnity (section 7), an explicit permission for anonymous aggregate statistics with published minimum group sizes (section 5), an AI Act and Article 22 statement (section 6), a records / DPO / representative section (17), a country annex for the US, UK, Switzerland, Brazil, Canada and Australia (Annex IV), and a change history. The retention period is now enforced by a daily deletion job instead of being stated only. Annex II corrected: upload limits per bucket, backup wording, and a precise description of the access controls that actually exist. |
| 4 August 2026 | Version 2.2. Provider address updated; competent supervisory authority and place of jurisdiction aligned with the place of establishment. |
| 31 July 2026 | Version 2.1. Hosting region corrected to the United States (us-east-2, Ohio); the transfer rests on the Standard Contractual Clauses because Supabase is not DPF-certified. |
| 31 July 2026 | Version 2.0. Full agreement published in place of the earlier summary, with the SCCs, the UK Addendum and the annexes. |
| 29 May 2026 | Version 1.0. First DPA summary published. |