Thanks Harvey_W
Can I ask you three things, because your change may be the answer for both of us:
1. Which redirect URI did you remove, and which did you keep?
2. How many did you have registered before, and how many now?
3. Did you change anything else at all, even something you dismissed as unrelated?
The reason I am pressing on the count rather than the value: on 4 September I ran a clean browser A/B test with DevTools recording, no client software involved, changing only the redirect_uri in the authorize URL.
https://desktop validateUser 504, consent 504
https://127.0.0.1:49202/ validateUser 200 but 14.12 seconds, consent 504 after 30.02 seconds
Both failed. I concluded the redirect URI was exonerated, and I have been treating it as ruled out ever since. But both of those values were registered in the dashboard at the time. Your fix suggests I ruled out the wrong thing. It is entirely consistent with my results that the fault is having more than one redirect URI registered, or a particular combination of them, rather than which one the request carries.
I have two registered, https://desktop and https://127.0.0.1:49202/. That is the same condition you were in before you changed it.
Second variable, which may or may not be relevant. Your scopes are seven:
offline_access, openid, sme-company-file, sme-contacts-customer, sme-general-ledger, sme-inventory, sme-sales
Mine are ten:
sme-company-file, sme-company-settings, sme-payroll, sme-contacts-employee, sme-timebilling, sme-sales, sme-general-ledger, sme-contacts-customer, sme-contacts-supplier, sme-purchases
My consent POST body is 4919 bytes, which is where those scopes are carried. I raised scope count as a possible factor with ROC_MYOB on 9 September and it has not been answered either way. Given you are working on seven and I am failing on ten, it stays on the list.
To any MYOB staff reading: there are now two customers, one of whom has recovered by changing redirect URI registration, and a specific difference in scope count between us. That is a far better lead than either of us had last week and it should be quicker for your engineers to chase than a blind repro. ROC_MYOB , you have my x-amz-cf-id from 9 September and told me on the 11th that you had a hypothesis with your developers — does this fit it?
One thing I still cannot do, and it is the reason I have not simply tried Harvey's change and retested. Nobody at MYOB has confirmed whether attempting or completing a new consent revokes or rotates the refresh token an application already holds. I have asked on 4, 9 and 11 September through three channels. Our production payroll runs on that token, and the only recovery path if it dies is the consent flow that has been broken for twelve days. I am not gambling production on an unanswered question.
So: a straight yes or no on that, and I can test Harvey_W finding today and report back here.
The timeline was:
Working again here too.
Retested this morning — validateUser came back 200 in 1.67 seconds. On 4 September it was 504. Whole chain is clean.
Harvey_W , your posts were easily the most useful thing in this thread, MYOB included. And credit for the follow-up, because you disproved your own theory: 3 redirect URIs, then 2, then 3 again and still working. So it wasn't the redirect URIs for either of us. Something got fixed on their end, quietly, around the 11th.
Tip for anyone else stuck: validateUser fires when you pick the business file and grants nothing. Connect is what actually approves. So you can check whether it's working without touching your existing token — just stop before you press Connect.
Still waiting on MYOB for three things, and I'd like them even though I'm unblocked:
Does a new consent kill an existing refresh token? Asked three times since 4 September. This is the one that cost me most. I couldn't test whether it was fixed, so I sat blocked for about six days after it already was.
An incident number.
The idle lifetime on refresh tokens. I have the 12 month reconnect off the consent screen, but not whether there's a shorter idle expiry.
Hi Bonso , according to How long do access tokens & refresh tokens last? – Support for the MYOB family of SME product APIs since 2020 the refresh tokens last a week. (In 2020 that was reduced from 1 year). I'm not aware of any subsequent changes.
