API - Resolve relations for charges

It would be great, if the API for charges could also resolve relations like member, memberPackages and ResourceLogs, like it is the case for invoice and member.

Greetings,
Christoph from the grandgarage Team

Hey Christoph,

thanks for the suggestion. Yeah, I can see that this could be useful in some situations. But just so I understand your situation better: Which problem are you currently trying to solve and what API queries do you have to issue atm?

Best regards,
Raphael

Hi Raphael,
thanks for the fast response. We had to build an custom invoice export page for our accountant which includes some additional informations about packages related to the invoice. Right now a lot processing happens in the background and we have to make these two requests for the additional informations:

Invoices + charges + member details = /invoices/{ID}?embed=member&embed=details&embed=payments

package = /members/{ID}/packages/{ID}?embed=packages

All combined details will be displayed directly in an excel-similar web table without pagination. It that takes time to load all invoices for a month. And for this use case it can not be outsourced in a in-memory processing job, because a direct response is necessary.

Anyway it would be cool, if there could be included deep relations from a charge like the package. But I’m not sure if thats realistic?

Hey Christoph,

we’ve just added the ability to resolve member, onBehalfOf and memberPackage when using GET /charges.

I hope that helps! Let me know if you run into any other issues.

1 Like

Awesome, thanks for the fast resolution. Could it also be integrated single charge route /charge/{id}, like you did it also for invoices.

Sure!

1 Like

Is it possible to add the ability to also resolve the resourceLog in the get Charges route like the member and the memberPackages? :pray:
Greetings,
Sebastian from the grandgarage Team

Generally yes, except that I don’t know which fields would be useful to resolve. (resourceLog is a very big record.)

resolve is usually for providing the most important fields of a relation so that you don’t have to fetch everything just to display e.g. the name of the member who created a booking or the name of the equipment that was used. (vs. embed, which includes the whole record and is used to reduce the number of separate requests that a client needs to make, without reducing the amount of data being transmitted.)

Can you tell me more about your use-case? What problem are you trying to solve right now?

In our case, we need the charges “resources” for accounting purposes (together with member & memberPackages).
Currently, we make a call to every GET charge/:id for the charges in a month/quartal to retrieve all the information we need.
If we could retrieve the “resource” information from the resourceLogs via the charges API we could just do one call instead of a few hundreds.
This would have a great impact on the speed & stability of our accounting services.

Greetings,
Sebastian from the grandgarage Team

Hey @gg_it,

we finally shipped this improvement: You can now pass resolve=resourceLog and/or resolve=booking when fetching a list of charges. And in both cases, you get some basic details about the resource as well (name, type, state).

I hope that helps!

1 Like

Great - this will improve & speed up our accounting services, thank you! :star_struck:

1 Like