Data minimization in an API means each endpoint accepts and returns only the personal data its purpose needs, by default. Shape responses per client role, avoid returning whole database objects, and keep personal data out of URLs and logs. GDPR Article 5(1)(c) calls for data that is adequate, relevant and limited to what is necessary.
Why APIs leak by default
Frameworks make it easy to serialise a model straight to JSON. A user endpoint written for the profile page then returns email, phone, date of birth and internal flags to every caller, including a widget that only needed a display name. Over time, clients depend on those extra fields, so removing them breaks things.
Article 25(2) asks for data protection by default: only data necessary for each purpose, covering the amount collected, extent of processing, storage period and accessibility.
The checklist
Requests
- Does each input field have a stated purpose? Drop optional fields nobody uses.
- Do forms collect a full date of birth when an age check would do?
- Is free text allowed where a pick list would be safer?
Responses
- Use explicit response schemas, not model dumps. Add fields deliberately.
- Return different shapes for different roles. A list view should carry less than a detail view.
- Mask where full values are rarely needed, such as the last digits of a phone number.
- Return internal IDs, not emails, when linking resources.
- Exclude flags and notes that are internal to your staff.
Queries
- Support field selection only through an allowlist, so callers cannot request any column.
- Cap page sizes and rate limit, so a loop cannot export your user base.
- Avoid search endpoints that confirm whether a person exists.
Transport and storage
- Keep personal data out of URLs and query strings, since they land in logs, proxies and browser history.
- Strip personal data from error messages.
- Log request IDs and user IDs, not payloads.
Lifecycle
- Document which fields are personal data and who may read them.
- Set a retention period for stored responses, caches and webhooks.
Webhooks and events
Outbound webhooks are APIs too. Send an ID and a type, and let the receiver fetch details with authorisation, rather than pushing the full user object to every subscriber.
Test for excess data
Add contract tests that compare actual responses with the documented schema and fail on extra fields. Review the schema in code review, with a privacy question: why does this client need this field?
Try it yourself
Click through it at your own pace, or open it full screen. Look at which findings relate to exposed data and think about whether each response field earns its place.
Quick check
Is returning extra fields a security issue or a privacy issue?
Both. Extra fields widen what an attacker or a curious client can read, and they exceed what the purpose needs.
Should I remove a field clients already use?
Version the API, announce a deprecation date and measure usage before removal.
Sources
Last reviewed: 19 October 2026.
