API data minimization means returning only the data needed for an approved consumer task. Start with the decision the application must support, justify each response field, and enforce that approved field set on the server. A smaller JSON payload is useful, but the real goal is to avoid exposing information the consumer has no reason or permission to receive.
For example, a regional operations application may need an account identifier, service status, routing region and last update time. It does not automatically need the contact email, invoice address or tax identifier stored beside those values. The application’s task should drive the response contract; the shape of the database row should not.
The example records, field decisions and acceptance criteria below are synthetic architecture guidance. They are not customer data, Elementrix configuration screens or observed test results. The worksheet is intended for a joint review by the business owner, API team and security reviewer.
Start with the consumer’s task
Write the task in one sentence: “The regional operations application routes an active account to the correct service queue and shows how current the status is.” This defines a narrower need than “the application needs customer data.” Record the consuming application, accountable owner and approved purpose beside the task. If the application acts for a person, retain the person’s relevant permissions and record boundaries too.
Define the operation before choosing fields. Reading routing status is different from updating a billing account or exporting a customer profile. Specify which records the consumer may access, then decide which properties it can receive from those records. A field allowlist does not authorize an otherwise forbidden account.
Our application-level versus user-level data access guide explains that identity distinction. The broader data access control guide provides context for the authorization decision. Verify the consumer’s record and operation permissions independently of the response-field design.
Classify necessary, optional and excluded fields
Use a field-purpose matrix before implementing the response. “Necessary” means that removing the field prevents the approved task or an explicit acceptance criterion. “Optional” means a documented convenience with a separate justification. “Excluded” means there is no approved need in this contract. Optional fields still need authorization; the label does not make them safe to return by default.
| Field | Decision | Purpose or reason | Response rule |
|---|---|---|---|
| account_id | Necessary | Identify the account being routed. | Return only for an account the caller may access. |
| account_status | Necessary | Decide whether the account can enter the active service queue. | Return the approved status value and document its meaning. |
| service_region | Necessary | Select the service queue. | Return the routing region, rather than an exact address. |
| last_updated_at | Necessary | Show the age of the status used for routing. | Define which event this timestamp represents. |
| account_label | Optional | Help an operator distinguish similar accounts on a screen. | Omit from the base contract; require an approved display need. |
| contact.email | Excluded | This application does not contact the customer. | Do not serialize the property or its parent object. |
| billing_address | Excluded | Routing uses service_region; invoicing is outside the task. | Do not return the address object. |
| tax_id | Excluded | The task does not perform tax or identity verification. | Do not return or log the identifier. |
| internal_risk_score | Excluded | Internal assessment is outside the approved routing decision. | Do not expose the value or a proxy for it. |
Record the reviewer, approval date and next review trigger with this matrix. A new consumer purpose, a schema change or a different record population should reopen the decision. A field once approved for one application should not silently become part of every consumer’s response.
Design the response from the approved field set
Before: a broad profile response
This fictional response illustrates a design to reject for the routing task. The nested contact, billing address, tax identifier and internal assessment add exposure without completing that task. The values below are deliberately synthetic, including the example.com email address and the placeholder tax identifier.
{
"account_id": "A-042",
"account_status": "active",
"service_region": "REGION-A",
"last_updated_at": "2026-10-15T05:45:00Z",
"account_label": "Example service account",
"contact": {
"name": "Example Contact",
"email": "contact@example.com"
},
"billing_address": {
"line_1": "14 Example Street",
"city": "Example City"
},
"tax_id": "SYNTHETIC-TAX-ID",
"internal_risk_score": 62
}After: the routing response
A purpose-specific response contains the four necessary fields. For this example, last_updated_at means the time the published account status was refreshed. It is not the time this HTTP request was received. Document that meaning so the application does not mistake a recently generated response for recently refreshed source data.
{
"account_id": "A-042",
"account_status": "active",
"service_region": "REGION-A",
"last_updated_at": "2026-10-15T05:45:00Z"
}Build a response object from explicitly approved properties after checking the caller, operation and record. Avoid serializing the complete source object and relying on the browser or mobile app to hide unwanted fields. The client has already received a property even if the screen does not display it.
OWASP’s API3: Broken Object Property Level Authorization addresses unauthorized property exposure and modification. Its guidance supports checking property access, explicitly selecting returned properties and validating the response schema. Use those controls at the delivery boundary rather than treating a frontend filter as authorization.
A requested field set is not an approved field set
If an API supports a fields parameter, treat it as a consumer preference within the approved contract. A caller asking for tax_id does not gain permission to receive it. For a restricted representation, a useful design is to return the intersection of requested fields, purpose-approved fields and caller-authorized fields, subject to the endpoint’s documented mandatory fields and error behavior.
Choose how unsupported or forbidden selections behave and document it. Rejecting an invalid selection can make mistakes visible; silently omitting fields may suit some contracts. Either way, test that a manipulated query cannot expand the authorized representation, and keep cache entries separated when caller permissions change the response.
Keep omission, masking and row filtering separate
| Control | What changes | Example | Limit |
|---|---|---|---|
| Property omission | Which fields are sent. | Do not include contact.email in the routing response. | A forbidden property must also be absent from alternate response paths. |
| Masking | How a returned value is represented. | Return a partially obscured contact value when that display has an approved purpose. | Some information is still disclosed; masking does not justify unnecessary fields. |
| Row filtering | Which records are available. | Allow only accounts within the caller’s approved region. | An allowed record may still contain fields the caller cannot read. |
A masked email still conveys information. A region-limited record can still expose an unnecessary tax identifier. Use record controls and field controls together where the task requires both. Field selection alone does not establish legal compliance, prove anonymization or prevent every inference from the fields that remain.
Account for logs, nested objects and derived fields
Expand objects before approving them
An entry such as “contact object approved” can hide several independent disclosures. Expand the object into its leaf properties: name, email, telephone and preferences may support different purposes. Apply the same review to arrays, embedded resources, expandable relationships and error details. A new property added to a shared object should not automatically appear in a restricted response.
Review what derived values reveal
A derived flag or segment can reveal information about an excluded source attribute. For example, replacing an internal score with a risk-band label does not make the underlying assessment irrelevant to the disclosure review. Ask what the consumer can infer, what granularity the task needs and whether the derived field has its own approved use.
Follow the data beyond the successful response
Check request and response logging, traces, debugging snapshots, exports, caches, retry queues and support tooling. A clean response contract does not help if middleware records the broad object first. Use an allowlist for diagnostic properties where practical, protect required audit records and set a retention policy appropriate to their purpose.
The OWASP Logging Cheat Sheet identifies sensitive information that should generally be excluded, removed or otherwise protected in logs. For this design, useful evidence can include the application identity, operation, decision and response-schema version without copying the full customer payload. Determine whether any identifier in that evidence is itself sensitive.
Validate the result with positive and negative tests
The following checks are proposed acceptance criteria, not completed test results. Use them against the real implementation with synthetic fixtures. Verify both the intended response and the paths that could expose the broader object. Day-to-day operation needs monitoring and change review in addition to a one-time test.
| Check | Input or condition | Expected result |
|---|---|---|
| Approved operation | Authorized consumer requests an allowed account. | The four approved fields appear with their documented meanings. |
| Field escalation | Caller requests tax_id or a nested contact expansion. | The restricted data is not returned; documented rejection or omission applies. |
| Record boundary | Caller requests an account outside its allowed region. | The record is not disclosed, even though the requested fields are permitted elsewhere. |
| Schema growth | A new source property is added to the account object. | The restricted response remains unchanged until its contract is reviewed. |
| Alternate path | Use a list, export, error response or cached representation. | The same applicable data boundaries remain effective. |
| Diagnostic capture | Inspect authorized test logs and traces for the operation. | Excluded payload fields are absent from diagnostics that do not require them. |
| Cross-consumer cache | A broader consumer request precedes a restricted consumer request. | A cached representation does not transfer the broader field set. |
Add a contract check that compares the actual response keys, including nested keys, with the approved schema. Do not settle for finding the four expected fields while ignoring unexpected extras. Test write authorization separately: limiting a read response does not prevent a caller from submitting forbidden properties to an update endpoint.
Use the matrix to make the next API review concrete
Bring one response, one consumer task and the field-purpose matrix to the review. Confirm record boundaries, agree which attributes belong in the base contract, and identify every alternate path that can reveal the same information. Keep the rationale with the contract so the next schema change can be evaluated against the original purpose.
For the control model behind that decision, read our field-level security guide. This article focuses on choosing a minimal representation; the hub explains the wider field-control context.
Request an Elementrix field-level access demo and bring an overexposed response with synthetic or redacted values. Use the matrix to discuss the consuming application’s purpose, approved fields and delivery boundary, then confirm which enforcement and lifecycle behaviors the current implementation supports.