【2026年版】X アーティクル API：X の長文投稿のコンテンツを取得する

著者：Sorsa Editorial

2026年7月8日更新：記事取得の料金を1,000件あたりのレートで捉え直し、100回分の無料リクエストのスターター枠を追加し、公式 X API の比較を記事アクセスの能力に絞りました。

要点 X アーティクルは、カバー画像と豊かな書式を持つ、最大でおよそ100,000文字を保持する X 上の長文の投稿です。公式 X API は本文ではなく t.co のラッパーだけを公開します。完全なテキスト、カバー画像、公開日、そしてエンゲージメント指標を取得するには、1回の専用の REST 呼び出しが必要です。

代替の Twitter/X API プロバイダーである Sorsa API は、完全な記事オブジェクトを単一のリクエストで JSON として返す専用の POST /v3/article エンドポイントでそのギャップを埋めます。本文のテキスト、カバー画像、公開日、そしてすべてのエンゲージメント指標を、OAuth なし、アプリのレビューなし、そしてヘッドレスブラウザなしで返します。各取得は1回のフラットなリクエストで、1,000記事あたり$1.80から、すべてのプランに適用される毎秒20リクエストの制限です。新しいキーは100回分の無料リクエストを含み、クレジットカード不要なので、エンドポイントはどの支出の前にもテストできます。

X が2026年1月にアーティクルをすべての Premium 加入者に開いて以来、より多くのジャーナリスト、アナリスト、そしてプロジェクトのチームが、Medium や Substack ではなくネイティブに長文のコンテンツを公開しています。監視や分析を構築する誰にとっても落とし穴は、公式 X API がアーティクルのオブジェクトを軸に設計されたことがないため、標準のツイートの検索が短いリンクとそれ以外は何も返さないことです。本ガイドは X アーティクル API を扱うための実用的なリファレンスです。形式が何か、なぜ公式のエンドポイントがそれを返せないか、そして1回の REST 呼び出しで記事の完全な本文、メタデータ、そして指標を引く方法を、検出、競合のベンチマーク、そしてコンテンツ分析のための実行可能な Python とともにカバーします。

目次

• X アーティクルとは？
• なぜ公式 X API は記事のコンテンツを返さないか
• X アーティクル 対 ロングポスト 対 スレッド
• X アーティクルへのプログラムによるアクセスが必要なとき
• X アーティクルを取得する：エンドポイント
• 投稿が X アーティクルかどうかを検出する
• 競合のアーティクルをベンチマークする
• NLP で記事のコンテンツを分析する
• 料金とレート制限
• よくある質問

