环信只是即时通讯的消息通道。环信本身不提供用户体系，环信既不保存任何 APP 业务数据，也不保存任何 APP 的用户信息。比如说，你的 APP 是一个婚恋交友 APP，那么你的 APP 用户的头像、昵称、身高、体重、三围、电话号码等信息是保存在你自己的 APP 业务服务器上，这些信息不需要告诉环信，环信也不想知道。
环信这样设计的目的有2个：
要使用环信，只需要为每一个 APP 用户创建一个环信账号。创建环信账号仅需要以下信息：
{
"username": "jliu", //username是第三方用户体系中的primary key。需要在AppKey的范围内唯一。
"password":"123456" //密码。为保证第三方用户体系中的账号密码不必要的泄露给环信，建议对第三方用户体系的账号密码做一次hash算法。然后在手机端登录环信时，客户端同样使用hash后的密码登录。
}
环信和用户体系的集成主要发生在2个地方，服务器端集成和客户端集成。
用户管理 REST API 提供了一个创建环信账号的 REST 方法。这个方法很简单，只需要提供账号 ID 和密码2个参数，就可以创建一个环信账号。对一个已经上线，已经有很多现有用户的 APP 来说，要集成环信，只需要写一个脚本，循环调用创建环信用户的 REST 方法即可。
环信账号中的 username 可以和已有的 APP 用户体系的用户的 primary key 相同。这样做的好处是不需要对现有 APP 后台的数据库的用户表做任何修改（比如不需要给用户表增加一个叫环信账号 ID 的字段）。
为保证安全，强烈建议只在服务器端调用创建环信账号的 REST 方法。具体方法见用户管理 REST API。即每次当 APP 客户端调用 APP 自己的业务后台创建新用户时，也在环信上为该 APP 用户创建一个环信账号。
通常的做法是在自己 APP 创建用户成功后调用创建环信账号的 REST 方法来创建环信账号。因为这个方法是服务器对服务器的调用，所以因为网络不稳定原因失败的可能很小。但开发者仍旧需要对该方法的返回结果做处理，如果该方法失败，应该做个 retry，如果仍旧失败，应该回滚在自己 APP 创建用户的操作。否则会导致 APP 的用户账号和环信账号不一致的问题。
为保证安全，强烈建议只在服务器端调用删除环信账号的 REST 方法。具体方法见用户管理 REST API。即每次当 APP 客户端调用 APP 自己的业务后台删除新用户时，也在环信上将该 APP 用户对应的环信账号删除。
为保证安全，强烈建议只在服务器端调用修改环信账号密码的 REST 方法。具体方法见用户管理 REST API。即每次当 APP 用户的密码被修改时，也要更新该 APP 用户对应的环信账号的密码。
APP 客户端在登录自己的 APP 服务器后台成功后，需要调用环信客户端 SDK 的登录方法。
APP 客户端在退出登录自己的 APP 服务器后台成功后，需要调用环信客户端 SDK 的退出登录方法。
所谓好友体系，是指谁是谁的好友的关系体系。环信提供好友体系，但不是必须使用的。
比如对一个企业内部移动办公 APP 来说，因为企业内部同事是彼此认识的，那么此 APP 可能是不需要消息发送权限控制的。即任何人都可以给任何人发消息。
但一个交友类的 APP 就必须要控制只有我的好友才能给我发消息，不是我的好友的人需要向我发送加好友邀请，我批准后才能给我发消息。这种情况下，就需要启用环信提供的好友体系。
APP 可以将现有 APP 的好友关系导入到环信的好友体系中。
好友列表管理 REST API 提供了一个修改环信账号好友体系的 REST 方法。对一个已经上线，已经有很多现有用户的 APP 来说，只需要写一个脚本，循环调用修改环信账号好友体系的 REST 方法即可。
好友列表管理 REST API 提供了一个修改环信账号好友体系的 REST 方法。即每次当 APP 业务后台的用户的好友列表发生变化时，也在环信上更新该 APP 用户的好友体系。
如前文所述，是否在环信中建立好友体系，是否开启或关闭发送消息的权限控制，是由 APP 管理者自己决定的。
通常来说，“将已上线的 APP 的现有用户的好友体系导入到环信”这个是在 APP 的服务器端做的。但“APP 用户好友列表更新时也同步更新环信账号的好友体系”这个操作则根据 APP 具体的业务场景，既可以在服务器端做，也可以在客户端做。