Discourse API を使用してユーザーオブジェクトを取得すると正常に動作しますが、external_id が含まれていません。Discourse のユーザー ID またはユーザー名が分かっている場合、そこから external_id を取得するにはどうすればよいですか？
なるほど、私は /users/blake.erickson.json（/admin なし）を呼び出していましたが、これでもユーザーオブジェクトが返却されます。ただし、single_sign_on_record は含まれません。
なぜ /users/ エンドポイントではユーザー名のみを指定できるのに、Discourse ID でユーザーを取得したい場合は /admin/users/:id.json になるのでしょうか？単に API デザインの気まぐれでしょうか？
さらに奇妙なことに、/users/by-external/:id.json を呼び出して外部 ID でユーザーを取得すると、single_sign_on_record が返ってきません。
つまり、API にはいくつかの癖があるようです。ユーザーオブジェクトに single_sign_on_record のプロパティが含まれる場合と含まれない場合があります 
設計上、管理用エンドポイントは、非管理用エンドポイントよりも多くのデータを返すように設計されています。はい、どちらも「user」レコードを取得していますが、一般ユーザーが呼び出せる /user/... エンドポイントが /admin/user/... と同じデータを返すのは、非常に問題があります。
ああ、/user エンドポイントが一般ユーザーにも利用可能だとは知りませんでした。ユーザー API キーという概念があることを忘れていました。
不整合に戸惑うことが続いています。現在、single_sign_on_record を取得するには Discourse のユーザー ID を知る必要があります（/admin/users/:username.json は機能しません）… しかし、他の多くの API 呼び出しはユーザー名を必要とするようです（例：/users/:username.json）。
さらに、非常に似ていてほぼ同じに見えるが異なる結果を返す別々の API エンドポイントもあります。例えば、/admin/users はユーザーの single_sign_on_record データを返しますが、単に /users/ を呼び出すと返ってきません。
これらはすべて大した問題ではありません。私は試行錯誤しながら理解しています… 進捗が進んだら、ドキュメントを少し修正して、これらの点をより明確にできないか検討してみようと思います。
ここで区別が生まれるのは、エンドポイントが UI 内のページをレンダリングするために必要なデータを返すからです。こちらをご覧ください：
もちろん、その気持ちよくわかります。私もそのテクニックを使って、すべての XHR リクエストを監視していました。問題はありません。ただ…一貫性がないんです。 でも、Discourse がこれほど強力な API を持っていることに、心から感謝しています！