X アーティクルとは？ {#what-are-x-articles}

X アーティクルは X（旧Twitter）上のネイティブの長文の公開の形式で、対象のアカウントが最大でおよそ100,000文字の書式付きの作品を投稿できるようにするもので、280文字のツイートの制限をはるかに超えます。各アーティクルは、カバー画像、タイトル、見出しとリストのある本文のテキスト、埋め込みメディア、そしてそれ自身の公開日を持ち、作者のプロフィールの専用のアーティクルのタブの下に現れます。

X は2024年3月8日に、当初は Premium+ の加入者と認証済みの組織のためにアーティクルをローンチしました。Engadget によれば、上限はおよそ100,000文字に達し、別のロングポストの機能の25,000に対してです。2026年1月7日、X のプロダクト責任者 Nikita Bier が、この機能のすべての Premium 加入者への拡大を発表し、Premium+ の独占を終わらせました。Social Media Today が報じたところによれば、X はこの推進を、2026年1月下旬の支払い期間のトップの長文アーティクルへの1回限りの$1 million（100万ドル）の賞金と組み合わせ、少なくとも1,000語のオリジナルの作品を投稿する US の Premium ユーザーに開かれ、主に Verified Home Timeline のインプレッションで判断されました。

この形式に対して構築するとき、いくつかの性質が重要です。

• アーティクルは、通常のツイートと異なるパターン、特により高いブックマーク率とより低いリツイート率を持つ、それ自身のエンゲージメントのオブジェクトを運びます。
• アーティクルにリンクする告知の投稿は依然として通常のツイートで、記事の本文は別のオブジェクトに住みます。
• アーティクルの公開日は、告知ツイートの created_at とは別です。

なぜ公式 X API は記事のコンテンツを返さないか {#why-the-official-x-api-doesnt-return-article-content}

公式 X API はアーティクルの本文を公開しません。作者がアーティクルを公開すると、X はそれにリンクする告知ツイートを作り、標準のツイートの検索は、記事のコンテンツではなく t.co の短いリンクを含むそのツイートのテキストだけを返します。リンクをたどると、JSON のエンドポイントではなく x.com/i/article/{id} のレンダリングされた web ページにリダイレクトするため、本文、カバー画像、そして公開日は、通常の投稿読み取りの呼び出しを通じては手の届かないままです。

告知ツイートの標準の v2 の検索は、このようなものを返します。

{
  "data": {
    "id": "1234567890",
    "text": "Just published a new piece on the state of crypto Twitter in 2026 https://t.co/XYZ123",
    "edit_history_tweet_ids": ["1234567890"]
  }
}

その t.co のリンクがペイロード全体です。本文も、カバー画像も、公開日もありません。

note_tweet フィールドはこれを解決しません。それは25,000文字のロングポストのために追加された、別の機能です。書式なし、カバー画像なし、別の公開日なしの単一のテキストのかたまりで、上限はアーティクルの制限をはるかに下回ります。note_tweet を読むとロングポストのテキストが得られ、アーティクルのコンテンツはけっして得られません。

チームが手を伸ばす回避策はすべてブラウザ自動化を伴います。認証された Cookie でヘッドレスブラウザをレンダリングされた記事のページに走らせ、DOM をスクレイプするのです。それは一度きりには持ちこたえますが、本番のパイプラインとしては常設の税です。ブラウザのクラスターを動かし、Cookie が期限切れになる前にローテーションし、チャレンジを扱い、レイテンシーがミリ秒から秒に上るのを見ます。これがまさに、チームを Twitter API の代替を探しに行かせるギャップです。データは公開で、アクセスのパターンは REST 呼び出しであるべきなのに、公式 API は依然としてブラウザに手を伸ばさせます。

特に記事の取得には、実用的な比較は呼び出しあたりの価格についてより、そもそも本文が到達可能かどうかについてです。以下の表は、直接の記事のエンドポイントを公開する読み取り専用の X データ API を、公式 X API と対比します。

アーティクルを公開したり X に書き込んだりする必要があるなら、それが公式 API の領域です。読み取り専用の X データ API は投稿しないからです。フラットで予測可能な価格でスクレイピングのスタックなしに記事のコンテンツを引くには、直接の記事のエンドポイントがより単純な道です。Sorsa API は当社の製品なので、表をベンダーの比較として読み、コミットする前に任意のプロバイダーを自分のワークロードに対してテストしてください。

X アーティクル 対 ロングポスト 対 スレッド {#x-articles-vs-long-posts-vs-threads}

X には3つの異なる長文のメカニズムがあり、混同しやすいものです。通常のツイートは280文字で上限です。ロングポスト（拡張された投稿と呼ばれることもある）は Premium 加入者に25,000文字に達し、API では note_tweet として現れます。X アーティクルは、見出し、太字と斜体のテキスト、リスト、埋め込みメディア、カバー画像、そして専用のプロフィールのタブを持つ、最大でおよそ100,000文字の別の形式です。

監視を構築する誰にとっての要点：通常のツイートとロングポストは注意点付きで標準の API を通じて到達可能ですが、アーティクルの本文はそうではないため、専用の取得の方法が必要です。

X アーティクルへのプログラムによるアクセスが必要なとき {#when-you-need-programmatic-access-to-x-articles}

告知ツイートだけでなくアーティクルのオブジェクトを取得する必要があるのは、長文の本文自体がデータであるときはいつでもです。よくあるケースは、競合のコンテンツインテリジェンス、特定の作者の持続的なアーカイブ、きれいな長文のテキストへの NLP、通常のツイートに対するエンゲージメントのベンチマーク、そしてアーティクルがスクレイピングの後付けではなくファーストクラスのソースであるメディアやジャーナリストの監視です。

競合のコンテンツインテリジェンス。 長文のアーティクルは、その短いツイートのストリームよりはるかに明確に企業のメッセージングの戦略を明らかにします。アーティクルは意図的で構造化されているからです。競合のアーティクルを毎週引いて差分を取ることは、低努力で高シグナルのループです。より広い 競合分析のワークフローと自然に組み合わさります。

アーカイブとコンテンツのデータベース。 チームが特定のアナリスト、トレーダー、または創業者に頼るなら、持続的なアーカイブが、投稿が編集、削除、または非表示にされても記録を守ります。full_text、published_at、そして作者のフィールドが、検索可能なストアに必要なすべてを与え、古い素材には 過去のツイートの取得で同じアプローチを拡張できます。

NLP の学習と分析。 アーティクルはプラットフォーム上で最もきれいな長文のテキストの1つです。書かれ、編集され、意図的に構造化され、それがノイズの多い短いツイートのストリームより感情の作業とトピックモデリングに適したものにします。より広いパターンは、感情とトピックの分析のガイドにあります。

エンゲージメントのベンチマーク。 アーティクルは、ツイートよりも高いブックマーク率と低いリツイート率に傾くため、通常の投稿に対してそれらをベンチマークすると数字を歪めます。アーティクルのオブジェクトを別々に引き、それらをそれ自身のクラスとして、ツイートレベルの分析にアプローチするのと同じ方法で分析します。

ジャーナリストと思想的リーダーの監視。 X が積極的に書き手を口説く中で、ジャーナリストはより頻繁にアーティクルに公開するため、メディア監視のツールは主要なソースとしてアーティクルの取り込みを必要とします。ウォッチリストからの新しいアーティクルの1分未満の検出には、アーキテクチャは リアルタイム監視に一致します。

X アーティクルを取得する：エンドポイント {#fetching-an-x-article-the-endpoint}

REST API を通じて X アーティクルを取得するには1回の呼び出しが必要です。告知ツイートの URL または数値の ID を記事のエンドポイントに送ると、応答が完全な本文のテキスト、プレビューのスニペット、カバー画像の URL、公開日、そしてエンゲージメントの数を JSON として返します。OAuth のハンドシェイクもブラウザのレンダリングも伴いません。認証はリクエストヘッダーの1つの API キーです。

Sorsa では、そのエンドポイントは POST /v3/article です。完全な仕様は 記事のエンドポイントのリファレンスにあります。

リクエスト

POST https://api.sorsa.io/v3/article
Content-Type: application/json
ApiKey: YOUR_API_KEY

{
  "tweet_link": "https://x.com/SorsaApp/status/1234567890"
}

tweet_link フィールドは、完全な告知ツイートの URL または単に数値のツイート ID を受け付けます。

応答（200）

{
  "full_text": "this isn't a cosmetic rebrand. it's a response to how crypto twitter actually works in 2026...",
  "preview_text": "this isn't a cosmetic rebrand. it's a response to how crypto twitter actually works in 2026...",
  "cover_image_url": "https://pbs.twimg.com/media/G-t2hYTaIAAstc8.jpg",
  "published_at": "2026-01-15T16:24:02Z",
  "likes_count": 315,
  "retweet_count": 41,
  "reply_count": 80,
  "quote_count": 37,
  "bookmark_count": 38,
  "views_count": 36538,
  "author": {
    "id": "1934538036466810880",
    "username": "SorsaApp",
    "display_name": "Sorsa",
    "followers_count": 6050,
    "verified": false
  }
}

パイプラインの端で扱う価値のあるフィールド名の注記が1つ：記事の応答は views_count を使い、一方標準のツイートのオブジェクトは view_count を使います。両方を同じコードに通すなら、キーを正規化します。完全な対応付けは 応答形式のリファレンスにあります。

クイックスタート

curl -X POST https://api.sorsa.io/v3/article \
  -H "ApiKey: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"tweet_link": "https://x.com/SorsaApp/status/1234567890"}'

import requests

API_KEY = "YOUR_API_KEY"
BASE_URL = "https://api.sorsa.io/v3"

def get_article(tweet_link: str) -> dict:
    """Fetch a single X Article by its announcement tweet URL or ID."""
    resp = requests.post(
        f"{BASE_URL}/article",
        headers={"ApiKey": API_KEY, "Content-Type": "application/json"},
        json={"tweet_link": tweet_link},
        timeout=30,
    )
    resp.raise_for_status()
    return resp.json()


if __name__ == "__main__":
    article = get_article("https://x.com/SorsaApp/status/1234567890")
    print(f"Author:      @{article['author']['username']}")
    print(f"Published:   {article['published_at']}")
    print(f"Views:       {article['views_count']:,}")
    print(f"Body length: {len(article['full_text']):,} chars")

開発者ポータルの承認も OAuth のダンスもありません。認証は1つのヘッダーです。新しいキーはダッシュボードから来て、クイックスタートガイドがセットアップを端から端までカバーします。

投稿が X アーティクルかどうかを検出する {#detecting-whether-a-post-is-an-x-article}

ライブのパイプラインでは、記事の URL のきれいなリストを持つことはめったにありません。あるのは投稿のストリームで、一部は通常で一部はアーティクルの告知ツイートです。告知ツイートは通常の x.com/{username}/status/{id} のパスに座るため、URL だけではそれを識別しません。信頼できるアプローチは、最初に記事のエンドポイントを試し、応答に実質的な本文がないときに標準のツイートの検索にフォールバックすることです。

import requests
from typing import Literal, TypedDict

API_KEY = "YOUR_API_KEY"
BASE_URL = "https://api.sorsa.io/v3"

class Content(TypedDict):
    type: Literal["article", "tweet"]
    data: dict

def get_content(tweet_link: str) -> Content:
    """Return an article object if the link is an Article, else the tweet."""
    headers = {"ApiKey": API_KEY, "Content-Type": "application/json"}

    try:
        resp = requests.post(
            f"{BASE_URL}/article",
            headers=headers,
            json={"tweet_link": tweet_link},
            timeout=30,
        )
        if resp.status_code == 200:
            article = resp.json()
            # Articles carry a substantial body. A short or missing
            # full_text means this was not an Article.
            if article.get("full_text") and len(article["full_text"]) > 500:
                return {"type": "article", "data": article}
    except requests.RequestException:
        pass

    resp = requests.post(
        f"{BASE_URL}/tweet-info",
        headers=headers,
        json={"tweet_link": tweet_link},
        timeout=30,
    )
    resp.raise_for_status()
    return {"type": "tweet", "data": resp.json()}

500文字のしきい値は実際によく機能します。より厳密にするには、cover_image_url または published_at、両方ともアーティクル固有のフィールドもチェックします。ここの単一投稿の検索は POST /v3/tweet-info で、標準のツイートのオブジェクトを返します。

競合のアーティクルをベンチマークする {#benchmarking-competitor-articles}

長文のアーティクルをベンチマークすることは、それぞれの指標を引いて表示あたりで正規化することを意味します。生の数はより大きなオーディエンスを持つアカウントに有利だからです。アーティクルに最も重要なシグナルは、1,000表示あたりのエンゲージメントと1,000表示あたりのブックマーク率です。ブックマークは後で読むための保存の意図を追跡し、それは深さと権威に相関し、通常のツイートではほとんど記録されません。

import requests
from dataclasses import dataclass
from datetime import datetime

API_KEY = "YOUR_API_KEY"
BASE_URL = "https://api.sorsa.io/v3"

@dataclass
class ArticleMetrics:
    author: str
    published_at: datetime
    views: int
    likes: int
    bookmarks: int
    replies: int
    retweets: int
    quotes: int
    body_length: int

    @property
    def engagement_rate(self) -> float:
        """Engagement events per 1,000 views."""
        if self.views == 0:
            return 0.0
        total = self.likes + self.bookmarks + self.replies + self.retweets + self.quotes
        return (total / self.views) * 1000

    @property
    def bookmark_rate(self) -> float:
        """Bookmarks per 1,000 views."""
        if self.views == 0:
            return 0.0
        return (self.bookmarks / self.views) * 1000


def fetch_article_metrics(tweet_link: str) -> ArticleMetrics:
    resp = requests.post(
        f"{BASE_URL}/article",
        headers={"ApiKey": API_KEY, "Content-Type": "application/json"},
        json={"tweet_link": tweet_link},
        timeout=30,
    )
    resp.raise_for_status()
    a = resp.json()
    return ArticleMetrics(
        author=a["author"]["username"],
        published_at=datetime.fromisoformat(a["published_at"].replace("Z", "+00:00")),
        views=a["views_count"],
        likes=a["likes_count"],
        bookmarks=a["bookmark_count"],
        replies=a["reply_count"],
        retweets=a["retweet_count"],
        quotes=a["quote_count"],
        body_length=len(a["full_text"]),
    )


def benchmark(article_links: list[str]) -> list[ArticleMetrics]:
    results = []
    for link in article_links:
        try:
            results.append(fetch_article_metrics(link))
        except requests.HTTPError as e:
            print(f"Skipping {link}: {e}")
    return sorted(results, key=lambda m: m.engagement_rate, reverse=True)

アーティクルの URL の入力のリストを構築することは別のステップです。各ウォッチリストのアカウントの最近の投稿をスキャンし、テキストが x.com/i/article への t.co のリンクだけであるものを保ちます。50の競合のアーティクルにわたるベンチマークは50リクエストで、エントリーのプランの十分内側にあり、それを毎週実行すると競合あたり月に数百リクエストかかります。バッチのパターンとカーソルの処理は、API 利用の最適化をご覧ください。

NLP で記事のコンテンツを分析する {#analyzing-article-content-with-nlp}

アーティクルの本文はテキストがきれいなので NLP によく適しています。書かれ、編集され、構造化され、短いツイートをモデル化しにくくするノイズがはるかに少ないのです。full_text をほとんど前処理なしで感情や要約のモデルにまっすぐ渡せます。取得と分析は別々のレイヤーです。記事のオブジェクトを取得し、それからその本文を、使う任意のモデルのプロバイダーに手渡します。

import os
import requests

SORSA_KEY = os.environ["SORSA_API_KEY"]

def fetch_article(tweet_link: str) -> dict:
    resp = requests.post(
        "https://api.sorsa.io/v3/article",
        headers={"ApiKey": SORSA_KEY, "Content-Type": "application/json"},
        json={"tweet_link": tweet_link},
        timeout=30,
    )
    resp.raise_for_status()
    return resp.json()


def build_prompt(article: dict) -> str:
    return (
        "Analyze this X Article. Return JSON with: sentiment "
        "(positive, negative, neutral, or mixed), main_topics (3 to 5 tags), "
        "and a 2 to 3 sentence neutral summary.\n\n"
        f"Body:\n{article['full_text']}"
    )

# Pass build_prompt(fetch_article(link)) to the model provider of your choice.

単一のキーが毎秒20リクエストを扱うため、取得がボトルネックになることはめったにありません。モデルのレイヤーがそうです。高いスループットには、まず記事を取得し、それからプロバイダーの並行性の制限に対して分析を並列化します。これは作者のウォッチリストにわたる毎日のジョブとしてよく機能します。

料金とレート制限 {#pricing-and-rate-limits}

記事の取得は1,000記事あたり$1.80から（最大のプランで各$0.0018）動作し、各取得は本文がどれだけ長くても月間の枠に対して1リクエストとして数えられます。文字単位の課金なし、カバー画像への追加料金なし、エンドポイントへの別のレート制限なしです。毎秒20リクエストの制限が一律に適用され、単一の記事の呼び出しがボトルネックになることはめったにありません。すべての新しいキーは、期限が切れず40個のエンドポイントすべてで動く、クレジットカード不要の100回分の無料リクエストで始まるため、記事のエンドポイントはプランを選ぶ前に試せます。

ほとんどのアカウントは週に1本未満のアーティクルを公開するため、200のウォッチリストの作者からすべてのアーティクルを毎週取得すると、月におよそ800〜2,000リクエストで、他のエンドポイントの余地とともに Starterプランの十分内側です。完全なプランの詳細は Sorsa API の料金の分解にあり、公式 X API とフラットレートのモデルにわたる呼び出しあたりの経済性は 現行の X API 料金ガイドで分解されています。既存の統合を移すなら、公式 X API からの移行の道がエンドポイントと認証の変更を対応付けます。

B2B SaaS の競合インテリジェンスのチーム、約10人は、およそ150〜200の競合とアナリストのアカウントから長文のアーティクルを毎週追跡したがっていました。公式 X API では本文が単に到達不可能だったため、現実的な代替は、Cookie のローテーションとチャレンジの処理を伴うヘッドレスブラウザのスクレイピングのクラスターでした。直接の記事のエンドポイントへの切り替えは、そのジョブを月に数百から数千リクエストに変え、快適にエントリーのプランの内側で、生かし続けるスクレイピングのインフラなしでした。決め手は数%の改善ではありませんでした。REST 呼び出しであるべきだったデータのために、維持の面全体を取り除いたことでした。

始め方 {#getting-started}

ゼロから動く記事の取得への最も速い道：

1. API プレイグラウンドに記事のツイートの URL を貼り付けて、コードを書く前にブラウザで JSON の応答を見ます。
2. ダッシュボードから API キーを引き、上の curl の呼び出しを実行します。
3. Python の get_article 関数をノートブックに落として統合を確認し、それから本番のために 429 のリトライと永続化のレイヤーを加えます。

認証は1つの ApiKey ヘッダーで、セットアップは審査待ちなしで数分かかり、すべてのエンドポイントが同じ一律の毎秒20リクエストを共有します。新規アカウントは、期限が切れず40個のエンドポイントすべてをカバーする、クレジットカード不要の100回分の無料リクエストを含み、記事の取得はその後1,000記事あたり$1.80から動作し、読み取り API の残りと同じ枠から引くため、既存のワークフローにエンドポイントを加えるのに別の統合は要りません。

よくある質問 {#faq}

X アーティクルは公式 X API を通じて利用できる？

直接はできません。公式 X API に記事専用のエンドポイントはなく、アーティクルを告知するツイートはそのテキストのフィールドに t.co のリンクだけを含み、本文、カバー画像、または公開日はありません。note_tweet フィールドは25,000文字のロングポスト、別の機能をカバーします。記事の本文を取得するには、レンダリングされたページに対してブラウザ自動化を実行するか、記事のオブジェクトを解決するサードパーティの REST API を使います。

X アーティクルとロングポストの違いは何？

ロングポスト（拡張された投稿）は Premium 加入者向けの最大25,000文字のツイートで、「続きを表示」のボタンとともにインラインで現れ、別の公開日も、カバー画像も、書式もありません。X アーティクルは、見出し、太字と斜体のテキスト、リスト、埋め込みメディア、カバー画像、そしてプロフィールの専用のアーティクルのタブを持つ、最大でおよそ100,000文字の異なる形式です。アーティクルはツイートより Substack の投稿に近いです。

X アーティクルの完全なテキストをどう取得する？

告知ツイートの URL または数値の ID を記事のエンドポイントに送り、JSON の応答を読みます。Sorsa API では、POST /v3/article が完全な本文、プレビューのテキスト、カバー画像、公開日、そしてエンゲージメントの数を単一のリクエストで返し、1つの ApiKey ヘッダーで認証し、OAuth はありません。各呼び出しはプランの枠から1リクエストとして数えられます。

過去に公開された X アーティクルを取得できる？

はい、アーティクルが X 上でまだ公開されている限り。アーティクルは公開されると永続的な URL を持つため、どの過去のアーティクルもその告知ツイートの URL または ID で取得可能です。作者が後でアーティクルを削除すると、検索は not-found のエラーを返します。アーティクルを超えるより古いツイートのアーカイブには、専用の過去の取得のワークフローがアカウントの最初の投稿までページネーションします。

API 経由で X アーティクルのコンテンツを引くのにいくらかかる？

Sorsa API では、記事の取得は単一のリクエストで、1,000記事あたり$1.80から（最大のプランで各$0.0018）の料金で、本文がどれだけ長くても文字単位の追加料金はありません。すべての新しいキーは、期限が切れず40個のエンドポイントすべてで動く、クレジットカード不要の100回分の無料リクエストを含むため、エンドポイントはプランにコミットする前に試せます。週に数百のアーティクルを取得することは、他のエンドポイントのための枠を残してエントリーのプランに収まります。

取得する前に投稿が X アーティクルかどうかどうやって見分ける？

告知ツイートは通常の x.com/{username}/status/{id} のパスを使うため、URL だけでは信頼できるシグナルではありません。信頼できる方法は、最初に記事のエンドポイントを呼び、full_text が実質的なとき（500文字のしきい値がよく機能します）のみ結果をアーティクルとして扱うことです。短いまたは欠けた本文は、それが通常の投稿だったことを意味します。cover_image_url または published_at の存在がそれを確認します。

監修：Keksich（Sorsa創業者、マーケター兼X APIリサーチャー）

本ガイドは、Sorsa の /article エンドポイントを本番で運用する実地の作業、フィールドとパラメータの名前のための現行の Sorsa API v3 のリファレンス、そしてエンドポイント自体のライブの応答の形に基づいています。機能のタイムラインと賞金の詳細は、2024年3月のローンチとおよそ100,000文字の制限に関する Engadget の報道と、2026年1月の Premium の拡大と$1 million（100万ドル）のアーティクルのコンテストに関する Social Media Today の報道に対して確認しました。エンドポイントの能力と料金は Sorsa の公表されたプランを反映します。2026年7月8日確認。