ソーシャルメディア予約投稿APIは、別のシステムが準備したコンテンツをInstagram、Threads、Facebook Pages、Bluesky、TikTok、YouTubeなどの公開キューへ送れるようにするインターフェースです。

しかし実用的なAPIは POST /posts だけではありません。実際の予約投稿には、アカウント接続、権限、media rule、予約時刻、再試行、失敗理由、Webhook、状態照会が必要です。

短く言えば:

予約投稿APIは最初のリクエストではなく、公開作業のライフサイクルを管理するAPIです。

なぜ各SNS APIを直接呼ばないのか

対象が狭いなら、各SNSのネイティブAPIを直接呼ぶ選択もあります。1つのプラットフォームだけを扱い、保守を自分たちで持てるなら、それで十分な場合があります。

難しくなるのは複数チャネルを扱い始めたときです。

だから予約投稿APIはネイティブAPIの薄いwrapperではなく、繰り返し発生する運用作業を吸収する必要があります。

最小構成

実用的な予約投稿APIには、少なくとも次の要素が必要です。

これらがないと、APIは簡単に見えても運用の負担が人に戻ります。

予約投稿APIで最も重要なのは状態です。

accepted -> queued -> publishing -> published
                              -> failed

この区別がないと、「APIリクエスト成功」と「SNS投稿成功」を同じものと誤解しやすくなります。

CMS、AIツール、社内ダッシュボード、顧客システムが結果を知る必要がある場合、方法は主に2つです。

1つ目はpollingです。外部システムが何度も状態を問い合わせます。始めやすいですが、ノイズが多く結果に気づくのも遅くなりがちです。

2つ目はWebhookです。公開状態が変わったときにスケジューラーがイベントを送ります。

{
	"type": "content.publish.failed",
	"brandRef": "acme",
	"contentId": "cnt_123",
	"sns": "instagram",
	"reason": "MEDIA_VALIDATION_FAILED"
}

自動化は連鎖です。AIツールがコンテンツを作り、APIが作業を受け付け、スケジューラーが後で公開し、別システムが結果を見て次の処理を決めます。だからWebhookが必要になります。

Ankkは、SNS予約投稿を人間向けダッシュボードとCLI/API/Webhookが共有する1つの運用フローとして扱います。

ankk contents publish --brand-ref acme --file payload.json

このコマンドは「providerにもう投稿した」ではなく、「Ankkが公開作業を受け付けた」という意味で捉えるべきです。実際のprovider公開は後続の状態変化で確認します。

自動化の流れはAnkk CLI/API開発者ガイドで、API/Webhookの範囲は料金ページで確認できます。

予約投稿APIを比較するときは、次を確認してください。

APIアクセスは出発点です。運用上の問いは、そのAPIが公開ライフサイクルを信頼できるほど見せてくれるかです。