Why would you need to connect the same customer multiple times?
Occasionally, you may want to allow your customer to link multiple integrations within the same category. For example, your customer Acme Corp. may have multiple subdivisions, one of which uses BambooHR, and the other, HiBob. Similarly, end-user's with Paylocity Integrations can have multiple sub-company instances, each with a different Company ID for their API access. This means that each Paylocity company will need to be connected as separate linked accounts. Merge supports this functionality.
How to set this up via Link
When you request a link token to initiate a Merge Link session, Merge determines whether to create a new linked account or modify an existing linked account based on a combination of the end_user_origin_id and the category. If Acme Corp. were to link BambooHR, and then you initiate another session in an attempt to link HiBob, Merge Link would open and assume that Acme Corp. wishes to modify their connection to BambooHR.
As it's important for you to differentiate between the two different connections (and give special UI treatment for modify vs. create linked account), in order to support multiple connections, you simply need to provide a different end_user_origin_id.
Recommendations on how to approach this build:
We recommend creating a table in your database, and storing the following information:
Your end user ID
A randomized ID/hash
This is what you'll pass to Merge as the
end_user_origin_id.
The integration slug/identifier. This is returned at the end of the linking flow.
You can also store any other metadata about the integration you'd like, though you can always fetch that from the
/available-actionsendpoint.
The account token (filled in once linking is complete)
That way, when your user is viewing their connections on your end, you're able to show multiple and know which end_user_origin_id to send over to Merge for each respective integration your customer has linked. This also enables you to link multiple instances of the same integration for the same end user.
Lastly, this approach has the added security benefit of not exposing any internal end_user_origin_ids.