Thanks Sai. Isaiah_C
For the record, I contacted MYOB Developer Support by email at 9:00am today. I have had no response, and no automated acknowledgement either, so I have no way of knowing whether the message was received.
Some additional detail in case it helps anyone else who hits this, and to save the next person the diagnosis:
The failure is intermittent, not consistent. On 4 September the consent page rendered normally (HTTP 200 at 08:15:47) and the whole outbound flow worked — authorize, login, password, MFA, login/callback, tpa/consent. The POST to /tpa/api/consent, raised when Connect was pressed, then returned HTTP 504 after exactly 61 seconds, which is a 60-second gateway timeout rather than an application rejection. An unauthenticated GET to the same endpoint later the same day returned a normal HTTP 405, so the edge is routing correctly.
Same endpoint, same unchanged request, failing in the morning and responding in the afternoon. That points to a transient fault behind the gateway rather than anything wrong with the client request.
The practical impact is that no interactive OAuth authorisation can be completed at all while this is occurring. We are running on an existing refresh token, which works — but if it lapses for any reason there is currently no way to re-authorise, so we have a production integration with no recovery path.
Has anyone else seen 504s specifically on /tpa/api/consent when completing authorisation? I would be interested in whether it correlates with time of day or with a particular redirect URI.
If any MYOB staff are able to check origin logs for that 08:16:48 AEST failure, I can supply the x-amz-cf-id from the response headers.
Hi Bonso , rather than an email, this link is the official way to contact MYOB API support (for the MYOB Business API) and will get you an auto-acknowledgement so that you know the request has been received, but an actual response may take a while, or so it seems from other posts.
Submit a request – Support for the MYOB family of SME product APIs
Hi Mike,
sorry for the late reply. I did submit a ticket/request at the same time but it has been sitting there for 5 days "Open"
I’m also running into the exact same 504 Gateway Timeout on /tpa/api/consent. It’s happening across both our production company file and sandbox environment. Fortunately, token refreshes for existing connections are still functioning normally.
Harvey_W ROC_MYOB
Harvey, thank you for posting. That is the first independent confirmation I have had, and it changes what this is.
Where this now stands. Two separate customers are hitting HTTP 504 on POST /tpa/api/consent, and in Harvey's case it affects both production and sandbox. On my side it reproduces outside my application entirely, in a clean browser session, with two different registered redirect URIs. The response headers show the 504 is generated by CloudFront after a 30 second origin timeout, not by the application. I supplied the x-amz-cf-id for one of the failures to ROC_MYOB (Ryan) on 9 September, and I appreciate him asking for it.
The timeline from my side:
4 September, 07:53 to 08:40 AEST, first failures
4 September, 09:00, emailed MYOB Developer Support. No reply, and no automated acknowledgement
4 September, posted here
5 September, support ticket submitted. Six days later it is still sitting at Open with no response
11 September, a second customer reports the identical fault
I want to be specific about why this matters rather than simply complain about the wait.
Both Harvey and I have noted that token refreshes for existing connections still work. That is not a mitigation. It is a countdown. Re-authorisation is the component that is broken, so any event that ends a stored grant, whether a refresh token reaching the end of its life, a revocation, or a transient error that causes an integration to discard its token, leaves a production integration with no way back in. There is no manual workaround, because the manual path is the consent screen that is returning 504.
This is not a degraded feature. It is a latent total outage for every affected integration, and neither of us can tell how long we have before it lands.
What I am asking for:
I will provide anything that helps, including logs, headers, client id, timestamps or a call at short notice. What I cannot do is keep waiting without knowing whether anyone is looking at it.
