nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

400 Bad Request errors 29 July 2025

SatoriFPA

Getting 400 Bad request errors on differing tables and different entities when trying to retrieve data today.

Find more posts tagged with

Accepted answers

All comments

Shem

Yes, I can confirm, Calxa is also now running smoothly on all endpoints.

SatoriFPA

Just got an email from Api Support advising to try again.

ETL appears to be running smoothly across multiple entities and endpoints.

Shem

Hey everyone - just want to flag we have also experienced a sudden spike in Bad Request errors with the ErrorType: InvalidQueryStringException. This started at a similar time as reported here.

In our case, we have built-in retry logic and, in some cases, this logic reduces the page size of subsequent requests. In most cases the retry logic is working, which to me shows the issue is not an InvalidQueryStringException.

I opened a support case with the API Support team yesterday and I do have a reply advising they are escalating to the API Engineering team internally.

They also mentioned the AccountRight API can be sensitive to formatting, encoding, or combinations of $top and $filter values, especially at large page sizes ($top=1000). They therefore suggested we could try some initial steps at our end to improve the success rate of requests.

Temporarily default to smaller $top values (e.g. 200 or 500) where filters are complex or involve collections (Lines/any(...)). While this increases call volume, it may avoid the errors in the short term.
Try URL-encoding the entire $filter parameter, even if it worked unencoded before.

We've implemented the above 2 points but it's too early to suggest if this has had any meaningful impact. Overnight all our connections will perform their daily sync tasks so we'll have a better idea tomorrow.

Cheers Shem

SatoriFPA

Status page still shows as green, but when I reached out to the CDATA team who built the ODBC driver for MYOB, they reported having numerous other customers who were also receiving the same issues.

SatoriFPA

@Shella_A

I still have no response to the ticket that I have lodged with the API support team.

When I reached out to the CDATA team, who built the ODBC MYOB driver that I use, they reported seeing this issue from other customers as well.

The api support team have not responded to the ticket.

With multiple customers seeing the same issue with various tenants, this is a MYOB API issue.
But there is no acknowledgement of this on the MYOB status page.

Can you please escalate this internally?

Marco_P

@Shella_A We have the same problem here. Getting lots of 400 - Bad request errors. Users keep being disconnected. It started on 29 Jul around 10pm utc. The same requets can work fine for many other accounts. Something has definitely changed on MYOB end. Can you please check what was released around that time?

MikeWbsync

@SatoriFPA any news on your ticket? We are having the same issue. Same code for 5+ years working without issue now seems to be failed randomly. We are seeing it mostly when using ODATA on Items but are also seeing it randomly on Contacts also.

SatoriFPA

Ticket #45913 has been raised with the MYOB APIsupport team.
It does not yet appear to have been reviewed

mcdonaldaj

i have exactly the same issue and it started on the same date. It would seem that something on the MYOB server side has changed which has started this problem. This same API call has worked daily without issue for the past 2 years.

Shella_A

Hi @SatoriFPA,

The "400 - Bad request" error usually means the invoice data sent to MYOB doesn't meet API requirements. To investigate, MYOB needs the API call's header and body details, which you generally can’t access or retrieve from your computer. You may send a support request to our MYOB API Team using this link to sort this out.

Cheers,

Shella