Lago is an incredibly flexible tool, but it will never be able to answer every user's needs. Custom expression are a reasonable stop-gap, but do not provide complete flexibility as they currently only allow referencing the data in a single event, and only using a pre-defined set of operations. As a way to allow users to define their own metrics calculations with complete flexibility, it would be very nice to have billable metrics have the ability to call a user-definable webhook that then returns the value to use on the invoice when it is necessary (During viewing of usage, and invoice calculations). The way that I imagine it, the webhook provides 5 main parameters, tho I can see more being useful. The start and end of the time being billed for, the external user ID being billed, the plan ID that is currently being billed, and the metric being billed. (If the webhook handler needs any more data, it can fetch it from Lago using that provided data.) From there, the handling endpoint can calculate the usage metrics based on the given parameters and return the "events" to Lago. Lago then calculates the invoice as it would any other and returns it, either to the end user looking at their portal, the lago user hitting the test invoice endpoint, or the billing engine itself charging the user and sending out the emails etc. Potential complications 1: The external service being called may have errors or instability and how to handle the invoice in that case is then complicated as it may not be able to be created with correct data. 2: The external service may be called several times in excess, including from the user directly loading their portal page. This could lead to a manner of overloading the end service. Some form of rate-limiting or caching should be used for atleast this call. 3: The user writing the webhook handler needs to make sure that it is a "read-only" request given the request may be made from several sources that are not actually charging the user. 4: Knowing how to bill an example invoice is complex as billing from start to now, or start to expected end may produce different results. 5: Given the filtering that a single metric can have, the single request to the webhook should have the ability to return multiple events, each with different properties. How to handle the excess metrics if filtering is not used, I don't know. Potential additions 1: It may be useful to allow the user to define extra query parameters of their own that are included in the request (or including some others automatically). I can see this being most useful for a user defining a single endpoint for multiple metrics, and switching the query they perform based on a query parameter defined in the webhook.
