amrakm_api

[queen vortex]

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1243159289745506344

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

[plush wigeon]

hi! that's the right API as far as I know.

but it requires me to provide start and end date parameters. I don't have these, I want it to be accurate numbers of their usage since billing cycle start date

start : subscription.current_period_start, end : Date.now() , I would think.

[polar ridge]

thank you for your quick answer!

what is the first value in the example snippet code in the link?

  "mtr_test_61Q8nQMqIFK9fRQmr41CMAXJrFdZ5MnA",
  customer="cus_Pp40waj64hdRxb",
  start_time=1711584000,
  end_time=1711666800,
  value_grouping_window="hour",
)```

what is :
  "mtr_test_61Q8nQMqIFK9fRQmr41CMAXJrFdZ5MnA",

[plush wigeon]

the ID of the meter object (https://docs.stripe.com/api/billing/meter/object) who's usage you're summarising

[polar ridge]

Thank you, and what is the subscription object that you extracted current_period_start from?

I tried this but didn't work:
subscription = stripe.SubscriptionItem.retrieve(subscription_item_id)

[plush wigeon]

it's just a Subscription sub_xxx https://docs.stripe.com/api/subscriptions/object#subscription_object-current_period_start

SubscriptionItem is something else(it's the line items of a Subscription)

[polar ridge]

thank you for your help, I got the start date now, but the API seems to expect timestamp rounded to the nearest hour? this might not give accurate usage if we round:

```InvalidRequestError: Request req_26JDEtJQobXpod: start_time 1716386177 should be aligned with hourly boundaries (expected 1716382800) because the value_grouping_window is hour.

Also, what other accepted values for `value_grouping_window` other than hour? I just need the final number, I don't want to aggregate over the aggregated list

[plush wigeon]

as far as I know aggregation is the only way to get the information

https://docs.stripe.com/billing/subscriptions/usage-based/implementation-guide#query-reported-usage for instance is just pointing at this API

[polar ridge]

and the only aggregation value accepted is hourly?

[plush wigeon]

yep

[polar ridge]

is there another way of displaying usage information to the user directly? can I change the settings of customer portal to make it display current usage? not just estimated bill?

[plush wigeon]

well the estimated bill does contain the usage

[plush wigeon]

the reason this is is aggregated is because there is not just a simple counter internally, as far as I understand it, the incoming usage is aggregated async

[polar ridge]

this is from customer portal, while you are in the first 100 you don't see how much you consumed, once you are in the next tier you start seeing charges

I'm strugging to get accurate number from list_event_summaries api, they seem not to include recent events

[plush wigeon]

yep that's what I mean , the total is not always available because the data is counted async. It mentions in the docs

The total usage value might not be the most up-to-date quantity because events aggregate asynchronously.

Meter event summary: The event summary for a customer and meter returns aggregated usage for a period (the meter defines the aggregation formula). In our example, the meter event summary returns the sum() of tokens for a specific customer, meter, and time window. Meter events don’t become available on the read path and are asynchronously aggregated into Meter event summary results.

[polar ridge]

thank you for your help, is it raesonable to round starting date to the nearest previous hour

end date to nearest next hour

Then the result will still be an estimate, not necessarily actual number, so I will report it to the end user and display this disclaimer

At the same time I will point them to customer portal for more accurate number on the billing; is that more accurate? or is it the same asynchronous method?

[molten cloud]

The portal will just reflect the values available in the API

[polar ridge]

so both ( portal + list_event_summaries ) read from the same source?