Suddenly overnight "mark invoice as" has broken

1

So it looks like you guys did an update overnight as suddenly our integration is broken.

We’ve changed nothing. We are trying to mark our invoices as “sent” but we’re now getting this error:

Client error: PUT https://api.freeagent.com/v2/invoices/24976806/transitions/mark_as_sent resulted in a 401 Unauthorized response"

We’re able to create the invoices with exactly the same authorization, but now suddenly this is broken.

Please please can someone look at this as it’s breaking our integration outright.

Thanks.

2

Does someone plan to take a look at this, please?

3

Hi Paul,

Thank you for your message and apologies for taking the small delay in getting back to you, we needed to take a dive through our log files to track down the issue, here.

We’ve found one of your failing requests from Friday morning and it looks like you’re sending some parameters, along with your PUT request, that our server interprets as an empty array ([]). This might be related to a change at our end, but without knowing exactly what’s being sent to our server (we don’t capture raw logs as these wouldn’t be sanitised), it’s tricky to reproduce.

Could you do me a favour and post your request to a service like postb.in and share the raw request with me us on this thread, please? Once we know exactly what’s hitting our server, we can try to find where the empty array is coming from.

You might also want to try tweaking your integration so it purely makes a PUT request to /v2/invoices/24976806/transitions/mark_as_sent, ensuring no further request parameters are sent.

Thanks for your help,
Dave J

4

Great stuff, thanks for getting back.

So I ensured our integration was sending no data whatsoever - it turns out it was essentially sending an array with a single key and no data. This resolved the problem. So I guess there was a change made somewhere such that non-usable data in a request now breaks a requests.

It’d be great to have:
a) more accurate and consistent error messages throughout the api responses since this isn’t the first time people are reporting, for example, 401 authorization when it’s not in-fact the case. If a request is going to die for a specific reason, it’d be great to have access to this reason so we can dig into, and not have to raise support requests. It’s a bottleneck for you and for us.

b) if you’re receiving data that’s not applicable to a particular request, which is easily done, perhaps strip it out, rather than self-destruct.

Thanks for looking at this and giving the necessary pointers.

5

Hi Paul,

Thanks for your update and I’m pleased to hear you managed to track down the rogue request parameters.

Absolutely, we agree with both your points about returning a misleading error code and lack of meaningful error. What’s funny is that, internally, your requests did trigger a 500 error, though something in the stack seemingly rewrote this to a 401 response before returning to you. We’re tracking that down at the moment.

We’re generally looking at improving our error responses and further sanitising user input, so rogue parameters are ignored whenever possible, as you’re right, this would save time for both end-users and our team :thumbsup:

Thanks, as always, for your feedback!

Dave J