[koopajah]

Does it also mean that when doing an API client library for stripe you have to handle all this complexity about versionning? Because if someone updates to the latest version of the library but still wants to use the old way of creating a charge (staying on the example where charge would now always be 1$) he would want to be able to do it without having to find an older version of the library that supported this API version.

[amfeng]

Hi! OP here.

This actually works out okay for most of our libraries. For the ones that can support it (Ruby, Python, etc), we don't hardcode the properties for any resources and instead generate objects on-the-fly when you make an API request.

In the $1 example, the libraries will just construct a Charge object without the `amount` property, since it wasn't returned in the API response.

You're right that it isn't perfect for other languages, though. We're working on making our versioning story better in our docs, libraries, webhooks, etc. (:

[koopajah]

I understand how you handle it on your end but let's assume I decide to build an API for a language you don't support yet. In a few months when you add new versions of the API where some fields become optional or mandatory, then won't I have to know all this as the library developer and handle each case? Because some of my users would expect to still be able to send the charge amount while others would not.

I'm more thinking in the idea of doing some "pre-validation" in my library to avoid an API call from the client when something is already expected to fail (like missing the amount field right now) which would not fail with a new version of the API. So I would have to adapt to each version to know that this user would require the amount field while another one would not.

[boucher]

Yeah, we specifically designed this setup with your situation in mind. As the author of a library, you can specify the version you want to use. So your code will work on any account, regardless of what that account's version is set to.