# Template JSON payload identification **URL:** \ **Category:** App Development\ **Created:** [May 27, 2021, 8:31am UTC](https://forum.canton.network/t/template-json-payload-identification/2641 "2021-05-27T08:31:02Z")\ **Posts on this page:** 1\ **Showing post:** 7
**Author:** ![Stephen](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/stephen/32/102_2.png) [@Stephen](https://forum.canton.network/u/Stephen)\ **Post date:** [June 1, 2021, 5:09pm UTC](https://forum.canton.network/t/template-json-payload-identification/2641/7 "2021-06-01T17:09:02Z")
> [@stefanobaghino-da](#): > > Please note that Daml-LF (the Daml compiler output) is subject to evolution over time, so you might have to adapt your code as new Daml-LF versions are published to make sure to handle new features (which is why [we have a library](https://github.com/digital-asset/daml/tree/main/daml-lf/interface) we use internally – i.e. no compatibility guarantees – to read and interpret Daml-LF packages). This is a possible way to go but I must say it’s not something particularly trivial. From easier to more difficult, I would say: 1. Using the daml-lf interface library to load LF packages. While changes will happen, you are likely to get help from scalac for adapting to them. 2. Loading the LF packages with protobuf (preferred protobuf gens work) and basically writing your own version of the interface library based on that. Not trivial, but way better than… 3. Parsing daml code. Seriously not recommended. There’s a reason all our navigator and codegen stuff is based on interpreting LF packages rather than daml code directly. --- _[View the full topic](https://forum.canton.network/t/template-json-payload-identification/2641)._