我的原始帖子后面的一些更多背景信息可能不像我希望的那样清晰（请注意这一切都在沙盒中）：我的DocuSign帐户连接到两个不同的帐户，一个用于本地开发，另一个用于登台/ prod我被添加到。我们为两个帐户都有集成商密钥和OAuth配置。我们还为两者配置了连接webhooks，我的帐户隧道的端点通过ngrok到我的localhost，而web应用的端点指向同一个端点，但使用prod / staging主机名。
在本地测试时，我可以使用我的测试帐户登录OAuth，然后我们的网络应用会使用我的测试帐户的访问令牌发送文档进行签名。签名完成后，将调用到我的localhost的隧道的连接端点，然后Web应用程序将使用发送它的访问令牌的用户来获取签名文档。它似乎都正常工作，但是当在staging env中重新测试时，我注意到虽然积分器密钥已经切换，但它实际上是在我登录的用户的Connect设置上，而不是集成器帐户的Connect设置key（我可以看到Connect端点在我的本地日志中被点击）。在与另一个没有连接设置的单独测试用户启动OAuth流时，Connect似乎根本没有启动（日志中没有跟踪/失败）。
真正归结为：当文档的签名全部存在且认为已完成时，是否会检查集成商密钥帐户的连接设置或用于登录的帐户通过OAuth流程？我原以为它是集成键的帐户，但我的经验似乎在告诉我。
我希望这可以为可能正在阅读的人解决我的问题/困惑。
以下帖子的原始文字：
OAuth非常适合发送文档以进行签名和排除，但是当签名完成后，Connect设置似乎正在启动启动流的用户的设置而不是应用程序的设置。想知道这是否是预期的行为，或者我是否遗漏了某些东西。
由于我们不能指望我们的用户在他们的DocuSign设置中输入我们的Connect端点作为加入他们的一部分（我们也不想这样做，因为它意味着所有文件，包括未从我们的应用程序发送的文件）会发布到它）我想知道这里的最佳做法是什么。我意识到，如果我们放弃Connect并使用用户存储的访问密钥切换到轮询策略，我们可以获得我们想要的功能，但我们更愿意尽可能坚持使用Connect。
是否有其他人使用OAuth + Connect进行DocuSign集成？
答案 0 :(得分：0)
集成商密钥（OAuth-speak中的client_ids）独立于帐户。
client_id表示API的客户端。客户独立于账户。任何有权访问客户端软件的人都可以使用特定的客户端软件（及其client_id）。
为了通过客户端访问API，有人需要成为身份验证用户。这是授予客户端访问API的权限（通过OAuth）的人。
Connect webhook设置与帐户相关联，而不是与client_id相关联。我推荐using the API to create/check/modify the connect settings。这样您的应用就可以确保设置正常。
eventNotification每个信封设置webhook设置。
HTH，如果不清楚，请在评论中回复。