Repository navigation
Time-based quotas + webhook events when quota is reached #94
Description
Preflight Checklist
- I have searched the issue tracker for an issue that matches the one I want to file, without success.
Problem Description
A lot of projects use quota-based billing instead of usage-based billing (eg. pay $X for Y credits/month). Currently the only way to implement this with OpenMeter is to make a GET request after every event to check the meter total. That's not very scalable.
Proposed Solution
This is how I imagine it would work:
- Each meter can have optional associated quotas with timeframes of Daily/Weekly/Monthly/Yearly/No timeframe. The timeframe determines when a quota resets.
- A webhook event is triggered when a quota is reached within the given timeframe. This can be used to inform another application that a quota has been reached.
- Allowing multiple quotas to be associated with each meter would let us trigger webhooks events for things warnings too.
Smaller and indie projects often prefer quotas because of the simpler billing model. I think adding this functionality would open up OpenMeter to a lot more developers.
PS. Another option could be returning the current meter's usage in the HTTP response when every event is posted. But I'm assuming that would require a database lookup on every event, which could get expensive.
Alternatives Considered
A simple Redis-based counter that is checked before each outgoing request is made.
Additional Information
No response
Activity
hekike commentedon Jul 6, 2023
Thank you for opening the issue; this makes sense.
OpenMeter doesn't know about billing periods and not every company bills on the first month of the date, so we need some API where users can set up a billing anchor and duration (weekly, monthly, etc.) per customer. Basically, usage specific alerting.
Something like:
But for that, you would need to register a threshold alert for each subscription. What do you think?
binaryfire commentedon Jul 6, 2023
Hi @hekike. That could certainly work and keeps things simple. I think we'd need a warning threshold as well. A warning webhook event would be required to implement logic to warn users when they are getting close to their limit.
But would it be better to define periods, thresholds and webhook URLs globally as "plans" and apply a plan + an anchor to individual subjects? In the vast majority of cases, a period / threshold / webhook combo would represent one tier for a specific product. Eg:
Product B
If we define these globally it'd be easier to change them for all users when we change our pricing, plan limits or webhook endpoints. 2 possibilities:
In either case, we'd be setting the anchor separately for each user/subject.
PS. I think "start_date" would be more user friendly than "anchor"
hekike commentedon Jul 11, 2023
Makes sense. Stripe uses anchor, for example, because billing periods can reset in specific scenarios and anchor changes. For example, when someone uses threshold-based billing. When a customer reaches the pre-set threshold, like $100, Stripe will generate an invoice and reset the billing anchor.
I think, in general, we need to find a way to trigger webhooks without going too much into billing or requiring OpenMeter to know too much about customers and billing.