#nova-astramentis_api

1 messages ยท Page 1 of 1 (latest)

hearty pawnBOT
#

๐Ÿ‘‹ 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/1395782787088257097

๐Ÿ“ Have more to share? Add more details, code, screenshots, videos, etc. below.

echo quail
dense mirage
#

We do, but calculating the discounts (especially if a discount applies to only one item in the invoice) gets messy real quick. We were hoping to leverage the Stripe API to do the calculations for us, and grab the final result.

echo quail
#

But right after you create the invoice, you'd know the amount right after all the discounts etc

#

What are you planning to do with the 'final amount' before the invoice is created?

dense mirage
#

Set the application fee (6.5% of subtotal)

echo quail
#

I see, that is not supported. You'd calculate this on your end. I'll raise your feedback to our product team to allow passing application fee in percentage on invoices here. Thank you for the feedback.

dense mirage
#

Gotcha, thats unfortunate but thank you for the info. I did have one side question for you, does it really require 2+ calls to add line items to the invoice (but not the preview)? I understand we have the bulk route, but is it planned for me being able to specify line items during invoice creation directly?

I ask because we self rate limit our requests to be good little stripe devs, but a single federated invoice could take 15 requests to create invoices from 5 shops simultaneously

echo quail
dense mirage
#

Ah, so at minimum its 1 request per invoice item, then 1 request to create the invoice

echo quail
#

Yes

dense mirage
#

Okay, as we scale we might need to reach out to you all to up our API rate limit. I have it set to 100 requests per minute, but that gets eaten real quick with this behavior. Perhaps, if you dont mind, you can raise feedback surrounding the ability to create invoice line items (for a one-off invoice) in-line with the request to create the invoice itself? The preview route is very convenient for this case

echo quail
#

You should group these invoice line items as API rate limit increases are not guaranteed, and are not supported for long term support.

I'll share that feedback, thank you

dense mirage
#

The invoice item create route has no bulk, only the invoice line item route. What is the difference here?

echo quail
#

Can you reword what you're asking please?

dense mirage
#

What is the difference between the two, or are they conceptually the same

echo quail
#

Yes, they are different in out API. InvoiceItems are top-level objects that are primarily created through calls to /v1/invoiceitems. Once an InvoiceItem has been added to an Invoice it will have an associated InvoiceLineItem, which is a nested resource under Invoices. It can't be directly created via the API.

dense mirage
#

Okay, maybe this is easier then. Code-wise, would this be a valid way of accomplishing what I described above (if not a little resource intensive)

image.png
#

Flow is:

Customer checks out -> We separate each 'storefront' into an invoice on a connected account -> create draft invoice -> add line items -> get subtotal from the invoice -> update application fee amount

echo quail
#

Please note that you can only create an Invoice item via the API and not Invoice line items.

dense mirage
hearty pawnBOT
echo quail
#

Ah, that is different. You adds multiple line items to an invoice

dense mirage
#

Yeah, this is why I am mightily confused! Functionally, does the bulk add line items route not work exactly how the add invoice item route works if I were to iterate over each item individually?

#

At least from the user perspective

echo quail
#

I recommend that you test all of this using your Sandbox.

#

It will make it easier to understand how it all works, and you can share the request IDs here if you're stuck

#

Without explicit object ids, it can be hard to ensure we're on the same page

dense mirage
#

Fair. I think the confusion lies in what the actual difference (user-facing only) is between the two API sections. Its not explained anywhere on the API itself (invoice line items are backed by invoice items means nothing when the example doesnt provide any meaningful difference)

#

For example, does calling bulk add invoice line items create an invoice item for me? Because if it doesnt, it violates this statement.

image.png
weak portal
#

Hi hi! Iโ€™m going to be taking over for my colleague here.

I'm not sure I quite follow what you mean here?

dense mirage
#

Hi, thanks for your help pgskc! Welcome to the party timebox.

My apologies for any confusion, I think im just getting lost (and admittedly a tiny bit frustrated) because of the conflicting statements here + on the API docs. Let me try and refocus.

Problem:

I am trying to create a draft invoice for a customer. As part of this operation, I needed to calculate a percentage of the total invoice amount in order to set application_fee.

Discussed so far:

Your colleague said I should group invoice line items due to API rate limiting (fair) #1395782787088257097 message

Your API says all invoice line items must be backed by either an invoice_item or subscription_item. #1395782787088257097 message

