Hi KJM,
I’m sorry to hear you’re running into 504 Gateway Timeout errors. Hopefully another developer in the community can share some insight and get back to you soon. If you’re still unable to resolve this, feel free to reach out to the MYOB Developer Support team via developer.myob.com, so they can look into it further.
Regards,
Sai
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.
