我找到了此文档，说明docusign API的资源/速率限制。 https://developers.docusign.com/esign-rest-api/guides/resource-limits但是，在开发和测试期间我没有遇到任何与资源限制有关的错误。这些仅在生产环境中有效吗？有没有一种方法可以在开发过程中测试这些限制，以确保应用程序在生产中能够正常运行？该文件有效/最新吗？
更新（我也想在这里扩展我的问题）
所以只有一种限制？每小时1000个电话，仅此而已？还是我也需要在两次请求相同网址之间等待15分钟？
如果存在第二种限制（在15分钟的间隔内多次调用同一URL），它仅适用于GET请求吗？因此，我仍然可以在15分钟内多次创建/更新信封吗？ 另外，如果存在第二种限制，我可以以某种方式在沙盒环境中对其进行测试吗？
答案 0 :(得分：1)
该限制在沙箱系统中也处于活动状态。
尚未对所有API方法进行计量。
要进行测试，只需进行大量调用，您就会看到已应用限制。例如，在一小时内进行1,000次状态呼叫。或创建1,000个信封，您将受到限制。
正确。每小时通话次数是目前唯一的硬性限制。如果通常每小时1,000个呼叫对于您的应用程序来说还是不够的，或者对于您的应用程序的特定用户来说还是不够的，那么有一个增加限额的过程。
这是轮询限制。如果每个信封每15分钟对DocuSign进行一次以上的轮询，则该应用程序的行为就不会很好。换句话说，您可以每15分钟轮询一次信封A的状态，也可以每15分钟轮询一次信封B的状态。
作为Go Live过程的一部分，将在应用程序测试期间监视轮询限制。一旦应用程序投入生产，它也会受到软监控。将来，对生产应用程序轮询的监视将变得更加自动化。
如果要轮询的信封很多，则 可能会遇到每小时1,000个呼叫的限制。
但是没有必要在轮询中遇到问题：不要轮询！而是通过DocuSign Connect或eventNotification设置Webhook，我们将给您打电话。
每小时仅（默认）1,000个呼叫会影响非轮询方法。
例如，一遍又一遍地询问信封接收者的状态，字段值，一般状态等。创建/更新信封的次数可以根据需要进行（每小时默认设置为1,000个）。
如果您想每小时创建1000个以上的信封，我们将很乐意为您提供服务。 （我们的许多大客户正是这样做的。）
我们关心的主要问题是不必要的轮询。
可能还有其他一些我们不希望遇到的不必要的电话。例如，每次用户登录仅需要OAuth:getUser调用一次。由于信息不变，因此不应重复多次。