#zach_api

1 messages · Page 1 of 1 (latest)

solid hatchBOT
#

👋 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/1300448590275149925

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

Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

sullen elbow
#

Hi there 👋 can you help me understand what you're seeing when you try to use those, what kind of error are you running into?

normal saddle
#

The error is that I do not see the V2 Attribute

#

on the stripe object, so I cannot make any calls to V2

#

If i put a watchpoint on the client, it shows me all the attributes available

#

V2 is not listed that

sullen elbow
#

What version of our python SDK are you using?

normal saddle
#

11.1.1

sullen elbow
#

Hm, that version should include support for V2 billing endpoints. I'm not familiar with the watchpoint you're referring to.

Can you share the code you're trying to run to use a V2 endpoint, and what error you see when you try to run that?

normal saddle
#

watchpoint just is a debugging term, for looking at the values of a variable or object in the debugger

#

here you can see, the different attributes available

#

and you can see that the v2 attributes do not show

sullen elbow
normal saddle
#

you can see here this is the error I get

#

client = stripe.StripeClient("OUR_API_KEY")
response = client.v2.billing.meter_event_session.create()

#

this is the code being run

normal saddle
#

I can see the v2 object in stripe client

#

One thing I noticed, that I am not sure is relevant is when i watch my stripe object

#

it shows api_version as 2024-04-10

sullen elbow
#

Oh, I'm more interested in that 9.6.0 version. Is that the version of stripe-python?

normal saddle
#

no its 11.1.1 right?

#

this is from a pip install --upgrade stripe

sullen elbow
#

I'm not exactly sure. The pip output does look like version 11.1.1 is in the environment, but I'm not exaclty sure that is the same environment, or has been pulled into, the other screenshots you shared. That VERSION value is making me very suspicous that an older version is still being used, from before support for the v2 billing endpoints was added.

rancid willow
normal saddle
#

OK

#

im glad that was in fact off

#

let me uninstall and reinstall stripe

#

see if it makes any difference

#

then dig into it very granularly as to why it might be showing that

#

very helpful thanks, ill be back if i cant get anywhere 🙂

#

Idk if you guys are still there, but QQ on this v2

#

before the old meter events had a huge limitation of only 1 usage record per meter per customer could be triggered at a time, it would error out if we sent more than 1 at a time

#

with the v2, is this solved? AKA, can i parallelize the creation of meter event sessions, and be sending usage for the ssame customer at the same time in more than 1 meter event session?

rancid willow
#

I believe this is still applicable, so you'd like want to accrue the usage and send periodically for the customer to avoid overlapping requests (or queue & defer them etc)

normal saddle
#

hmm, i see.

solid hatchBOT
normal saddle
#

I was hopeful that since this v2 seems to be a sync-async bridge of sorts

#

where i send synchronous calls which are validated

#

then you are sending behind the scenes/managing behind the scenes

#

that this would remove this limitation since it would be on your end that the usage actually hits the meter

meager trail
#

Looking in to this, so far I haven't found confirmatino either way. To be honest I wasn't aware that that was a restriction on the v1 API at least for the mode where usage was summed up rather than set

normal saddle
#

correct this was for summed usage

#

it would not let you send multiple usage records for the same customer against the same meter at the same time

#

i had to implement a queueing mechanism to throttle this on our end

#

problem is now the throughput of the queue sending 1 at a time is not good enough, our scale is to much

#

I was hoping v2 might help us here, because it seemed like we could send multiple at the same time, get them validated synchronously and then from your end you would handle the posting to the meter

meager trail
#

@normal saddle Gotcha, unfortunately a colleague confirmed that this is still a restriction in v2 at the moment. What is your account ID? I can add it to the feature request for removing this restriction

normal saddle
#

@meager trail ok thank you for confirming, will publishable key work?

#

I also wanted to ask if they have made any progress on the MAX functionality for metered usage, it was a feature request a few months ago when I checked. With old usage records, you could send usage and use the "max" setting to only bill for the max usage for the month.

#

Do you have any insight into an update on that? or any potential beta?

meager trail
#

I can look up your account ID from a publishable key though it is considered safe to share the actual acct_ account ID publicly

#

Looking in to the max question and will get back to you

normal saddle