I've tried the following:
Sending
profile: {
email: 'new.email@domain.com',
}
to accounts.setAccountInfo
,
Sending
addLoginEmails: 'new.email@domain.com'
Followed by
removeLoginEmails: 'old.email@domain.com'
to accounts.setAccountInfo
.
Nothing seems to work. I've also tried toggling conflictHandling: saveProfileAndFail
on and off.
The odd thing is that I can freely edit the user's settings in the Gigya console, just not using the REST APIs. Has anyone else experienced this? Any tips? I tried dumping the logs from the network tab when I was using the Gigya console and the payload of their request is almost identical to mine.
Thanks
Thanks for the comment, @Levi.
It turns out that there's a bit of an undocumented requirement here:
I was using exclusively emails which contained a +
symbol, I was frequently generating new emails to test some business logic, and it turns out that if the +
symbol is not URI Encoded (to %2B
), the calls to addLoginEmails
, and setting profile.email
would fail, and the removeLoginEmails
would simply do nothing.
My new payload looks like this:
profile: {
email: 'new.email%2Btest@domain.com',
},
addLoginEmails: 'new.email%2Btest@domain.com',
removeLoginEmails: 'old.email%2Btest@domain.com',
...
and everything functions as expected. The emails are also reflected in the Identity Access area of the console, and my request returns 200 OK as expected.
It seems a bit strange that this wasn't documented and I'm waiting for the next unexpected character error.