コードから発信。同じ流れを、プログラムで。
ダッシュボードの操作はすべてRESTエンドポイントです。公開、予約、アカウント、分析、Webhook。公式のTypeScript SDK。Claude Desktop、Cursor、ChatGPT向けのMCPサーバー。ワークスペースごとにスコープを絞ったAPIキーで、何も漏れません。
3行のコードで、3つのプラットフォームに予約投稿。
公開呼び出しの実際の形です。ワークスペースを選び、キャプションとプラットフォームを渡すと、投稿IDとプラットフォームごとの配信状況が返ります。TypeScript、PHP、curlのどれからでも同じ呼び出しです。
/v1/postsimport { FoPost } from '@fopost/sdk';
const client = new FoPost({ apiKey: process.env.FOPOST_API_KEY });
const accounts = await client.accounts.list({ workspaceId });
const post = await client.posts.create({
workspaceId,
status: 'scheduled',
scheduleAt: '2026-09-01T09:00:00Z',
content: [{ text: 'Stop launching on Tuesday.', position: 0 }],
accounts: accounts.map((a) => ({ id: a.id })),
});pst_01H7K3MRGB8YZ4QVWTwitter連携は作れた。そこへLinkedInがすべてを変えた。
Twitterへの公開は週末で作れました。ところがLinkedInに3日、OAuthフローに1週間かかり、Instagramは世界一扱いにくいAPIで、TikTokにはまだ手も付けていません。
どのプラットフォームも同じ日に違う形で壊れます。Blueskyのレート制限が変わり、Threadsがメディア形式の制限を追加し、HashnodeがGraphQLのバージョンを切り替える。プロダクトを作っている最中に、連携が燃えています。
5つのプラットフォームのOAuthを自前で実装し、リフレッシュトークンを自社のDBに保存しています。これでトークンの更新、暗号化保存、SOC 2並みの鍵管理まで自分の責任です。やりたかったビジネスはこれではないはずです。
APIが向いているのは？
こんな方におすすめ
- ユーザーに代わってソーシャルに公開する必要があるプロダクトを作っている
- CI、CRM、自社のバックエンドから動くコンテンツ運用のパイプラインを回している
- MCPでFoPostをClaude Desktop、Cursor、ChatGPTにつなぎ、エージェントに公開を任せたい
- 代理店向けツールを作っていて、33のプラットフォーム連携を管理せずにクライアントへソーシャル公開機能を提供したい
こんな方には不向き
- ダッシュボードから手作業でしか投稿しない。APIは過剰で、エディターが最適です。
- 完全なホワイトラベルのAPIホスティング（your-brand.api.com）が必要。エンタープライズ契約についてご相談ください。
APIは1つ。プラットフォームは32。障害対応は私たちが引き受けます。
書くのは1つのスキーマだけ。32のプラットフォームへの展開、トークンの更新、レート制限への対応、投稿の配信、エラーの通知は私たちが行います。機能のリリースに集中できます。
シンプルで予測しやすいREST
予測しやすいリソース（posts、accounts、workspaces、deliveries、webhooks）。すべてのエンドポイントで一貫したリクエストとレスポンスの形を、/v1でバージョン管理しています。
TypeScript SDKと、単体で使えるPHPライブラリ
TypeScript（npm install @fopost/sdk）はこのREST APIをラップします。PHP（composer require fopost/social-core、MITライセンス）は単体で動作し、自分の認証情報で11のプラットフォームに直接公開できます。FoPostのアカウントは不要です。
AIアシスタント向けMCPサーバー
npx -y @fopost/mcpで、FoPostのワークスペースをClaude Desktop、Cursor、ChatGPT、その他MCP対応のエージェントに接続できます。使えるツールは14種類：公開、予約、分析、アカウント管理。認証はAPIキーで行います。
ワークスペースごとのスコープ付きキー
ワークスペースごとのキーに操作スコープを設定：posts、accounts、workspaces、labels、publish、deliveries、webhooks、analytics、automations。UIはJWT、コードはAPIキー。代理店全体のスーパーキーはありません。
すべてのイベントに送信Webhook
publish.success、publish.failed、account.disconnected、account.reconnected、automation.triggeredなどを購読できます。すべてのペイロードに署名があるので私たちから届いたものか検証でき、配信に失敗した場合は指数バックオフで再試行されます。
実務に見合ったレート制限
上限は公開連携に必要な量を大きく上回り、接続アカウントが増えるほど自動的に引き上げられます。超えた場合も、黙って捨てられたりキーが停止されたりせず、バックオフの目安となるRetry-After付きの429がきちんと返ります。
生成。インストール。公開。
APIキーを生成
公開に使うワークスペースで、必要なスコープを付けたAPIキーを作成します（最初はpostsとaccountsで十分です）。コピーできるのは一度だけ。秘密情報として扱ってください。
SDKをインストール
npm install @fopost/sdk。SDKを使わずにRESTエンドポイントを直接呼ぶことも、どちらも使わずにClaudeからMCPサーバーを使うこともできます。
呼び出す
import、インスタンス化、作成の3行です。公開呼び出しは投稿IDとプラットフォームごとの配信状況を返します。投稿はダッシュボードのキューに入り、予約した時刻に公開されます。
Webhookを購読（任意）
ワークスペース設定でWebhook URLを追加し、publish.successとpublish.failedを購読します。各配信が成功または失敗するたびに、エンドポイントに署名付きのPOSTが届きます。これでシステムが常に同期されます。
33のプラットフォーム連携を自前で作るより優れている理由。
開発者がいまマルチプラットフォーム公開に取り組む3つの方法。SDKとMCPサーバーを備え、障害対応を他者が引き受ける本物のAPIは、そのうちひとつだけです。
自作：33のプラットフォームAPIを自分で
技術系の起業家が挑むこと
- プラットフォームごとのOAuthフロー。トークンの保存。トークンの更新。秘密情報の暗号化管理。
- プラットフォームごとに異なるレート制限、異なるエラー形式、異なるメディア制約。
- LinkedInがAPIを変えれば、コードを直すのは自分。Bluesky、Threads、Hashnodeも同じです。
- TwitterとLinkedInの後はプラットフォームが増えません。残りの29は希望リストのままです。
BufferやHootsuiteのAPI
既存大手が提供しているもの
- 公開APIはあるものの、後付け感があります。SDKはコミュニティ頼みで、あったりなかったり。
- MCPサーバーはありません。ClaudeやCursorにつなぐには独自の連携が必要です。
- シート単位の料金のため、代理店にとってAPIはコストの塊になります。
FoPostのAPI + SDK + MCP
本当に求めているもの
- 1つのRESTスキーマで32のプラットフォームに対応。書き込みAPIのないSubstackはブラウザ拡張機能でカバーします。
- 私たちが保守するTypeScript SDKと、MITライセンスのPHPライブラリ。
- MCPサーバーは提供中：npx -y @fopost/mcpでClaude Desktop、Cursor、ChatGPTへ。
- ワークスペース単位のスコープ付きキー、署名付きWebhook、再試行を標準搭載。障害対応は私たちが引き受けます。
主要なネットワークすべてに公開