Query parameter missing in api calls

[Noroth]

I noticed that the ListCheckouts function is not working for me. I took a look at the code of functions that require query parameters and it seems that those parameters are not passed to the API.

E.g.: params is unused in the function. Also applies to other functions

sumup-go/checkouts.go

Lines 798 to 801 in 665a7e6

	func (s *CheckoutsService) List(ctx context.Context, params ListCheckoutsParams) (*ListCheckoutsResponse, error) {
	path := fmt.Sprintf("/v0.1/checkouts")
	req, err := s.client.NewRequest(ctx, http.MethodGet, path, http.NoBody)

[DrissiReda]

For me it always returns an empty list, even if I use this, and I have a bunch of parameters

checkouts, err := client.Checkouts.List(context.Background(), sumup.ListCheckoutsParams{})

did you manage to get this to work? even without parameters.

Another thing for trying refunds, no matter what I do I get error 404 not found

[Noroth]

I compared the calls to simple cURL requests.

To answer your question, I also get an empty list when I don't specify anything in the query. Is this correct? I don't know. We will have to ask the Sumup team here.
However, I get a response if I provide a checkout ref with cURL, but not when using the Go SDK.

I haven't tested refunds yet.

Personally, I think that the API could use a few more filter parameters because if I don't somehow save the checkout references that I specify during checkout creation I will have a hard time finding out which of them have already been created and are pending as I am not able to see them somewhere in the dashboard.

I thought the List endpoint would solve this problem for me, but it actually seems to be a GetByCheckoutReference rather than a ListCheckouts functionality. Maybe I'm wrong here and missing something.

[DrissiReda]

@Noroth The API describes it as getting ALL checkouts if nothing is specified. However the only way /checkouts work is getting a single checkout using its reference as a parameter.

It's weird to not have a solution to list every checkout. I contacted [email protected] and they haven't been helpful. They link the API doc as if it's my mistake I've tried multiple times to explain the documentation isn't working as intended and it's been falling on deaf ears.

Can I contact you if you're working on this? Maybe we can progress better together. Get back to me if you're open to that.

[Noroth]

@DrissiReda I'm currently on vacation. I will be back on the 24.10.

Let's see if someone has replied to that issue by then. I am currently only working on a PoC whether we want to integrate Sumup into our system.

We can talk when I'm back home. Is that okay?

[DrissiReda]

Great that works. Working on a PoC for the same reason.

[matoous]

Heya, I am sorry for the late response, this slipped through.

We are working on an overhaul of the code generator where we will address this. It aims to also improve error handling and a few more things. I will keep you posted, thanks for reporting!

[Noroth]

Hi @matoous
there are great tools for client generation available. Such as https://github.com/oapi-codegen/oapi-codegen

Does this not fit your needs?

[matoous]

We use oapi-codegen extensively internally, it works well, but doesn't generate style of code that we would like to eventually like to achieve with the golang SDK (specifically, we hope to extend the amount of products that are available via APIs and would prefer it to be more structured than everything being methods on a the root Client struct. Furthermore, this SDK should eventually provide everything necessary for event handling).

If you prefer the code generated by oapi-codegen or before we reach maturity in this repo you can always copy the openapi specs either from here or from https://github.com/sumup/openapi and generate the client on your side.

[Noroth]

I was just asking out of curiosity. Maintaining code generators can be quite a time consuming task especially if you are generating from specs such as OpenAPI as those will eventually be updated and you might wanna keep it up-to-date as good as possible

https://github.com/OAI/OpenAPI-Specification/

But I'm not here to stop you :)

[matoous]

Addressed in: #10