どうもありがとうございます！はい、やります！具体的にはページビュー（ログインユーザー、匿名ユーザー、クローラー）を探しているのですが、APIドキュメントに見当たりません。何かヒントはありますか？
管理者固有の呼び出しの一部がAPIドキュメントに記載されていません
ネットワークタブを開き、管理者ページに移動し、取得したいデータを含むレポートを表示してから、ネットワークタブを確認してブラウザが何を読み込んだかを確認します。
これは、Reverse engineer the Discourse API の要約です
私がすることは、データエクスプローラープラグインを使用して必要なものを取得し、それをAPIでプルダウンすることです。Discourse APIでData Explorerクエリを実行する
もちろんです。管理パネルで提供されているものとは異なるデータが必要な場合は、DE（データ抽出）が最適です。
また、そのクエリがアップデート後も同じデータを返すという保証も得られますが、基盤となる構造が変更され、クエリを保守する必要が生じる可能性もあります。
どちらにしてもトレードオフはあります。
お二人ともありがとうございます！「リバースエンジニアリング」手法とAPIキーでうまくいきました！本当にありがとうございました！
この会話には少し遅れてしまいました（まあ、その拡張版ですが :p）。私も Discourse フォーラムからデータを取得したいと考えていましたが、API キーの設定が面倒だったので、もしあなた（または誰か）が任意の Discourse フォーラムから投稿を取得するための簡単なラッパーを求めているなら、こちら をチェックしてみてください。
PyPi でリリースされているので、pip/uv で簡単にインストールできます。レート制限も自動的に処理し、Pydantic で型付けされているため（個人的には開発者体験が向上すると思います）、使い勝手が良いです。使用方法は以下の通りです。
from discourse_reader import DiscourseClient
client = DiscourseClient("https://meta.discourse.org")
# カテゴリを閲覧
for cat in client.categories():
print(f"{cat.name}: {cat.topic_count} トピック")
# トピックとそのすべての投稿を取得
topic = client.topics.get(12345)
print(topic.title)
print(topic.opening_post.cooked) # 元の投稿（HTML）
print(topic.accepted_answer) # 承認された回答、または None
for reply in topic.posts.replies():
print(reply.username, reply.cooked)
pydiscourse ほど包括的ではありませんが、これは意図的なもので、API キーなしで動作するように設計されています。また、Data Explorer プラグインよりも優れたデータや高速なデータを提供するわけではありませんが、スレッドのバッチやシンプルなサイト統計を素早く取得したい場合には便利だと思います 
このアプローチは、このフォーラムの利用規約および Discourse フォーラムのデフォルトの利用規約に違反する可能性があるという印象を受けます。
フォーラムへのアクセスを自動化したり、ウェブクローラー、ブラウザプラグインやアドオン、またはウェブブラウザ以外の他のコンピュータプログラムを使用してフォーラムを監視したりすることはできません。ただし、公開されている検索エンジンを実行している場合は、その検索エンジン用にフォーラムをクロールしてインデックス化することは可能です。
うーん、特別なことをしているわけではなく、単に公開されている API エンドポイントに対する単純な curl リクエストをラップしているだけだと思います。しかし、もし @Discourse チームが私が作成したものに不快感を抱いているようでしたら、お知らせください。
個人的には、このパッケージ自体が利用規約（ToS）に違反しているとは思いません。なぜなら、フォーラムの利用規約を尊重する責任は常に、そのツールを使用する開発者にあるからです。このパッケージは公開され、文書化された API エンドポイントにのみアクセスします。もし開発者がフォーラムをスクレイピングしたり監視したりする悪意を持っているなら、それはもともと非常に簡単な作業です。
その点で、pydiscourse も同様の機能を提供しています。違いは API キーが必要かどうかだけです（一般ユーザーにとってこれがどれほど容易かはわかりませんが）、その後、同様に任意のフォーラムの利用規約を違反する目的で使用できます。つまり、フォーラムへの自動アクセスをデフォルトで禁止するルールがあるなら、pydiscourse や discourse2 も利用規約に違反することになりませんか？discourse2 は、API キーが提供されない場合でも、公開されているデータへのアクセスを機能リストで宣伝しています：
サーバー環境とブラウザ環境の両方で動作します>（> API キーなしで公開データをクエリしたり、関連するオリジン（例：最新のトピックなど）で利用するのに役立ちます）
おそらく、他の言語でも同様のアクセスをサポートするパッケージが他にも多数存在するでしょう。
いくつかの補足：このツールは、顧客がホストしているフォーラムからデータを簡単に取得できるようにするために作成しました（ただし、直接データベースへのアクセス権はありません）。これで私のワークフローが整理され、同じ状況にある他の人々も支援できることを願っています。
実際には、API キーを生成するにはまず管理インターフェース（管理 > 高度な設定 > API キー）へのアクセスが必要です。したがって、API キーを発行するのは、管理者が「意図的に行う」行為であり、一般ユーザーが自由に取得できるものではありません。
はい、API キーを取得する唯一の方法が管理インターフェースからである場合、このパッケージは特定のフォーラムの利用規約違反を容易にしてしまう可能性があります。
それでも、私が以前述べた他の点についても議論したいと考えています。また、それらに対する他の人々の意見も聞きたいです。具体的には、curl や requests を使えば、誰でも既に簡単にスクレイピングや監視が可能です。利用規約を違反しない責任は、その開発者にあるべきではないでしょうか？それとも、彼らが使用するツール自体にその責任があるべきなのでしょうか？
discourse2 や同様のパッケージはより広範な用途を想定していますが、discourse2 は API キーが提供されない場合でも公開エンドポイントで動作する能力を宣伝しています。これによって、利用規約違反が同程度の程度で可能になってしまうのでしょうか？
また、Discourse は GPLv2 でライセンスされているため、discourse-reader のようなツールの作成は、直接的に何らかの規約違反を内包するのでしょうか？
これらの点について、他の人々の意見を聞かせてほしいです。
公式の discourse_api Ruby ギムも、API キーなしでパブリックデータへのアクセスをサポートしています。したがって、このようなツールが存在することは問題ないと思います。ただし、利用者が各フォーラム固有の利用規約（ToS）を遵守しているかどうかは、ユーザー自身の責任となります。
（これは個人的な意見であり、CDCK の公式な法的声明ではありません 
）
また、認証されていないボットリクエストは、はるかに厳格なレート制限の対象となり、さらに他のボット保護セキュリティ層（例：Cloudflare）の影響を受ける可能性がある点にも注意が必要です。可能であれば、常に API キーを使用することをお勧めします。
ご返信ありがとうございます！当面の間、私のパッケージの README を更新し、開発者がこのツールをどのサイトに対しても使用する場合でも、そのサイトの利用規約（ToS）を尊重するよう免責事項を追記しました。
このツールを作成する際、このデフォルトの利用規約のルールについては全く知りませんでした。今後、このパッケージを利用しようとする方々が、同じくこの点について学んでくれることを願っています
ええ、これはまさに以前に VCR について行われた議論をそのまま反映しています。同様に、鍵開けツールもそうです。ツールには正当な用途と不正な用途の両方が存在し、責任を負うのは操作者です。
繰り返しになりますが、私は弁護士ではなく、これは公式の見解ではありませんが、私たちの立場は以下のように正確に表現されていると感じます。
ツールを用いた善意の探索（例）と、自動化を設定することには大きな違いがあります。
データの大規模なスクレイピングを行ったり、過度な負荷をかけたり、他者の体験を損なったりしない限り、そのようなツールを使って meta を利用することに対して私たちは厳しくなることはありません。特に、機能開発や Discourse API との連携方法を学んでいる方については、むしろ推奨します。