I hit this recently and there’s a hotfix in the works (possibly already released) that should resolve it. Should be getting backported to FR32, FR34 and FR36.
I was informed that for the custom reports engine APIs you should be able to workaround the issue by adding QSDK and a space before the token eg oQSDK<space>Access token string] instead of the bearer token prefix. Haven’t tried that myself though… just went back to using the classic QSDK Token in the AuthToken header approach for the time being.
I hit this recently and there’s a hotfix in the works (possibly already released) that should resolve it. Should be getting backported to FR32, FR34 and FR36.
I was informed that for the custom reports engine APIs you should be able to workaround the issue by adding QSDK and a space before the token eg oQSDK<space>Access token string] instead of the bearer token prefix. Haven’t tried that myself though… just went back to using the classic QSDK Token in the AuthToken header approach for the time being.
Awesome, I will try the QSDK thing.
I am using the bearer token to update excel spreadsheets and had to write a login script just to get the data.
Super annoying.
Thanks.