ユーザーはあなたのプロダクトの中で何かを作り、それをどこか別の場所に投稿するために離れていきます。そのギャップを埋めることはよくある機能要望であり、その作業の形はほぼすべて、最初に下すひとつの決定にかかっています。
決定事項：それは誰のアカウントか
投稿先が自分自身のアカウントなら、APIキーで十分です。サーバー間通信で、同意フローもなく、もっとも単純です。
投稿先がユーザーのアカウントなら、OAuthが必要です。各ユーザーがあなたのアプリを認可し、あなたはユーザーが選んだワークスペースに紐づくスコープ付きのトークンを受け取ります。
これは最初に正しく決めてください。ユーザーにAPIキーの貼り付けを求めることから始めるプロダクトは、後になってOAuthへ移行することになり、その間にユーザーに双方にとって良くない習慣を教えてしまいます。長期間有効で広い権限を持つ認証情報をサードパーティのプロダクトに貼り付けるという習慣です。
本来なら構築することになっていたもの
プラットフォームを直接統合するのではなく公開用APIを使う理由は、直接統合がプラットフォームごとに終わりのないプロジェクトになるからです。
- プラットフォームごとに異なるスコープとトークン寿命を持つ、別々のOAuthフロー
- プラットフォームごとのリフレッシュジョブ。これは静かに失敗し、公開機能を道連れにする
- プラットフォームごとに異なるアップロードモデルを持つ、別々のメディアパイプライン
- いくつかのプラットフォームでの非同期公開。200が返っても公開されたとは限らない
- プラットフォームごとに異なるレート制限
- いくつかのプラットフォームでのアプリ審査。これはあなたがコントロールできないカレンダー上の時間であり、拒否されることもある
- 各プラットフォーム独自のスケジュールで発生し続ける破壊的変更
公開が製品そのものではなく一機能にすぎないSaaSにとって、それは差別化要因ではない何かに付随する恒久的な保守コミットメントです。
それでも構築するもの
公開用APIを使っても、すべての作業がなくなるわけではありません。以下は依然として必要です。
**接続用のUI。**ユーザーがアカウントを接続し、その接続の状態を確認できる場所です。
**目に見える破損状態。**接続は壊れます。ユーザーはそれを確認して直せる必要があり、それはあなたが飲み込んでしまうエラーではなく、プロダクト内の状態であるべきです。
**あなたのプロダクトの言葉での構成。**APIはコンテンツとチャンネルを受け取ります。ユーザーが実際に何をし、それがどう投稿にマッピングされるかは、あなた次第です。
**失敗の処理。**何かが公開に失敗することはあります。ユーザーがそれをあなたから知るのか、投稿が存在しないことから知るのかを今のうちに決めてください。
選定時に確認すべきこと
| 要件 | 理由 |
|---|---|
| 細かいスコープを持つOAuth | マルチユーザーのプロダクトには必須で、狭いスコープは被害範囲を限定する |
| プラットフォームの具体的なリスト | 「主要なネットワークすべて」ではなく |
| 作成時のバリデーション | 上限を超えたキャプションが、ユーザーに提示できる場所で失敗するように |
| あなたの階層でのレート制限 | あなたと一緒にスケールするかどうかを決める数字 |
| 構造化されたエラー | 「公開に失敗しました」ではなく、何か役立つものを表示できるように |
この点でのBulkPublish
- **認証：**ユーザーのアカウントに代わって操作する場合はOAuth 2.1、自分自身の場合はAPIキー
- **OAuthの詳細：**PKCE（S256）必須、
scope必須で暗黙のデフォルトなし、単回使用の認可コード、ローテーションするリフレッシュトークン、トークンはBearer bpat_...として渡される - スコープ：
posts:read、posts:write、media:read、media:write、analytics:read、channels:read、full - **範囲：**59のドキュメント化されたエンドポイント
- **プラットフォーム：**15
設計時に押さえておくべき境界がひとつあります。OAuthトークンが届くのは投稿、スケジュール、ラベル、メディア、分析、クォータ使用状況、読み取り専用のチャンネルデータまでです。アカウント管理、つまりチーム、組織、請求、クレジット購入、APIキー、OAuthアプリの管理は、fullを含むどのOAuthトークンに対しても403を返します。これらの操作は、ユーザーがあなたのアプリを切断した後も存続してしまうからです。それにはAPIキーが必要です。
これは本番環境で説明のつかない403として発見するより、今知っておくほうがいいことです。
| Free | Pro | Business | |
|---|---|---|---|
| APIリクエスト/日 | 30 | 5,000 | 50,000 |
| APIキー | 1 | 5 | 10 |
まとめ
まず、自分自身のアカウントに公開するのかユーザーのアカウントに公開するのかを決めてください。ユーザーのアカウントであれば、後で移行するのではなく初日からOAuthを使いましょう。プラットフォームを直接統合することは、あなたのプロダクトではない何かに対する恒久的な保守コミットメントであり、それでも構築が必要なのは、接続用のUI、目に見える破損状態、そして何かが失敗したときにユーザーに伝えることです。