这个问题确实挺头疼的，我之前也遇到过类似的情况——X（原Twitter）的direct_messages/events/new.json这个端点的速率限制信息确实没法通过常规的rate_limit_status.json接口拿到，而且正常调用时也不会返回那些速率限制头。不过有几个可行的办法来处理：

• 查阅官方API文档：X的官方文档会明确标注每个端点的速率限制规则。针对direct_messages/events/new.json，当前的限制是每滚动24小时周期内，每个认证用户最多发送1500条私信。你可以直接从官方文档里获取这个固定的限制值，作为应用内限流的基准。

• 自行维护调用计数器：因为接口不主动返回剩余次数，你需要在自己的应用中为每个认证用户维护调用次数的记录。具体来说：

  • 记录每次调用的时间戳（UTC时间，和X的服务器时间对齐）
  • 每次调用前，计算该用户在过去24小时内的总调用次数
  • 如果次数未达上限则执行调用，否则触发限流逻辑

• 捕获429错误并获取实时限制信息：当你触发速率限制时，X会返回429 Too Many Requests状态码，此时响应头中会包含x-rate-limit-limit、x-rate-limit-remaining、x-rate-limit-reset这些关键字段。你可以在捕获到这个错误时，提取这些信息来校准你的计数器，或者实现基于重置时间的重试逻辑（注意不要频繁重试，避免被进一步限制）。

内容的提问来源于stack exchange，提问作者Hadi ABOU HAMZEH