I would recommend that you instead disallow sign up if the email already exists using a different method.

That’s much easier to do

That being said, I can probably make a small write up on it tomorrow

That being said, I’ll do a write up on it sometime tomorrow here

hey @Untel so here is the writeup: - Start by overriding the backend signinup POST API to first check if a session exists using the

getSession

function with optional session verification. If a session exists, then you know that the user is logged in and that they are probably trying to link a social provider to their account. In this case, add the session object to the userContext object before calling the original implementation. - Override the createNewSession function on the session recipe to check if the session object exists in the userContext obj and if it does, then just return that session else call the original implementation. The above will make sure that during social login account linking, you do not end up creating a new session and reuse the existing one. The next step is to associate the new userId (of the social login sign up) with the actual user ID of the user. This can be done in many ways: - Use the user metadata recipe to store this mapping. - Store this mapping in your own database. Either way, you can do this mapping in the signInUpPOST API override after you have called the original implementation and its response from the function call has {status: "OK"}. You will also have access to the access token of the social provider here which you can use / store in this case. ----------- The above is a basic implementation, and has several edge cases that are not accounted for, but for simple cases, it works.