Error getting invoice PDFs via the API

Hi all,

For over a week now we’ve been getting errors back when trying to retreive invoice PDFs via the API.

We’re using the .NET client and it looks like there’s just no data coming back from the API:

The call is to:
_client.GetInvoicePdfAsync(freeAgentInvoiceId);

and we’re seeing:

Unexpected character encountered while parsing value: . Path '', line 0, position 0.

Nothing’s changed our side, so I presume this is a freeagent issue, but just wanted to check if anyone else was having issues or if there’s a known issue with this at the moment?

Thanks

Hi Gareth,

Thanks for your message on our forum! My name is Ewa and I’m one of engineers here at FreeAgent – I’m sorry to hear you’ve had some trouble and I’ll do my best to help.

The error message you so helpfully quoted above is not one we recognize, is it possible it’s coming from the .NET client you’re using? Is there any chance you can look one level deeper and see what’s the status of the API response you’re receiving and the exact message the API returns?

Best wishes,

Ewa

Hi yeah, sorry about that - it’s been so long since I looked at our Freeagent API integration I forgot it’s our own library. We’re digging into the exact error now.

Can you let me know if there’s been any recent changes to the API at Freeagent’s side just to narrow down my culprit list a bit?

Thanks

Hi Gareth,

No problem at all, I’m glad we’re hopefully one step close to the answer! I’m not aware of any recent changes around invoices endpoints, and certainly not the one which allows you to retrieve them as a PDF. If our endpoint is indeed erroring out, if you can let me know the name of your integration and the response status you’re receiving, I can take look in our logs to see what’s going on.

Best wishes,

Ewa

1 Like

Hi Ewa,

Thanks for getting back to me. I’ve had a full dig into what’s going on now and can replicate the issue locally with a dev account.

It looks like our code is failing with any communication to Freeagent’s API - it just showed up as the PDF endpoint as that’s all we use the API for at this time (as well as negotiating new access tokens).

So I’m looking at a test we’ve got set up in the library which reproduces the issue. From the API we get a 200 response but the content is bonkers:

Now to me, that looks like we’re trying to read a HTTPS response as HTTP and not decrypting the TLS response, but we’re using Refit and .NET core in this library which will be doing all that for us. I can’t prove that’s the issue though.

Is there any way you can tie logs up at your end with these requests (what info do you need from me to do that? Our app is called: “Timetastic test freeagent app” that I’ve been testing with this morning) Or do you know if there have been any changes to SSL termination, authentication or the like on December 2nd as that’s when our logs first started reporting errors (just after midnight).

Thanks

Gareth

Hi Gareth,

Thanks a lot for this further info — after speaking to my colleagues, we think that this is most likely an issue with a GZIP response content not getting decrypted. This could happen if your requests include an Accept-Encoding: gzip header (you can verify that by either checking your requests or seeing whether the responses you receive include a header Content-Encoding: gzip) — some recent changes to our infrastructure that happened at around the time you started seeing errors for the first time could mean that that the encoding header started taking effect. Most clients (including .NET’s HttpClient) give you the option of decompressing request content automatically, so it looks like you should be able to tweak your library to handle decompression correctly.

I hope this helps!

Best wishes,

Ewa

Hi Ewa,

Ah Nice find! Thanks for the tip, I’ll dig into it and let you know if we get it sorted.

Just out of interest, is there any changelog or engineering blog we can subscribe to to get notifications of changes like this?

Just an update Ewa, that seems to have sorted it - thanks for sticking with me on that one!

For anyone else coming across this with ReFit, you’ll want something along the lines of:

            var handler = new HttpClientHandler
            {
                AutomaticDecompression = DecompressionMethods.GZip
            };
            var client = new HttpClient(handler)
            {
                BaseAddress = new Uri(rootUrl)
            };
            
            this.FreeAgentApi = RestService.For<IFreeAgentApi>(client, refitSettings);

to get it to work.

Thanks for the help Ewa, although I’m a bit frustrated that it took us so long to track down the error because there’s seemingly no way to find out when the FreeAgent API is going to change. I’ve come across this a few times with FreeAgent and it’s always a pain to trace.

Cheers

Hi Gareth,

Thanks for the update - I’m delighted to hear that our suggestion helped you get to the root of the issue and fix things up! :tada:

Please rest assured that we do our best to announce any planned breaking changes on this forum. The fact that gzip is now sent when requested for application/json (rather than the Accept-Encoding header being ignored) was an unintentional knock-on effect of some wide-reaching updates to FreeAgent’s infrastructure, so I can only apologise for not giving you a heads-up. If you ever spot some unexpected behaviour in the future (although of course we hope you don’t!), please don’t hesitate to raise it on the forum, and it will be investigated as soon as possible.

Best wishes,

Ewa