# Should JSON:API Include Support for Field-Level Expiry Metadata in Responses?

**URL:** <https://discuss.jsonapi.org/t/should-json-api-include-support-for-field-level-expiry-metadata-in-responses/3065>\
**Category:** Uncategorized\
**Created:** [July 18, 2025, 4:38am UTC](https://discuss.jsonapi.org/t/should-json-api-include-support-for-field-level-expiry-metadata-in-responses/3065 "2025-07-18T04:38:54Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![reyiyeb](https://avatars.discourse-cdn.com/v4/letter/r/8e8cbc/32.png) [@reyiyeb](https://discuss.jsonapi.org/u/reyiyeb)\
**Post date:** [July 18, 2025, 4:38am UTC](https://discuss.jsonapi.org/t/should-json-api-include-support-for-field-level-expiry-metadata-in-responses/3065/1 "2025-07-18T04:38:54Z")

</div>

Hello

I have been working with JSON:API for a caching-heavy application & wondered if there’s any standard / discussion around including field-level expiry metadata in JSON:API responses. 😇Right now, cache-control & ETags can manage whole-resource expiration but in many real-world APIs; certain attributes (like `price`, `stock`, or `location`) update more frequently than others. 🙂

Embedding expiry metadata at the attribute level could help clients make smarter refresh / polling decisions.

I am aware this might go beyond the core spec but curious if anyone has tackled this use case. For eg; imagine a product API where the `description` rarely changes; but the `price` changes every 60 seconds sending a `meta.expires_at` per attribute could reduce unnecessary data fetches. 🤔

I have not seen this discussed widely and wonder if it conflicts with the spec’s emphasis on simplicity & consistency. 😇 Checked [JSON:API — Extensions and Profiles](https://jsonapi.org/extensions/) for reference. Also checked [what is cloud computing](https://www.igmguru.com/blog/what-is-cloud-computing), where different data fields update at different times.

Is this something already explored through `meta` / `extension` usage in practice? Would this kind of fine-grained expiry violate the spirit of JSON:API, or could it be proposed as an optional extension? 🤔

I would love to hear your thoughts or see if others have solved this problem differently.

Thank you !! 🙂