Yes, that would fit my needs.

@lucas-subli Doing this is actually hard because the types differ according to the mode (put vs update).

For instance, if startTime is required but not always, it should be present in the put mode input item, but optional or extended (e.g. $get('anotherAttribute')) in the update mode. On the other hand, the resulting ttl should be required in the put mode but not in the update mode.

I think using the update mode for the input item (which is wider than the put mode) and the put mode for the output (which is stricter than the update mode) would make it work in all scenarios, but still it may be a bit confusing and not necessarily what you expect (you may not want to return a ttl if startTime has not been updated).

WDYT?

If we are using the .link method with a qualifier, I would think that if the default qualifier is put and a putAndUpdate is allowed, there is no need to worry too much about confusion, as if anyone is using a more advanced option they are most likely going through the docs. And if there are three options put, update and putAndUpdate the latter clearly seems more nuanced.

As for the typing, I think your assessment is on point, using the wider option on the input and the stricter on the output (if it works in all cases). Even if it is a bit confusing on the return.

If I don't want to return a TTL if startTime has not been updated, I could always go back to using two different .links, but since returning it or not has no impact on costs or performance, I would argue that having the option for cleaner code is still worth it.