REST v2 - List Payments by Invoice IDs

@OmarAlmonte, in XML-RPC we can get a list of the Payments by supplying a list of the Invoice iDs.

Checking the new Sales - List Payments endpoint, you can only supply a list of Payments based on their IDs. I do not see the ability of providing a list of Invoice IDs, only a single Order ID.

https://developer.infusionsoft.com/docs/restv2/#tag/Sales/operation/listPayments

@Angi_Hast, your team needs to be putting more thought into these API Endpoints.

We do not expose a separate invoice Id in our REST APIs, only the Order Id.
This was an intentional design decision when we implemented the v1 REST API in 2015.

@Tom_Scott, here are my thoughts on whole REST matter including yourself.

Failure 1 - When your team started the REST project did they not understand the capabilities of the XML-RPC API? REST v1 was meant to be a replacement, but failed in a number of areas. How did that happen?

Failure 2 - It is now 2026, which is 11 years on since REST started. And still up to this date it is not fully comparable to XML-RPC, and it will never be. That is a very long time to get the API right. The XML-RPC could have been sunset 7 years ago if the REST API was correctly designed.

Failure 3 - You failed to help the community in a number of ways. Several issues were reported over the years, and they were not fixed. Only in the past few months they were corrected because they were raised again. How becomes you never got them resolved? Did you bother registering them internally?

Failure 4 - The original PHP iSDK was a great SDK, and with minor tweaking can still work on the latest version of PHP. When the new SDK came to support REST, it was overly third party library dependent, which made it 10x bigger than it was before. Then it was trapped in waiting for those vendors to keep it up to date with newer versions of PHP. I know you were involved in maintaining it, but did it not register the problems it would bring?

Failure 5 - Your team are not putting thought in these endpoints, it seems to be the case of hope for the best and see if anyone reports the missing features.

Failure 6 - REST v2 was meant to be the improved version for REST v1, comparable to XML-RPC, and would have corrected the previous issues. Well that does not seem to have been the case. Was that the intentional design as well?

I could go on with the list of failures, but it would fall on deaf ears.