Expose file size (sizeInBytes) in the Object Attachment field JSON payload

Product Ideas
1

What is the problem you are trying to solve?

In Liferay Objects, an Attachment field is returned in the Object Entry payload with the following structure:

“attachment”: {
“externalReferenceCode”: “123-456-ABC”,
“id”: 12345,
“link”: {
“href”: “/documents/…/file.pdf”,
“label”: “file.pdf”
},
“name”: “file.pdf”
}

The payload does not expose any file size information, even though the underlying document in the Document Library has this metadata available (the Headless Delivery API returns sizeInBytes for documents).

A common business requirement is to display the size of each attached file (e.g. in MB) in a custom UI, such as a Client Extension consuming the Object APIs. With the current payload, the only options are:

  1. Requesting attachment.link.href — this effectively counts as a download and triggers any Action Builder action configured with the “On After Attachment Download” trigger, even though the end user never intentionally downloaded the file. This produces false positives in download-tracking logic.
  2. Calling GET /o/headless-delivery/v1.0/documents/{documentId} for each attachment, using the id from the attachment payload — this avoids the download trigger, but requires one additional asynchronous request per attachment. For object entries with multiple attachments (or list views showing many entries), this results in an N+1 request pattern with noticeable overhead and performance concerns, just to display a file size.

What is your project about? (e. g. Intranet, Partner Portal, Enterprise Website, etc)

All

What is your proposed solution? (optional)

Include the document size directly in the Attachment field JSON representation, for example:

“attachment”: {
“externalReferenceCode”: “123-456-ABC”,
“id”: 12345,
“link”: {
“href”: “/documents/…/file.pdf”,
“label”: “file.pdf”
},
“name”: “file.pdf”,
“sizeInBytes”: 1048576
}

Optionally, other lightweight document metadata already exposed by Headless Delivery (such as encodingFormat / content type) could be included as well, keeping the attachment representation consistent with the document representation returned by /o/headless-delivery/v1.0/sites/{siteId}/documents.

Benefits:

  • Client Extensions and other API consumers can display file size information without triggering download-related Object Actions (“On After Attachment Download”).
  • No additional request per attachment — eliminates the N+1 pattern when rendering entries with multiple attachments.
  • Consistency between the Objects API attachment representation and the document metadata already exposed by the Headless Delivery API.
  • The data is already available server-side (DLFileEntry size), so the change is purely additive and backward compatible.
2 Likes