How to Handle Multiple SmartThings Accounts Linked to the Same Third-party Service Account?

Devices & Integrations
1

Hello, @nayelyz

I want to implement a scenario where SmartThings accounts A and B are both linked to the same Third-party Service account, and even if account A disconnects, account B continues to function normally.

To implement this flow, I would need a way to identify the SmartThings account. However, after reviewing the Interaction Types documentation, it appears that there is no information provided by SmartThings—such as an ID or token—that allows us to distinguish between accounts.

In this situation, what would be the recommended approach to handle this?

2

I’m not sure if I understood your argument correctly, but I faced problems when trying to link third-party services (like Tuya and Tapo) to my SmartThings (ST) account.

I have three homes registered, and when I linked a third-party service account (for example, Tuya) to my ST account, the system automatically linked the Tuya devices to all three homes at once, even though I only wanted to add them to one. It was the same with Tapo: all the cameras were linked to every home, even the ones that don’t have cameras.

This created an excessive amount of work. I had to go into each home’s account in ST to remove the devices I didn’t want to link, because the system didn’t give me the option to choose which home to add the service to. And whenever the third-party service had a problem, I had to repeat the entire process.

To solve this, the only solution was to create two SmartThings accounts and manage the third-party services (Tuya, Smart Life, and Tapo) separately for each of the homes.

4

Hi @sb_yun

Thanks for the details. Could you clarify what you’re trying to achieve?

  • If you’re looking to integrate your own IoT device into SmartThings, the interaction types mentioned above relate to Schema-based integrations, which are used to connect devices from an external cloud into SmartThings.
  • If your goal is to consume or control SmartThings devices from your own cloud, that’s a different use case, where your service would need the ability to access and manage devices already installed in a SmartThings location.

Once we better understand your intent, we can point you in the right direction.

5

Hello, @Itati

I’m working on integrating my own IoT device with SmartThings, so that it can be controlled and its data can be accessed both from my own cloud (3rd-party) and from SmartThings.

I’ve been following the Interaction Types documentation, and most of the features are working as expected, including device registration, control, and deletion. However, I’m facing the following issue:

  1. When my service is connected to SmartThings, OAuth authenticates my service account X, and the devices already linked to account X are registered in SmartThings through the discoveryRequest process.

  2. Device control works correctly through Command, and any changes made directly or via my service are reflected in SmartThings using Callback.

  3. When SmartThings accounts A and B are both linked to the same service account X, both A and B can control and delete the devices.

  4. The problem occurs when account A tries to unlink from X. Currently, there seems to be no way to distinguish between A and B, as I don’t see any identifier in the documentation that allows me to separate SmartThings accounts. My goal is to allow A to unlink while B remains linked, but I haven’t found a solution for this.

Could you advise on the correct way to handle this scenario?

6

Thanks for the details you shared.
Just to confirm, did you create your Schema app using the Developer Console, and did you specify the schemaType during creation? This is important, as missing that parameter could prevent SmartThings from sending the integrationDeleted event when a user unlinks.

7

I created the app in the Developer Console and also specified the schemaType.

I am receiving the integrationDeleted event correctly, but I am unable to determine whether the event came from an unlink action in Account A or in Account B.

8

Thanks for the follow-up and for confirming that you’re receiving the integrationDeleted event.

Just to clarify: the payload includes two key tokens you can use to identify which SmartThings user initiated the unlink:

{
  "headers": {
    "schema": "st-schema",
    "version": "1.0",
    "interactionType": "integrationDeleted",
    "requestId": "abc-123-456"
  },
  "authentication": { 
    "tokenType": "Bearer", 
    "token": "Partner access token" 
  }, 
  "callbackAuthentication": {
    "accessToken": "xxxxxxxxxxx",
    "refreshToken": "xxxxxxxxxxx"
  }
}

authentication.token - This is your service’s token for the user (the Partner Access Token). It may be expired or invalid at the time of deletion, since SmartThings does not refresh it when sending this request.
callbackAuthentication.accessToken - This is the SmartThings-issued token, and it is unique per SmartThings user who linked your service.
This is the key you can use to distinguish between Account A and Account B, even if both are linked to the same service account (X).

9

Thank you for your support.
I would like to raise one additional concern.

It is not entirely clear whether the grantCallbackAccess request is always sent together with the discoveryRequest every 24 hours, but it does appear to be triggered periodically. As a result, our service updates the callbackAuthentication.accessToken whenever such a request is received.

The challenge is that each grantCallbackAccess request issues a new callbackAuthentication.accessToken, but there seems to be no straightforward way to determine whether this token belongs to Account A or Account B. Consequently, it is unclear which account’s callbackAuthentication.accessToken should be updated in our system.

Could you please advise on the best approach to handle this situation?

10

Hi @sb_yun

The grantCallbackAccess request is not executed with every discovery.

In the discovery response, there is a property called requestGrantCallbackAccess. If this is set to "true", it will force a new grantCallbackAccess. Please make sure that your response is not returning this value as true, since this should only be used in cases where the original refreshToken has been lost.

Also, in the grantCallbackAccess request you will see the authentication property, which contains the token that your service originally provided.

11

Thank you for your response. I was able to resolve it successfully.
Thank you so much. :folded_hands: