GDPR Fines Keep Rising - What It Means for Your API Project
GDPR enforcement is no longer a background concern. According to figures compiled by law firm DLA Piper, firms across Europe were issued more than 330 fines in 2025, totalling over 1.2 billion euros. Data breach notifications reached 400 per day for the first time since the regulation came into force in 2018. Between January 2024 and January 2026, the daily notification rate rose to 443, a 22 per cent increase from 363.
TikTok received 2025's largest individual fine: 530 million euros, issued by Ireland's Data Protection Commission over the transfer of European user data to China-based personnel. Luxembourg's supervisory authority upheld a 2021 fine of 746 million euros against Amazon after it processed user data for advertising without proper consent. Both decisions were contested. Both were upheld.
Regulators are not softening. They have concluded, reasonably, that eight years after GDPR came into force there is no longer any excuse for non-compliance. If your organisation builds or maintains software that handles personal data, this matters to you directly. And if that software includes APIs and third-party integrations, the surface area for liability is larger than most teams realise.
Why APIs Are a Compliance Risk
GDPR applies to personal data regardless of how it travels. An API request that includes a name, email address, IP address, or any other identifier that can be used to single out an individual is carrying personal data. The mechanism of transport does not change the obligation.
Most modern applications move personal data constantly. A user logs in and their session data passes through an authentication service. A checkout flow sends order details, including a delivery address, to a fulfilment API. A support ticket is created and a name and email address are sent to a third-party helpdesk platform. In each case, personal data has left your system and entered someone else's.
Under GDPR, you are responsible for what happens to that data. Not just in your own systems, but in the systems of every processor you send it to. Article 28 requires that any third-party processor you engage provides sufficient guarantees of GDPR compliance, and that you have a Data Processing Agreement in place before any personal data is shared. That applies to every API vendor, SaaS platform, and cloud service your application integrates with.
The Third-Party Problem
This is where many teams are most exposed. It is straightforward to audit your own database and your own code. It is considerably harder to audit the data handling practices of every third-party service your application sends data to, particularly when that list grows over time without anyone keeping track of it.
The ISMS.online article that prompted this post quotes an expert observation that the growing adoption of AI is making this worse. Many AI systems are developed by third-party vendors and trained on large datasets. When organisations send personal data into these systems as inputs, they frequently cannot guarantee how that data is stored, used for model improvement, or protected. Regulators are increasingly aware of this, and GDPR enforcement around AI data handling is expected to intensify.
Even without AI in the picture, the third-party API problem is real. A webhook you set up to notify a CRM when a new user registers is sharing personal data with that CRM. If the CRM vendor has a data breach, or if you later discover they have been selling data to advertisers, your organisation may bear some responsibility for having sent the data there without adequate due diligence. You can read more about how webhooks work and the data they carry in our post on webhooks versus polling.
Data Minimisation Starts at the API Layer
One of the most effective things you can do to reduce your GDPR exposure is to reduce the amount of personal data your APIs send and receive in the first place. This principle, data minimisation, is one of the six lawfulness principles in Article 5, and it applies to every field in every request.
In practice, this means asking whether each field you are including in an API payload is genuinely necessary for the function being performed. If you are sending a full user record to a third-party service when only a user ID is needed, you are creating unnecessary risk. If your webhook payloads include email addresses that the receiving system never uses, those fields should not be there.
This kind of audit is unglamorous work, but it has a direct impact on your compliance posture. Personal data that is never sent to a third-party system cannot be exposed by a breach at that third party.
The 72-Hour Notification Clock
DLA Piper's research attributes the rise in breach notifications partly to regulators enforcing the 72-hour rule more actively. Under GDPR, when an organisation becomes aware of a data breach that is likely to result in a risk to individuals' rights and freedoms, it has 72 hours to notify the relevant supervisory authority.
For that clock to start, you have to become aware of the breach. For you to become aware of the breach, you need adequate monitoring and logging in place across your systems and integrations. This is where many organisations fall short. If personal data flows through multiple APIs and third-party services with no centralised logging, it is extremely difficult to detect an incident in time to meet the notification requirement.
Every API integration that handles personal data should have logging that records what data was sent, when, and to which endpoint. Not to the extent of logging the personal data itself in plaintext, but sufficient to reconstruct the flow in the event of an incident. Without this, you cannot demonstrate compliance, and you cannot respond within the required window.
Access Controls and Authentication
Weak access controls are consistently cited in GDPR investigations and enforcement actions. An API that allows any authenticated user to retrieve any record, or that uses a single shared API key for all integrations rather than scoped credentials, is an access control problem and a GDPR problem simultaneously.
Personal data should be accessible only to the systems and users that have a legitimate need for it. API keys and tokens should be scoped to the minimum necessary permissions. Integrations should authenticate with credentials that can be revoked independently if a vendor relationship ends or a credential is compromised. We cover authentication approaches in more detail in our post on understanding API authentication.
Deletion and the Right to Erasure
GDPR's right to erasure, commonly called the right to be forgotten, creates a specific technical challenge for systems that have distributed personal data across multiple integrations. When a user requests deletion of their data, that request must be fulfilled across every system where their data has been stored, including third-party systems you have sent it to.
If your application has been sending user data to five different third-party APIs for the past three years, and a user now requests erasure, you need to send deletion requests to all five. If you do not have a record of which systems hold which user's data, you cannot fulfil the request reliably. This is a significant operational problem for teams that have not planned for it from the beginning.
Building deletion into your integration design from the outset, rather than retrofitting it later, is strongly recommended. This means understanding which third-party systems you send personal data to, what their deletion APIs look like, and whether they offer the ability to delete individual user records on request.
What Regulators Are Looking For
According to the ISMS.online article, regulators are looking for organisations that can demonstrate a clear data privacy strategy: a documented explanation of why personal data is collected, whether it is actually necessary, and how it is stored and protected. They want to see deliberate, responsible data handling, not a checkbox exercise.
From an API development perspective, this means being able to answer: what personal data does your application handle, where does it go, who can access it, how long is it retained, and how can it be deleted on request. If those questions produce blank looks, that is where to start.
The converging regulatory landscape is also worth noting. The EU's Digital Services Act, Digital Markets Act, and AI Act all interact with GDPR obligations. Treating these as separate compliance exercises is increasingly impractical. A joined-up approach to data governance across your technology stack is both more efficient and more defensible to a regulator.
Practical Steps for Development Teams
A few concrete things worth doing if you are not already:
- Audit every third-party API your application sends personal data to and confirm that a Data Processing Agreement is in place with each vendor
- Review your API request payloads for data minimisation opportunities, removing fields that are not needed by the receiving system
- Ensure API credentials are scoped and can be revoked independently per integration
- Implement logging sufficient to reconstruct personal data flows in the event of an incident, without logging personal data in plaintext
- Map your deletion obligations across third-party integrations and confirm you can fulfil erasure requests end to end
- Check that your webhook implementations do not carry more personal data in their payloads than the receiving system requires
None of these are exotic requirements. They are the kind of hygiene that well-designed API integrations should have regardless of GDPR. The regulation provides a legal incentive to do the work properly, and the enforcement trend of 2025 makes clear that the incentive is real.
If you need help reviewing the data handling practices of your API integrations, or want to discuss how to build compliance into a new integration from the ground up, get in touch with us. This is work we do regularly, and it is easier to get right at the design stage than after the fact.