If you want the Refund Total and other fields to be present in Orders, then @OmarAlmonte will inform the development team to see if they can implement it.
thanks @Pav for the quick reply. While I appreciate that I can make another call to get payment statuses (which I’ll implement as a fallback), I’d like to avoid having to make a call for each order I am dealing with. I’m also curious why the documentation lists those fields if they are not implemented? Or perhaps I am missing something.
EDIT: this is the documentation I’m referring to: Keap REST API
@OmarAlmonte will be back next week to answer your questions.
Bare in mind that the REST v2 API is still being updated so things could either be missing, broken, or yet to be released. There are several other gaps to be filled as other developers have been reporting things.
This came up for us a while back, and the key thing to check is whether the Orders v2 endpoint is returning the default field projection only.
Even though refund_total is listed in the Orders documentation, it isn’t always included in the default response. In those cases, it needs to be explicitly requested using the fields query parameter on the orders endpoint.
For example, adding a fields=refund_total parameter to the request (or explicitly listing all required fields) should cause it to be included in the response, assuming the order has refunds applied.
This behavior is consistent with how several other v2 endpoints handle non-default or computed fields.
General filtering and field selection patterns: Keap REST API
If that doesn’t surface it, it may indicate the endpoint is returning a summary projection for that request — but in our case, explicitly requesting the field resolved it.