（私はアサナで働いています）
これは優れた質問であり、むしろ一連の質問です。
すべてのオブジェクトに対して繰り返し要求を行うシステムを設計しています。オブジェクトの数が増えるとどうなりますか？最初の要求率が妥当であったとしても、これにはスケーラビリティの問題があります。よりスケーラブルなソリューションは、システムの変更の数に応じて拡張できるソリューションです。これも時間の経過とともに増加しますが、はるかにゆっくりです。1人のユーザーが1日に行うことができる変更の数は比較的一定ですが、時間の経過とともに作成したオブジェクトの総数は増加します。したがって、私の最初のアドバイスは、この方法で物事を行うことを避け、代わりに変更を検出してそれらに基づいて行動する方法を見つけることです。このアプローチを採用することで能力が失われると感じる理由を知ることは興味深いでしょう。
さて、Asana APIは現在、システムの変更を検出するための使いやすいメカニズムを提供していないことを知りました。これはよくリクエストされる機能であり、現在調査中ですが、残念ながら納期をお約束することはできません。したがって、今のところシステムをポーリングする以外に選択肢がない場合があります。
APIに対して礼儀正しいことに関しては、多くのサービスプロバイダーは、APIの偶発的または悪意のある使用が他の顧客へのサービスに影響を与えることを防ぐために、APIの使用に制限を設定しています。Asanaも例外ではありません。これらの制限が公開されている場合と公開されていない場合があり、標準の制限はありません。すべてサービスによって異なります。ただし、サービスの制限について知りたいと思っている方は、非常に思いやりがあります。
とは言うものの、1日あたり15万件のリクエストは、AsanaAPIにとってはかなりの量です。すべてのAPIユーザーから大量のトラフィックが発生した場合、1日あたりのリクエスト数はGoogle Web Searchよりも多くなる可能性があり、まだそれほどスケーラブルではありません。:)技術的には、場合によっては、単一のユーザーからのそのボリュームでのリクエストを処理することがあります。
ポーリングする必要がある場合は、15分などの間隔でポーリングしてみてください。ただし、この期間にワークスペース全体をポーリングしないでください。トラフィック/データが多すぎる可能性があります。私たちは、より良いソリューションを提供するために取り組んでいます。
Asana APIに対して非常に多くのリクエストを行うと、目的の応答ではなくHTTPステータスコード429が返されます。詳細については、こちら（https://asana.com/developers/documentation/getting-started/errors）をご覧ください。