Hi, I have been testing the new RESTFul API. Previously with the old API I was querying a list of unpaid invoices, but one thing I did not get was the Term Days - which you now get on the new API which is great, as you can calculate the due date from this now instead of performing a second round of queries on each individual document which is how I was getting Term Days until now. However, the new API /invoices does not include the viewHref which gives you a direct link to the pdf of the invoice. I have looked at the new API /invoices/{id} response and here you get preview_uri which you can use to look at the invoice but this also gives you the buttons for other things like running a statement etc. Do you intend to include the equivalent of the viewHref key/value paid in the /invoices response as before which gives a link to the PDF of the invoice only? I hope so! Thanks, Rob.
Hi @rocketman
The way to get a PDF has been moved into a separate endpoint, GET /invoices/{id}/get-pdf
Details and an example can be found here: Quickfile API Documentation
Hi,
Thanks…this does mean a lot more API calls as you have to loop through for each invoice to grab the link for each one…but if that is the approach, then at least it is possible…
I was hoping things would be simplified now that we have the term days on the /invoices one…but we gained one thing and lost another.
But, OK - thanks!
Rob.
Hi Rob
Thanks for the feedback!
Just curious on the use case here, to see if we can understand how users are using the API. If there’s a clear case, then I can certainly pass this back to our development team.
Hi Mathew,
Sure - no problem. Internally we have a Power BI dashboard that shows outstanding invoices and how many days until due/overdue etc. There is also a link to view the document (for each row using the viewHref field). One thing I did also notice is that we are also looping through the individual invoice documents to get the currency factor from the document header so the outstanding total of all invoices can be represented in GBP.
We can get to everything we need, now that you have directed me to the new pdf endpoint (that seems to also give just the document but not the other options like run statement etc.), but I think as a design principle on your side it would be good to include fields in the API that will likely prevent the need for people to have to write solutions that first gets the records, and then have to make repeated calls by looping through individual documents as this will have I guess some kind of performance impact on the API and service on your side…so more header/document related fields like the PDF link and in my case the currency factor would prevent this. I appreciate that mine might be one opinion of many, but hope the feedback is useful.
Thanks, Rob.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.