GDPR API Compliance: Endpoints, Access Control, and What GDPR Requires
An API is rarely the thing a GDPR audit starts with, and that is precisely the problem. Endpoints get built to solve an engineering task, personal data flows through them because that is what the application needs, and nobody circles back to ask whether the response payload, the access controls, or the logging around that endpoint would survive a data protection review. Most API-related GDPR exposure comes from exactly that gap.
Key Takeaways
• Article 25 GDPR requires data protection by design and by default, which means an API should return only the personal data a specific request actually needs, not everything the underlying database happens to contain.
• Broken Object Level Authorisation, where an API fails to check whether the requesting user is entitled to the specific record they are asking for, is OWASP’s top-ranked API security risk and a direct route to a GDPR-reportable breach.
• When a third party consumes your API, or your system consumes another organisation’s API, that data flow is a processing relationship that usually needs a Data Processing Agreement under Article 28.
• Logging API requests is good security practice, but the logs themselves contain personal data and are subject to the same retention and access-control obligations as the data they describe.
Does GDPR Apply Directly to APIs?
GDPR does not mention APIs specifically, but any API that transmits, stores, or processes personal data falls squarely within its scope. The regulation is technology-neutral: it governs what happens to personal data, not the specific mechanism moving it. An API returning customer names, email addresses, or behavioural data is processing personal data in the same legal sense as a form submission or a database query.
What Does Data Minimisation Mean for API Design?
Article 25(2) GDPR requires that, by default, only personal data necessary for each specific processing purpose is processed. Applied to an API, this means an endpoint should return the fields a given request actually requires, not the full underlying record because it was easier to serialise the whole object.
A common failure pattern is an endpoint built for one purpose, such as displaying a user’s name on a dashboard, that returns the user’s full profile including fields like date of birth, address, or internal notes because that is what the database model contains. Every field returned beyond what the calling application needs is unnecessary processing and unnecessary exposure if that response is intercepted, logged insecurely, or cached somewhere it should not be.
What Access Control Failures Cause the Most GDPR Risk in APIs?
Broken Object Level Authorisation, commonly abbreviated BOLA, is OWASP’s top-ranked API security risk for a reason: it is common, easy to introduce accidentally, and directly exposes personal data belonging to people other than the requesting user. It happens when an API endpoint accepts an object identifier, such as a user ID or record number, and returns the corresponding data without verifying that the requesting user is actually authorised to access that specific object.
A practical example: an endpoint at /api/users/{id}/profile that returns whichever profile matches the ID in the URL, regardless of whether the authenticated user making the request owns that ID, allows anyone to enumerate other users’ personal data simply by changing the number. This single design flaw has been behind a large share of publicly disclosed data exposure incidents across industries, precisely because it is invisible in normal use and only surfaces when someone deliberately probes the endpoint.
Does Sharing Data Through an API Require a Data Processing Agreement?
Usually, yes. If your API sends personal data to a third-party system, or your application consumes personal data from another organisation’s API, that exchange is a processing relationship under GDPR. Where the relationship is between a controller and a processor, meaning one party is processing data on the other’s behalf, Article 28 requires a written contract covering the processor’s obligations, security measures, and what happens to the data when the relationship ends.
This applies whether the data moves through a polished partner API with documentation and rate limits, or through an informal internal integration that nobody has classified as a “vendor relationship” at all. The technical sophistication of the API has no bearing on whether the underlying legal requirement applies.
Does Scraping Data Through an API Without Consent Violate GDPR?
Yes, and enforcement in this area has been significant. Facial recognition company Clearview AI was fined €30.5 million by the Dutch data protection authority in 2024 after building a database of more than 30 billion facial images, largely by automatically scraping publicly accessible photos and converting them into biometric identifiers, without the knowledge or consent of the people in those photos. The regulator found this processing unlawful, even though the underlying photos were publicly visible online.
The case is a reminder that lawful basis requirements apply to data an API or scraper collects from external sources just as much as to data your own users submit directly. Publicly accessible does not mean freely processable, particularly for biometric data, which sits under Article 9’s stricter special category rules.
What Should API Logging Include, and What Should It Avoid?
Logging API requests supports security monitoring and incident investigation. Still, the logs themselves become a store of personal data once they capture things like user identifiers, IP addresses, or request payloads containing personal fields. That means API logs are subject to the same retention limits, access controls, and security requirements as the primary data the API handles.
A practical approach is logging enough to investigate an incident, such as timestamps, endpoint paths, and user or request identifiers, while avoiding logging full request or response bodies where those bodies contain personal data that has no investigative value sitting in a log file indefinitely. Where full payload logging is genuinely needed for debugging, it needs its own retention schedule and access restrictions, not an assumption that logs are somehow exempt from GDPR because they exist for operational reasons.
How Do You Build a GDPR-Compliant API From the Start?
Practical measures that consistently come up across security and privacy guidance for APIs include returning only the fields a specific endpoint’s purpose requires rather than full database objects, implementing object-level authorisation checks on every endpoint that accepts a resource identifier, using standard authentication protocols such as OAuth 2.0 rather than custom authentication logic, encrypting data in transit and at rest, and rate limiting endpoints that expose personal data to reduce the impact of any single compromised credential or scraping attempt.
Building this in from the design stage, in line with Article 25’s privacy by design requirement, is considerably cheaper than retrofitting access controls onto an API that has already shipped and is already being consumed by other systems that assume its current behaviour. Our Article 32 breakdown covers the security-of-processing standard these measures are ultimately assessed against.
Conclusion
APIs move personal data at a speed and volume that makes design-stage mistakes expensive later. Data minimisation, object-level access control, and treating third-party data exchange as the processing relationship it legally is are not separate concerns from the rest of GDPR compliance; they are the same obligations applied to a different transport layer. The organisations that get this right treat API design review as part of the privacy by design process, not a step that happens after the endpoint is already live.
Frequently Asked Questions
Does an internal API, only used by our own systems, still need to be GDPR compliant?
Yes. GDPR applies to processing personal data regardless of whether the API is public, partner-facing, or purely internal. An internal API that returns more personal data than a given internal service needs still creates unnecessary exposure and still needs to follow data minimisation and access control principles.
Is API key authentication enough to satisfy GDPR’s security requirements?
Not on its own. A shared API key authenticates that a request comes from an authorised system, but it usually does not distinguish between individual users or enforce object-level authorisation. Article 32’s security requirements generally expect authentication and access control appropriate to the sensitivity of the data involved, which for personal data typically means more than a single static key shared across all consumers.
If we use a third-party API to enrich our own customer data, who is the controller?
It depends on the arrangement, but in most enrichment scenarios, your organisation remains the controller for the resulting combined dataset. At the same time, the third-party API provider acts as a processor for the data it supplies, or as a separate controller if it determines its own purposes for that data. This needs to be assessed and documented per relationship rather than assumed.
Disclaimer: This blog post is intended solely for informational purposes. It does not offer legal advice or opinions. This article is not a guide for resolving legal issues or managing litigation on your own. It should not be considered a replacement for professional legal counsel and does not provide legal advice for any specific situation or employer.
About the Author
Zlatko Delev
Country Manager & Head of Commercial — GDPRLocal
Zlatko specialises in data protection compliance, ISMS strategy, and AI law. With a legal background and hands-on experience supporting organisations globally, he helps businesses navigate GDPR, the EU AI Act, and international privacy frameworks.