Add ability to provide external_id of customer instead of external_subscription_id when creating an event.
J
Jeffrey Koehler
The need to provide an external subscription ID with every event when I have multiple different subscriptions for different users means that I have to query lago for the currently active subscription type. This causes a lot of back and forth for each event.
I would instead like to provide the external ID of the user in the event, and no subscription ID, and have lago determine what subscription (potentially plural) to apply the metric to based on the metric code.
This would vastly simplify having different user levels (IE a "pro" or "enterprise" user might get decreased per-event usage rates, as opposed to a "basic" user)
J
Jeremy Denquin
Hello Jeffrey,
Thanks for your request.
Initially, we included both external_customer_id and external_subscription_id in the events. However, we removed external_customer_id a few months ago for several reasons.
The main reason is that, for us, an event should always be tied to a subscription. For large volumes of events, having to recompute the associated subscription from a customer ID didn’t make sense. We strongly believe that we should not be the source of truth for event/subscription mapping.
For your use case, I recommend leveraging our batch events endpoint:
Store the external_subscription_id in your system for each customer.
When sending events, you can easily build an array of events (even identical ones, if needed), each with its corresponding external_subscription_id.
I understand this might not be a perfect fit, but we aim to provide the best experience for as many use cases as possible without compromising the overall design.
Feel free to reach out in our Slack Community channel if you need any assistance!
J
Jeffrey Koehler
Jeremy Denquin
I would request you reconsider this. With the addition of "Features", it appears more and more that Lago is in fact aiming to
become
the source of truth.As is, I already AM treating it as the source of truth for everything, meaning I have to query Lago for each user's event, looping through the returned subscriptions to send events for each one that matches a list I have to
manually
provide. AKA that re-computation that "didn't make sense with a large volume of events"? Instead of handling it internally where Lago has direct access to perform queries with indexes, its been shoved on external users to do, who now have to deal with excess latency sending requests to a different service.
With the recent addition of "Features", the idea of being able to switch from one plan to another is becoming all the more relevant, but remains excessively complex due to the lack of the ability to simply send events on a per-user basis.
Lago is, IMO, genuinely almost perfect, but this remains a massive blemish on its capabilities.