504 Gateway Timeout on /tpa/api/consent and /tpa/api/consent/validateUser

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:

• Confirmation that this is a known fault and that someone is working on it. Yes or no is fine. Seven days without acknowledgement on an authentication endpoint is the part I am struggling with, more than the fault itself.
• An incident or reference number covering it, so this is not tracked as two unrelated tickets from two customers.
• The refresh token lifetime for the granular sme-* scopes. If it is finite, that is our deadline, and at the moment we are being asked to plan around something we cannot see.
• Written confirmation that completing a new consent does not revoke or rotate an existing grant. I have now asked this twice. Until it is answered I cannot safely retry the consent flow to check whether the fault has cleared, because a failed attempt could cost me the working token my production system is currently running on.

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.