#ario_api
1 messages ยท Page 1 of 1 (latest)
๐ 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/1383180444488695990
๐ Have more to share? Add more details, code, screenshots, videos, etc. below.
Hi, I can provide more info if required
Hi there ๐ I'm trying to buidl some context here. Are you saying these requests are slow because you ran the same requests before and they executed more quickly?
Some endpoints do more work behind the scenes and are expected to take longer to respond than others.
Can you share the IDs of the requests that were slow, and any previous ones that weren't slow?
Those IDs should have an req_ prefix:
https://support.stripe.com/questions/finding-the-id-for-an-api-request
Sample screenshot of slow request
I've redacted some keywords for safety
It's to generate the stripe checkout url I believe
This is the code:
const session = await module.exports.client.checkout.sessions.create({
success_url,
payment_method_types: ['card'],
mode: 'subscription',
client_reference_id: user_id,
subscription_data: {
items: [{ plan: stripe_plan_id, quantity: 1 }],
},
});
return session.url;
That code isn't to the same endpoint
Oh, sorry - let me look
The code is to create a Checkout Session, the endpoint you're talking about is for creating a Billing Portal Session though.
Oh it does some kind of redirect hmm
Our endpoint? It shouldn't
Oh sorry I think I found it:
const session_object =
await module.exports.client.billingPortal.sessions.create({
customer: customer_id,
// In this flow, the user needs to
// 1. open the billing portal where the first screen they see is a "confirmation" of a change to their subscription
// 2. after confirmation get redirected back to the app. This is different than the usual "manage membership" flow, where by default the user sees the "manage membership splash page" (which includes a Change Membership button, and a Cancel button)
// 3. upon completion of either action they return to the same splash page instead of the app.
flow_data: {
type: 'subscription_update_confirm',
after_completion: {
type: 'redirect',
redirect: {
return_url: redirect_url,
},
},
subscription_update_confirm: {
subscription: subscription_id,
items: [
{
id: subscription_item_id,
price: stripe_plan_id,
quantity: 1,
},
],
},
},
});
return session_object.url;
This code?
Yeah, that looks like it would create a Billing Portal Session.
Looks like this is what's slow
Again, are you saying that is slow because you previously saw that endpoint respond more quickly?
I just see it as the slowest part in my tracing for P95
Maybe it's a non-issue
Honestly, looking more - it doesn't look that bad
We can close this thread if you like, sorry about the time waste
That's my thinking, some endpoints just have more processing that they have to do and take longer to respond. Creating a Billing Portal Session involves retrieving a lot of related objects (customers, billing portal configurations, subscriptions, payment method configurations, checks multiple subscription and invoicing settings, etc), so there's more processing involved before it can respond.
Understood - thank you
Any time! Best of luck with your project!