Glossia
OpenAPI ドキュメント完備
完全な OpenAPI 3.1 仕様に基づき、Scalar を介してインタラクティブなドキュメントを提供します。単一の仕様ファイルからエンドポイントの確認、リクエストの試行、クライアントコードの生成が可能です。
PKCE 対応 OAuth 2.1
動的クライアント登録、PKCE を使用した認可コードフロー、トークンイントロスペクション、失効処理に対応しています。サードパーティークライアントは、シークレットを共有することなく安全に認証できます。
ページネーションとフィルタリング
すべての一覧エンドポイントで、ページ単位のページネーション、フィールドフィルタリング、並べ替えを標準でサポートしています。予測可能なレスポンスメタデータにより、クライアントを容易に構築できます。
開発者を第一に
REST APIはGlossiaの中核です。ダッシュボード、CLI、MCPサーバーは、すべて同じエンドポイントを使用します。新しい機能はまずAPIに追加され、そこから他のすべての機能領域に反映されます。
そのため、UIの制約を受けることはありません。継続的インテグレーションおよび継続的デリバリーとの連携からカスタムダッシュボードまで、想定するあらゆるワークフローを、同じ安定した文書化済みインターフェース上に構築できます。
認証
Glossiaは、すべてのAPI認証にProof Key for Code Exchange（PKCE）を使用するOAuth 2.1を採用しています。このフローは、ファーストパーティおよびサードパーティの両方のクライアントに対応しています。手順全体については、認証および認可のドキュメントを参照してください。
動的クライアント登録：クライアントは、リダイレクトURIとグラントタイプを指定し、/oauth/registerでプログラムから登録します。手動の承認手順や、操作が必要なポータルはありません。
PKCEを使用した認可コード：ユーザーは、ブラウザ上の同意画面を通じてクライアントを認可します。PKCE拡張により、シークレットを保存できないパブリッククライアントでも、トークンの安全性が確保されます。
トークンのライフサイクル：標準のOAuthエンドポイントを通じて、アクセストークンの交換、イントロスペクション、失効が可能です。トークンエンドポイントのレート制限により、総当たり攻撃を防止します。
認可
アクセス制御には2つの層があります。スコープ、ロール、詳細な権限マトリクスについては、認証ドキュメントを参照してください。
スコープは、トークンがアクセスできるリソースのカテゴリを定義します。voice:readを持つトークンはボイス設定を読み取れますが、変更はできません。スコープはresource:actionパターンに従います。たとえば、用語管理にはaccount:read、organization:write、glossary:adminを使用します。
ポリシーは、ユーザーと特定のリソースとの関係を検証します。適切なスコープを持つ有効なトークンでも、ユーザーが所属していない組織にはアクセスできません。すべてのリクエストが両方の層で検証されます。
ページネーション、フィルタリング、並べ替え
すべての一覧エンドポイントは、一貫したメタデータを含むページネーション済みの結果を返します。
すべてのレスポンスにtotal_count、total_pages、current_page、page_size、has_next_page?、has_previous_page?が含まれるため、クライアントは推測に頼らずページネーションコントロールを構築できます。
filters[field]=valueクエリパラメーターを使用して、インデックスが設定された任意のフィールドで絞り込めます。order_by[]パラメーターを使用して、昇順または降順に並べ替えられます。すべてのリソースで同じインターフェースを使用します。
OpenAPIと対話型ドキュメント
完全なOpenAPI 3.1仕様は/api/openapi.jsonで提供されています。対話型APIリファレンスはScalarを使用しており、ブラウザから直接エンドポイントの確認、スキーマの検査、テストリクエストの送信ができます。
仕様から任意の言語向けクライアントライブラリを生成できます。APIコントラクトはバージョン管理され、安定性が維持されるため、新機能のリリースによって連携機能が動作しなくなることはありません。