ありがとうございます。
Discourse のインスタンスを複数実行し、その上に（Discourse ではない）全体的な管理/調整システムをバックグラウンドで実行することを想定しています。トピックは次の 2 つの方法のいずれかで Discourse に追加されます。ユーザーが通常の Discourse トピック作成メカニズムを通じて追加するか、管理/調整システムが API を介して追加します。
API を介してトピックが作成される場合、通常はタスクまたは同様のワークフロー項目を表し、既に独自の非 Discourse ID があります。これを「外部 ID」と呼びましょう。
ユーザーが Discourse 内でトピックを作成する場合、Webhook をトリガーして Azure 関数を作成し、中央システム内にスタブのようなクローンを作成します（これにより、Discourse メッセージがコンテンツ、タスクなどのより広いストリームに接続されます）。したがって、ここでも Discourse トピックは間接的に一意の「外部 ID」を持つことになります。これを API を介してトピックに更新することを提案します。
各トピックがロードされると、Ajax を使用して中央システムから非 Discourse 中心の情報を取得し、トピック画面に表示するカスタム Discourse テーマコンポーネントがあります。
Discourse トピック ID を使用して Ajax 呼び出しのパラメータを設定し、一致するデータを見つけることもできますが、それを行うために「外部 ID」を使用する方が効率的です（ルックアップなどを回避するなど、複数の理由でよりクリーンです）。
「外部 ID」をカスタムフィールドに簡単に保存できます。他のデータ用に既に 1 つ持っています。しかし、Topics API には、まさに必要としているように見える「external_id」フィールドがあり、さまざまな理由でそれを使用したいと考えています。このやや重要なフィールドをレポート、エクスポート、将来の検索などに組み込みやすくなります。
Discourse API Docs のスクリーンショットを参照してください。
これはかなり新しいフィールドだと思います。フォーラムでのアドバイスのほとんどは、現在必要としているものではない User external_id フィールドに関連しています。上記のように、トピックの Ember モデルを取得し（カスタムテーマコンポーネント内で）、それを通じてトピックに関するほぼすべての情報を取得できます…ただし、external_id フィールドは取得できません。
（上記と同様に、このサイトのどこかから借用したこのコードを使用してトピックを取得しています。現時点ではどこにあるかはわかりません。
const topicController = api.container.lookup("controller:topic");
if (topicController) {
const thisTopic = topicController.get("model");
したがって、リクエストは、トピック固有の external_id フィールドがモデル（「thisTopic」）のどこかに埋め込まれているか、それともこれらの概念を誤解しており、カスタムフィールドを使用してこの外部 ID を保存すべきか（そのアプローチが機能すること、そしてどのように機能するかはわかっています！…単に、それが利用可能であれば、その明確さと将来性のある使用を好みます）ということです。
繰り返しになりますが、助けてくれてありがとう、感謝しています！