Hi. Implementing

ThirdPartyEmailPassword

recipe; I'm trying (on the backend) to detect from a user session, if the user is a social or email-password (or both ?) one. I can see the payload types from

getUserInfo

differ : thirdpartyemailpassword

ts
{
    id: string;
    timeJoined: number;
    email: string;
    thirdParty?: {
        id: string;
        userId: string;
    } | undefined;
}

emailpassword

ts
{
    id: string;
    timeJoined: number;
    email: string;
}

thirdparty

ts
{
    id: string;
    timeJoined: number;
    email: string;
    thirdParty: {
        id: string;
        userId: string;
    };
}

Is that

userInfo.thirdParty != null

supposed to be the legit way to differenciate between both ? Additionally : - what should be the behavior of a backend when trying to call

updateEmailOrPassword

on a thirdParty signuped account ? - is a user with both email-password / third party identities supposed to exist ? Thanks

> Is that userInfo.thirdParty != null supposed to be the legit way to differenciate between both ? Yes. > what should be the behavior of a backend when trying to call updateEmailOrPassword on a thirdParty signuped account ? If called for a third party user, this function will throw an error. > is a user with both email-password / third party identities supposed to exist ? No. They will be separate users. We will be adding the account linking feature which will allow you to merge the accounts into one unified user object.

Thanks for this fast and superclear answer. I'd suggest an entry point on the ThirdPartyEmailPassword recipe documentation (and potentially any "dual" recipe). Especially the last point was not super-clear to me (even after reading the WIP docs on account linking)

Fair enough 🙂 We shall consider 🙂

Another suggestion when I'm on it : this one :

ts
import { User } from 'supertokens-node/recipe/thirdpartyemailpassword/index.js'

Declared as

ts
export declare type User = {
    id: string;
    timeJoined: number;
    email: string;
    thirdParty?: {
        id: string;
        userId: string;
    };
};

Could be a type union between

ts
import { User } from 'supertokens-node/recipe/thirdparty/index.js'

and

ts
import { User } from 'supertokens-node/recipe/emailpassword/index.js'

Like so :

ts
export declare type User = ThirdPartyUser | EmailPasswordUser

--- It would unlock great TS features such as type narrowing and type guard. Like :

ts
const userIsThirdParty = (user: ThirdPartyEmailPasswordUser): user is ThirdPartyUser => user.thirdParty != null

I see. Fair enough. We are working on an sdk change which will get rid of the different user types and have one common one anyway.