调用 https://api.weixin.qq.com/cgi-bin/account/fastregister?access_token= 接口， 发送 https://mp.weixin.qq.com/cgi-bin/fastregisterauth?回调返回的ticket {"ticket":"**************"} 最终返回的结果是：{"errcode":61058,"errmsg":"invalid ticket"} 结果中也没有rid，请问可能的原因是什么？ （小程序已经创建成功： ） 文档中说明是：61058 用户扫码凭证校验不通过 但是这个说明对于问题的排查没有任何帮助作用，因为也只能是管理员才可以扫描成功，管理员扫码后出现这个情况，那还能让谁来扫码呢？ [图片]

获取直播房间列表的接口 https://api.weixin.qq.com/wxa/business/getliveinfo?access_token=，现在返回的信息中，缺失2大内容，希望官方能够完善： 1）房间信息没有 close_share 6个close参数，不管是创建房间还是编辑房间，都能够传入 closeShare ，但是获取房间列表却只返回了5个close参数，没有close_share， 这样会导致我们开发时信息不对称，能设置却无法读取真正的状态 2）货架商品信息没有是否已上架的信息 这个问题同样是信息不对称，开放时给我们提供上架、下架的API，但是获取信息时，又不让我们知道商品是否已经上架，这样我们开发出来的功能体验就不好，你们官方不是总在强调客户体验吗？

现有的素材管理接口只能针对公司素材进行管理，但是在实际运营中，有时候需要对顾问进行区别化管理（不同的顾问会有专属的能够发送的素材），这点当然微信官方也考虑到了，所以在《对话助手》的会话界面中有“小程序素材”这一栏目，但是目前这一栏目只能由顾问自己手动去编辑。在接入系统后，无论是商户也好，还是我们开发商也好，都希望这一栏目的内容能够由我们来按需自动生成，这样一来我们可以进行区别化的设置，顾问也不需要花时间去手动编辑。希望将来可以考虑开放针对顾问个人素材进行管理的api接口

顾问和公众号推文的每月主动群发推送触达粉丝的次数能否分开统计，公众号4次，顾问推送的也能单独有4次？ 因为从业务上来讲，公众号进行的推文针对的粉丝群体一般是公众号的所有粉丝，而顾问群发的内容一般是顾问所负责的那部分粉丝。如果每个月公众号已经做了推文，那么留给顾问能进行的群发机会就很少了。 当然估计你们最担心的是很多商家钻空子，用顾问来群发面向所有粉丝的消息。这点可以通过群发粉丝数量来控制，比如规则调整为：每个粉丝每个月可以接收4次公众号推文，且每个月可以接收4次来自顾问推送的群发粉丝数为总粉丝数1/4、1/5、......、甚至到1/10的群发信息。因为真正拿顾问来细化管理粉丝的，每个顾问分配到的粉丝一般都是有限的。

https://api.weixin.qq.com/cgi-bin/guide/getguidebuyerchatrecord?access_token= 获取顾问聊天记录接口在开始接入该接口时是没有问题，但是今天突然发现，接口调用无法返回正确的数据了，总是返回参数错误 POST参数如下： {"guide_openid":"oSeevt50BOjZsg0U_hnyjaq5hZJg","openid":"oSeevt5J3bP6AJiL8oQG3W8e0hnc","begin_time":"1604737539","end_time":"1607329539","page":0,"num":10000} 返回的数据如下： {"errcode":40097,"errmsg":"invalid args hint: [oHdFR0I2e-0c97lA] rid: 5fcde804-7393ece5-4a55ab1d"}

[图片] 现有的交互流程如上图，能从企业内部应用跳转到服务号对话助手，意味着我们可以在自有的企业应用中直接发起与粉丝的会话，对于我们来讲是一个很好的应用模式。 但是因为沟通是双向的，随着使用的深入，会发现顾问主动联系粉丝很流畅，但当粉丝主动联系顾问时，顾问想要了解粉丝在企业内的资料动态，还得手动切换回企业内部应用，并进行手动检索才能定位到该粉丝。 所以想问问官方会不会考虑将【服务号助手小程序】与【企业内部小程序】建立双向连接，即我们可以事先通过接口为公众号设置【服务号助手小程序】跳转的【企业内部小程序】页面信息，然后在会话界面中有按钮入口，直接跳转到【企业内部小程序】，并传入粉丝openid和顾问openid？ [图片]

按照文档说明调用与传参 POST https://api.weixin.qq.com/cgi-bin/guide/cancelguidemassendjob?access_token=ACCESS_TOKEN { "task_id":1332414111522783232 } 但是返回值总是 { "errcode": 40097, "errmsg": "invalid args hint: [AFgfT0I2e-bSV1Xa] rid: 5fae055e-165941e5-16ffd675" }

关于《为客户更换顾问》这个接口，我有个疑问，既然每个客户只能归属一个顾问，那么更换顾问时还得传递原顾问信息，是不是显得有点多余了？ 更换顾问前，非得再去调用《查询客户所属顾问》接口获取原顾问信息（因为通过接口分配的顾问，在MP上是可以手动进行顾问更换的，所以我们分配时缓存到商户系统的顾问信息，是无法保证百分百是当前顾问的），然后再调用《为客户更换顾问》接口更换顾问。 《为客户更换顾问》接口被强制上了一把锁，原顾问信息在接口里面就像是一把钥匙，有钥匙才能进行更换，但是，这把钥匙却是和锁挂在一起的，与其这样，为什么还要上锁呢？ 是不是其实可以废除《为客户更换顾问》接口，统一使用《为顾问分配客户》接口来分配或更换顾问，这样我们开发起来更简单，商户操作起来也更简便

[图片] 按接口的说明，是拉取该顾问近30天的聊天记录，但是接口实际返回的却是客户近30天的聊天记录。 举例说明一下： 如果客户甲的顾问一直是顾问A，则传入顾问A和客户甲，可以拉取他们之间30天内的聊天记录 但是，如果客户甲的顾问此前是顾问A，他们之间30天内有聊天记录，然后后来客户甲被重新分配给顾问B。 则传入顾问A和客户甲，是无法拉取聊天记录的，会返回没有顾问关系；如果传入顾问B和客户甲，则会返回顾问A和客户甲的聊天记录，及顾问B和客户甲的聊天记录（如果他们之间也有过聊天记录），并且返回的顾问A和客户甲的聊天记录中，顾问信息也是顾问B的信息（也就是说，聊天记录只跟客户有关系，跟顾问没有任何关系，传入的顾问信息只能是当前顾问，并且多顾问服务过的客户无法获知历史的聊天记录是和哪个顾问发送的）。 另外，还有一个更致命的bug：不停的更换顾问后，发现聊天记录会不断的被复制膨胀

标签管理接口只包含如下接口，那么需要修改标签名称的时候怎么办呢？需要删除某一个二级筛选项时又应该怎么办呢？ [图片] 另外标签类型只能支持4项太少了，能否扩容？