id is a string and not a number

[phiilu]

I noticed that the id field of a Variant or Product is a string and not a number, while all other ids (store_id, product_id) are numbers.

Going through the code I did not see why this is the case.

[PJUllrich]

@phiilu yes, that's weird indeed, but it's how LemonSqueezy returns these IDs 🤷

I find it interesting that variant.product_id is a number, but product.id is a string :D
That's also how they document it in the Variant Object and the Product Object

What happens if you send e.g. a product_id as string and not as number? Does the API return an error?

Maybe we should raise this with LemonSqueezy?

[PJUllrich]

I requested that they unify the types of IDs in LemonSqueezy's Feature Request page. I can't link to the request directly but if you search for API: Unify type of IDs in API Responses you'll find it. Here's the feature request website: https://www.lemonsqueezy.com/suggest-feature

[phiilu]

Thanks for reporting this to the Lemon Squeezy Team! I upvoted it 😄

And yes, you are totally right the API is returning indeed a string for the id 😅 I did not consider this 🙈

This makes it quite annoying to work with the results. As you already mentioned the product.id is a string and variant.product_id is a number and those can't be compared with ==

I hope they change it or give a good reason why this is the case ^^

[PJUllrich]

What do you think, would it make it easier to use the library if we’d sanitize this in our responses? So, to convert all integer IDs to string IDs when building the response struct? We can always remove it once they fix it on their end.

…

On 15. Apr 2023 at 09:21 +0200, Florian Kapfenberger ***@***.***>, wrote: Thanks for reporting this to the Lemon Squeezy Team! I upvoted it 😄 And yes, you are totally right the API is returning indeed a string for the id 😅 I did not consider this 🙈 This makes it quite annoying to work with the results. As you already mentioned the product.id is a string and variant.product_id is a number and those can't be compared with == I hope they change it or give a good reason why this is the case ^^ — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[phiilu]

I do not really have a definitive answer 😅

I think this could be a convenient solution, but I am not so sure if it is a good idea to change the types of API responses. Maybe this can cause confusion (?)

On the other side casting all _id fields to strings would not be a big issue I think, as probably no one should do any arithmetic calculations with them ^^

So with that said I would be fine with both approaches:

• it can stay how it is and lemon_ex parses the Response exactly how Lemon Squeezy returns it
• change all _id fields to strings so it is easier to work with them

If you find one or the other solution better, then you can decide what makes the most sense to you 😄

[PJUllrich]

@phiilu sorry for getting back to you so late, but I agreed with you and saw no need for further action. I'm reluctant to change the API response to anything that isn't defined in the docs. Otherwise, folks might get confused why the doc say one thing and the code returns another thing. I submitted the feature request there, so let's see. Maybe they fix it. Maybe they don't.