Hi,
I’ve been using the API extensively for a long time and suddenly I’m hitting errors with Bank Transactions Explanations. This is something we’ve been doing for a number of years now and it’s no longer working for us.
For all requests to create an Explanation we are getting an HTTP 302 redirect reponse:
<html><body>You are being <a href="https://api.freeagent.com/sessions/new">redirected</a>.</body></html>
This is the same on the sandbox too…
At the same time, we are not having any problems on the api with anything else. Just the creation of bank transactions, though we can list/get them.
Any ideas? Has something changed?
Thanks.
I believe I’ve found the issue.
The API on your side has been updated, it seems, and it’s removed certain undocumented traits. I’ve found a few of them over the last couple of weeks, and this is just the latest.
Before your backend updates, we could send the "ID"s of bank accounts, Bills, Invoices etc., while explaining transactions. But now you only strictly accept the URIs. This is more than a bit of a pain. Because what it means now, is that before I can perform such a request, I must now make several other requests to pull down data for bank accounts, bills etc., so I can then get the associated full URIs. Why can’t I just “assume” URIs based? Because you could easily change the URIs, and I would have to hard-code URIs for sandbox testing and live. The only constant is IDs.
This, along with your upcoming rate limits, is all a bit counter-intuitive. If what you wanted was moreAPI requests to hit you, you got it 
Thanks.
Hi Paul,
While, as you noted, passing ids rather than URIs is an undocumented behaviour, I’ve had a dig into our recent changes and I haven’t found anything that should affect this.
Looking back through our logs, it appears that you are sending the ID of related entities (such as paid_invoice) formatted as a number and I’ve been able to reproduce your issue when formatting the request in this way. As we’re expecting a URL, the entity value is expected to be a string and passing IDs as strings does behave correctly - is it possible you have been doing this in the past?
I’d be keen to hear of other undocumented traits that may have been removed (aside from Brutal Inconsistencies in API responses/documentation, which I’m aware of), although I must stress that depending on undocumented traits of the API may result in things breaking later.
