Tweet by ID API: Get Any Tweet as JSON for $0.0008

The endpoint that resolves a tweet ID

You can pass either form of the identifier, so a link a user pasted into your product works without you parsing it first. Send id when you already hold the number, or url when you only have the link, and leave the other one out. The table comes straight from our OpenAPI document.

Sample response from GET /twitter/tweet/detail

The object below is the example published in the spec. Real responses also carry the attached media and any quoted tweet when the post has them. Call it again later and compare the counters to build a growth curve for one post.

{
  "id": "1759123456789012345",
  "tweet": {
    "id": "1759123456789012345",
    "text": "Shipping the new docs today.",
    "created_at": "Tue Feb 20 14:02:11 +0000 2026",
    "author": {
      "id": "745273",
      "username": "naval",
      "name": "Naval"
    },
    "favorite_count": 4821,
    "retweet_count": 612,
    "reply_count": 88,
    "quote_count": 14,
    "bookmark_count": 203,
    "view_count": 219340
  }
}

Start using the X API: fetch one tweet by ID

A read needs no X account of your own, so there is nothing to register. Public tweets are not attributed to anybody, which means a key is the only credential involved and you can run the call below straight after signing up.

1. Create a key at signup. There is no approval step and no card.
2. Copy a tweet ID from the end of a status URL, or pass the whole URL in the url parameter.
3. Send the request below. Parse the response with the ID kept as a string so a 19 digit number survives.

curl "https://api.twitterapis.com/twitter/tweet/detail?id=1759123456789012345" \
  -H "Authorization: Bearer $TWITTERAPIS_KEY"

import os
import requests

resp = requests.get(
    "https://api.twitterapis.com/twitter/tweet/detail",
    headers={"Authorization": f"Bearer {os.environ['TWITTERAPIS_KEY']}"},
    params={"id": "1759123456789012345"},
)
resp.raise_for_status()
data = resp.json()
print(data)

const url = new URL("https://api.twitterapis.com/twitter/tweet/detail");
url.search = new URLSearchParams({ id: "1759123456789012345" }).toString();
const resp = await fetch(url, {
  headers: { Authorization: `Bearer ${process.env.TWITTERAPIS_KEY}` },
});
const data = await resp.json();
console.log(data);

What a tweet lookup costs at real fill

Most read endpoints quote a best-case page price and leave you to discover the real yield. This one has none of that gap, because a successful call returns one tweet every time. The table shows what a workload costs at the fill it will actually see.

Calculated from the biller's per-call rate. The signup credit of $0.50 covers 625 lookups. To read a whole conversation, the thread route returns it in one call instead of many lookups.

Ways to get a tweet by ID compared

A single lookup looks trivial until you do it at volume or need the counters. The options below differ mostly in what they return and in how much maintenance they ask of you, so weigh the fields you need before weighing the price.

How a per-tweet price compares for single lookups

On a one-tweet lookup, a per-item tariff comes out lower than our flat call price. twitterapi.io bills Tweet details by ID at $0.00015 per tweet returned, with the same $0.00015 as a minimum per call, and its endpoint takes up to 50 IDs per request, per its published pricing details (pricing.json v2026-10-12, read 2026-11-05). If your workload is nothing but bulk ID lookups, that tariff costs less than this one.

Where this route earns its place is everything around the lookup. It takes a pasted status URL as well as an ID, so user input needs no parser. The same key covers search, timelines, followers, posting, follows and webhook monitoring, priced per call rather than per item, which keeps a mixed workload easy to forecast. And every route, this one included, is a tool in our MCP server, so an agent can resolve a link and act on it in one session.

• URL or ID. Pass url for whatever a user pasted, or id when you already hold the number.
• Reads and writes on one key. Look a post up here, then reply to it or follow its author without a second account.
• Agent access. The twitter_tweet_detail tool takes the same inputs, so Claude or Cursor can read a linked post directly.

What it does and what it does not do

This endpoint fits any workflow that starts from a known post rather than from a search. It is the second step after something else hands you an ID, and it turns that ID into a record you can store, rank or show to a user. It does not search, and it does not return a conversation or more than one tweet per call.

• Link previews. Render a clean card when a user pastes a tweet URL into your product, using the url parameter.
• Engagement tracking. Poll a list of tweets on a schedule and chart the counters. Our guide on tracking a tweet with an API shows the loop.
• Webhook enrichment. A webhook delivery tells you a post exists. A lookup adds the current counts before you store it.
• Space announcements. A post that links to a Space carries its ID, and the Twitter Spaces API turns that into a title, host and counts.
• Moderation queues. Re-fetch a reported post to see whether it is still up before a human spends time on it.

Tweet IDs and why they must stay strings

A tweet ID is a 64-bit number, usually 19 digits today. JavaScript stores numbers as 64-bit floats and only keeps integers exact up to 16 digits, so JSON.parse on a bare number silently rounds it and you end up asking for a different tweet. We return IDs as strings for that reason, and you should keep them that way in your database too.

