#ubi
sonic vine
Tag: v756 fails, so something happened since v756 that the whole thing is busted
Remove support for expand on BankAccount#delete and Card#delete
I found that inv756
Here is the PR about the situation: https://github.com/beam-community/stripity-stripe/pull/829/files
finite fractalBOT
bold orbit
Hi @sonic vine I'm here to help
Is your test case about creating an external account and setting it to a connected account?
sonic vine
Focusing on one at the time:
describe "update/2" do
test "updates a bank account" do
assert {:ok, _} = Stripe.BankAccount.update("cus_123", "ba_123")
assert_stripe_requested(:post, "/v1/customers/cus_123/sources/ba_123")
end
end
That is failing, which it is calling
def update(account, id, params \\ %{}, opts \\ []) do
path =
Stripe.OpenApi.Path.replace_path_params(
"/v1/accounts/{account}/external_accounts/{id}",
So, everything changed from /customers/ to /accounts
I do see it here!
bold orbit
Were you using an old Stripe API version before?
sonic vine
eeehh, no clue, it stopped working on v756 the last one that worked just fine is v755
so, I guess so?
is the "/v1/accounts/{account}/external_accounts/{id}" the correct one nowadays?
bold orbit
Yes, you are right
sonic vine
hhhmm, should I "break change" in my client, or moving forward towards that API will no break change for people using it?
bold orbit
What's the Stripe API version that you are using now?
sonic vine
so, removing /v1/customers in favor of /v1/accounts wouldn't break change, is that correct?
I am trying to use v756 at the very moment, ideally I would use latest
There?
bold orbit
I'm still wating for your Stripe API version.
sonic vine
Sorry, I shared it before, I said the v756 tag, from https://github.com/stripe/openapi/releases/tag/v756
I am trying to upgrade to that tag, since the last one that worked was v755
bold orbit
No. This is the Stripe API Version I'm tallking about https://stripe.com/docs/upgrades#api-versions
sonic vine
that one: "version": "2023-10-16",
bold orbit
Ok that's the latest API version, yes you should use /v1/accounts/{account}/external_accounts/{id} for external accounts
sonic vine
Would it be a breaking change to go from /v1/customers in favor of /v1/accounts given the same API version of "version": "2023-10-16"?
BEFORE: "/v1/customers/cus_123/sources/card_123"
AFTER: "/v1/accounts/cus_123/external_accounts/card_123"
For the same "version": "2023-10-16"
bold orbit
I still don't understand why you were using /v1/customers for external accounts. That endpoint is for customer.
Anyway, if you are not changing the Stripe API version, then there's no breaking change involved.
sonic vine
I am not sure neither, that information comes form your OpenAPI Spec 
bold orbit
Do you have the link to that information?
sonic vine
these are the changes: https://github.com/stripe/openapi/compare/v755...v756
The before and after, in your official OpenAPI file
Is that incorrect by any change? Before I break change due to a mistake in your side, I am not sure, I am going by the official OpenAPI spec
bold orbit
This is just a diff between two files. It indicates that the "/v1/customers/{}/sources/{}/verify" endpoint is removed, it doesn't means that "/v1/accounts/{}/external_account/{}" is a replacement.
sonic vine
I see so they are two identical update operations now (without taking into consideration the path value)
One for the external account, and the other one for the customer 
bold orbit
Well, update is a common operations that exist in lots of stripe resources.
sonic vine
how does your SDKs know the differences between one and another one? Do you check the path value or is there any other value that would tell me the nested resource type?
bold orbit
Based on the path prefix. For instance /v1/customers is for customer resources and /v1/accounts is for account resources.
What do you mean by nested resource type?
sonic vine
The "x-stripeOperations" is a propietary value attached to the Schema, therefore nested by the schemas.
They are not part of the OpenAPI Spec, 
it seems that it would be amazing if the spec is designed to be CodeGen friendly, without having to do prefixing lookup by the path
Something like operationId from OpenAPI spec
ooooh I see, I can lookup the operationId by reading the path back to the paths object
bold orbit
I'm not familiar with Open API spec. If you believe this is a feature request, you can create a ticket in the stripe openapi repo, or reach out to support https://support.stripe.com/contact/email