Granting on Subscription-managed Entitlements

[GAlexIHU]

I realize this is an old PR but I'm curious why this is not an intended use case for OpenMeter to support? It seems this is a very natural way to support subscriptions + overage.

I don't believe this can be accomplished by editing the subscription as the subscription is just a standard base and overage should be something extra that's variable-charged on top of that.

I also tried to do this with add-ons but it doesn't work because the add-ons renew on the same basis as the underlying subscription, but overages should be one-off additions to the entitlement and not renew.

It seems this is exactly what grants were designed for, but I can't figure out why grants cannot be applied to entitlements managed by subscriptions. With this restriction in place, it seems the only way to get the desired behavior is to basically reimplement subscriptions using raw entitlements and apply grants onto those.

Is there some other suggested way to manage this with OpenMeter? cc @GAlexIHU

Originally posted by @christopherhwood in #2481 (comment)

[GAlexIHU]

Hi @christopherhwood

First off, sorry for getting back to you this late...

The main reason we decided to drop that feature (as mentioned in the description) is that it would be confusing with the current implementation. As currently is, the subscription lifecycle creates new entitlement instances with each change, as we do a "remove + add" style diffing on the subscription contents (relevant code is here if you're interested, its a bit messy). Due to this, after each change there is potentially a new entitlement instance where the previous balance history is effectively reconstructed. Using this logic, migrating the manual grants over to the new instances and diffing correctly is problematic. A fairly simple change would be to allow manual granting, but the grants would be wiped on the next change (e.g. manual edit or scheduled change).

Now, don't take this next part as a public roadmap commitment, but we want to make some significant changes to how entitlements work, and they are relevant to this conversation.
The current form of entitlements essentially fulfill two fairly different use-cases: one would be access checks on given features (which we think what entitlements should be), the other is a workaround for managing credit-like use-cases (e.g. top-ups, overages, etc...). These two are closely tied (credit-like balances often control, among other things, feature access), but interacting with them is usually convenient through different APIs. TLDR: we think current entitlements are too complicated for the 90% use-case, and though it enables many credit scenarios, we can do better on that experience if we re-think it a bit.
As we want to change most of how entitlements will work internally, we're hesitant to make significant changes to how it works now (including for instance how subscriptions manage it).

Finally, to address your problem & question: to bridge the gap in the meantime, we want to add a convenience API, where you would be able to grant to subscription managed entitlements with the restriction that the grants will expire with the current usage-period (or next scheduled subscription change event, whichever is sooner). This would enable most simple top-up & overage scenarios in our opinion. Do i understand it right, that this would also cover your use-case?