The ID also encodes the time the post was created, because X generates IDs in time order. That means sorting by ID sorts by age, and you can compare two posts without reading their timestamps. It does not tell you anything about the author, which is a separate number: use the ID finder if you were looking for an account's ID rather than a post's.

Deleted, protected and missing tweets

A lookup returns public posts. If a post was deleted, or the ID never existed, the call comes back as a 404 and your code should treat that as a final state rather than a failure to retry. Treat a post from a protected account the same way.

That 404 is useful on its own. A monitoring job that re-fetches saved posts can mark the ones that disappeared, which is how brand teams notice a retraction. If you need the text of something already gone, read the guide on recovering a deleted tweet to see what is and is not possible.

Refreshing many tweets on a schedule

The common production pattern is a list of saved IDs and a job that refreshes their counters. A small thread pool is all it takes, because each lookup is independent and there is no cursor to keep. The example below fans out over a list of IDs, keeps the handful of counters most dashboards chart, and skips anything that returns a 404.

Stay inside the flat ceiling of 600 requests a minute and 20 concurrent per key, which still gives you 36,000 lookups an hour on one key. Back off on a 429 rather than retrying immediately. If you find yourself refreshing every post from one account, the timeline API returns many of them per call and works out far cheaper than single lookups. The rate limits page compares that ceiling with what X publishes.

import os
from concurrent.futures import ThreadPoolExecutor
import requests

API = "https://api.twitterapis.com/twitter/tweet/detail"
HEADERS = {"Authorization": f"Bearer {os.environ['TWITTERAPIS_KEY']}"}


def counters(tweet_id):
    resp = requests.get(API, headers=HEADERS, params={"id": tweet_id}, timeout=30)
    if resp.status_code == 404:
        return tweet_id, None
    resp.raise_for_status()
    tweet = resp.json()["tweet"]
    return tweet_id, {
        "likes": tweet["favorite_count"],
        "reposts": tweet["retweet_count"],
        "views": tweet["view_count"],
    }


ids = ["1759123456789012345"]
with ThreadPoolExecutor(max_workers=10) as pool:
    for tweet_id, row in pool.map(counters, ids):
        print(tweet_id, row)

Turning a lookup into an engagement rate

One response carries everything you need for the standard engagement metrics, so there is no second call to make for a per-post report. Add favorite_count, retweet_count, reply_count, quote_count and bookmark_count, then divide by view_count to get an engagement rate per impression. Using the example in the spec, that is 5,738 interactions on 219,340 views, or about 2.6 percent.

Compare a post against its author's recent average rather than against a global benchmark, because rates vary a lot with account size and topic. The Twitter analytics API page goes further into account-level metrics, and our guide to tracking tweet performance in real time shows how to sample a post at sensible intervals after it goes live.

• Replies. The count is on the object, and the replies guide shows how to read the text of each one.
• Quotes and retweeters. To see who shared a post, read our answer on quote tweets and retweeters.
• Writing back. If a lookup feeds a reply workflow, the post API publishes the response.
• Getting started. The quickstart covers the auth header and paging model that every route shares.

Passing a URL or an ID, and which to store

The url parameter is the easy path for input you do not control. People paste links with tracking parameters, old twitter.com domains and photo suffixes, and handing the whole string to the API saves you from maintaining a parser for each variant. Keep the id from the response as your stored key, because the numeric ID never changes while a handle in a URL can change whenever the author renames their account.

If you already parse links for another reason, the number after /status/ is all you need, and the snippet below pulls it out of any common form. Pass it through id on later refreshes, so every record in your database goes through one code path. Validate that the match is all digits before you send it, since a user can paste anything into a text box.

import re

STATUS_ID = re.compile(r"/status(?:es)?/(\d+)")


def tweet_id_from(link):
    match = STATUS_ID.search(link)
    return match.group(1) if match else None


print(tweet_id_from("https://x.com/naval/status/1759123456789012345?s=20"))

One key for every X endpoint

The key you use for a lookup is the same key for every other route, so moving from one tweet to a search or a follower list needs no new credential or plan. Per our OpenAPI document there are 125 endpoints behind that one Bearer key, split across 72 reads and 53 writes, and each bills from the same prepaid balance.

That matters for a lookup because it is rarely the only call in a workflow. A typical job finds posts with the search API, resolves each one here, and then reads the author with the user API. One key keeps that chain simple to build and to budget.

Public profile data on every tweet

Each response names the author, so you usually do not need a second call to attribute a post. tweet.author carries the numeric ID, the handle and the display name, which covers a byline, a link back to the account and a join against your own records. Store the numeric ID rather than the handle, since a handle can change.

When you need the rest of the public profile, such as the bio, follower count or join date, pass that ID to the Twitter user API as a separate read. Keep that call behind a cache if the same authors come up often, because a profile changes far more slowly than the counters on a post.

Look up tweets from an AI agent

Give an agent a URL and it can read the post without a browser. The MCP tool below takes the same id or url input as the REST call, which makes it handy for summarising a linked tweet inside a chat, and the MCP page has the client configs.

• twitter_tweet_detail calls GET /twitter/tweet/detail

npx -y @twitterapis/mcp@latest