I asked what the difference is between creating an invoice item through https://docs.stripe.com/api/invoiceitems?api-version=2024-10-28.acacia (which creates an invoice line item) and creating an invoice line item through https://docs.stripe.com/api/invoice-line-item?api-version=2024-10-28.acacia. The example on the second API route suggests I don't need a pre-existing invoice_item to create an invoice_line_item. I wanted to know then, what the functional difference between a POST /invoice_item vs POST /invoice_line_item is from my perspective (or do they behave similarly).

weak portal
#

Well, you can't create an item by POSTing to /v1/invoice_line_item for a start - which is a fairly material difference. ๐Ÿ™‚

dense mirage
#

Is the example incorrect then?

weak portal
#

Sorry, which example?

dense mirage
weak portal
#

That API endpoint requires an existing Invoice.

#

The other does not.

dense mirage
#

Gotcha, okay there is the difference. I have a draft invoice already (with zero items on it), so I can bulk-add line items correct?

weak portal
#

Correct. ๐Ÿ™‚

#

Ahhhhh, ok. I think I get this. GIve me a quick second for the steam from my ears to clear.

#

You want to apply a 10% Application Fee to the Invoice Items on an Invoice, right?

So if you create the bunch of Invoice Items, you can then iterate over them and: sum up with the total of the amount, compute the application fee amount as a percentage of that, and then bulk-add them all and set the Application Fee.

Right?

dense mirage
#

Yeah, thats about right. Stripe handles shipping rates, discounts and currency conversion for us, so the idea was to use the value you guys calculate on the invoice subtotalExcludingTax to be the "source of truth" on the amount charged to the user. Then, i take a percentage of that and update the invoice to use the percentage fee.

#

My original query was 'is there a better way to do this' using invoice previews

weak portal
#

Ooo, ya, your way is better. ๐Ÿ˜‚

#

If we offered a percentage option, that would, as you've pointed out, obviously be the best choice. My very broken memory tells me we used to have something that had application_fee_percent, but at this point I'm not sure I trust that My Memory fellow as far as I can throw him. ๐Ÿ˜…

dense mirage
#

Google's AI summary seems to remember application_fee_percent but I wasnt sure if it was hallucinating or not :/

#

I swear on a stack of leetcode that once upon a day I was allowed to do this, but no longer. I don't want to hit your API like a freight train, so im trying to reduce the number of times I round robin

weak portal
#

I also trust generative AI about as far as I can throw it too, and given the weight of a data center ... that ain't far. ยฏ_(ใƒ„)_/ยฏ

Yup, makes sense. ๐Ÿ™‚

#

(It's good at some tasks for sure, but it seems that, to err is not exclusively human.

dense mirage
#

Its great if you know the subject matter and how to verify. I spent about 3 hours trying to find application_fee_percent which lead me here, which might explain why I was a little dry on details at times

#

I do appreciate helping out though, we at least reduced our API count from 10+ per invoice to a static 3, which is already a major improvement

weak portal
#

Ya, it does create some pretty exciting goose chasing adventures.

That's awesome - and you're very welcome! ๐Ÿ™‚

Have you been running into rate limiting? Is that the impetus for this?

dense mirage
#

The man who coded this ~3 years looked at his code and asked what idiot wrote this, before realizing hes the sole server side developer. I like to behave when im a guest in another company's api servers, so I was aghast that I hit my rate limiter 14 times for a single invoice. I then did the math and was like 'if we have 4 concurrent users, we are boned'

#

So we havent hit it yet, but i try to keep my rate limiter as a fraction of the total allotment

weak portal
#

That's fair. I believe "what idiot wrote thi... ... uhhh, oh, never mind it was me" is not uncommon in this game - I know I have uttered a similar phrase more than once. ๐Ÿ˜…

Awesome. The biggest thing is having an understanding of when you might be getting close, so you can work on mitigating. ๐Ÿ™‚

dense mirage
#

Next steps are probably a processing queue using kafka, but i will wait until my client feels like its necessary to spend the money on that ๐Ÿ™‚

#

Hardest part about using your API is transactional concurrency in my own program. My objects arent in the database by the time you send me a webhook >.<

weak portal
#

Yes, that is hard. Idempotency is critical.

Synchronous systems are hard. Asynchronous systems are harder. Distributed systems are nutty. ยฏ_(ใƒ„)_/ยฏ

dense mirage
#

Just mirror stripe objects 1-1 in your database, react to webhook events and pretend everything is fine copium

weak portal
#

lmaohno

dense mirage
#

Either way, i think we can close the thread since the original question + followups are good ๐Ÿ™‚ Thank you for your help and see you next time im confused!