If you searched for a "TikTok Live API" and landed on a dozen marketing pages that promised real-time gifts, viewer counts, and live comment streams, you already know the space is noisy. The honest answer in 2026 is that TikTok Live data is one of the most fragmented surfaces on the platform: a small slice is officially exposed, a larger slice exists only inside TikTok's own apps, and the rest is approximated by third parties who scrape the public web.
This post maps the current landscape for developers, explains where TikLiveAPI does and does not fit, and shows the workarounds we actually recommend when a customer emails us asking how to track a Live session. We will also be direct about what we do not offer, so you can plan your stack with both eyes open.
What Live data even exists on TikTok
Before talking about endpoints, it helps to separate the kinds of data a Live stream produces. Conceptually there are five buckets:
- Stream metadata: the room ID, title, start time, language, region, the creator's user object, and whether the stream is currently online.
- Viewer counts: a live concurrent viewer number plus a cumulative "total viewers" tally that updates while the stream is on air.
- Live comments: the chat stream itself, one message per viewer, often arriving at several hundred messages per minute on a busy room.
- Gift transactions: virtual gifts viewers send, each with a gift ID, coin value, sender user object, and timestamp.
- Post-stream artifacts: replays, recap videos the creator publishes after the stream, and the follower delta the stream produced.
The first four buckets are real-time and exist primarily inside the TikTok app's WebSocket connection to the Live room. The fifth bucket lives in the regular TikTok feed and is fully public after the fact. That distinction is the single most important thing to understand about the Live landscape, because it tells you which parts of your use case can be served by a REST API at all.
What TikTok officially provides
TikTok's own developer surface for Live is narrower than most teams expect. As of 2026 the official pieces are:
TikTok Live Studio
A desktop app for creators that lets them stream from OBS-style sources directly into TikTok Live. It is a producer tool, not an API. There is no public REST or WebSocket interface that consumers can call.
TikTok Open API with Live Studio integration
The Open Platform lets developer apps integrate with Live Studio for things like overlays, alerts, and stream deck style automations. Crucially, this works through OAuth on a per-creator basis: the creator installs your app, grants scopes, and your app receives events for that one creator's streams. It is excellent if your product is "an overlay for streamers" and unworkable if your product is "a market intelligence dashboard that watches a thousand creators."
Public web data
The www.tiktok.com Live pages render very limited data without authentication: creator handle, room title, and a viewer count that updates on page load. There is no public REST endpoint TikTok promises will keep working, and the underlying WebSocket is not part of any documented developer contract.
That is the entire official surface. Everything else you have seen advertised as a "TikTok Live API" is a third party reverse engineering the mobile or web client.
Where TikLiveAPI fits, and where it does not
We will say this plainly: TikLiveAPI does not currently expose a dedicated /live/ endpoint. We do not stream real-time gift transactions, we do not relay chat messages, and we do not return concurrent viewer counts while a room is on air. If those are your core requirements, you should keep reading the "third-party landscape" section below rather than try to force our endpoints to do something they were not built for.
What we do well is everything that surrounds a Live stream in the regular TikTok feed. Two endpoints in particular carry most of the Live-adjacent use cases our customers actually ship:
User posts for post-stream recap discovery
Many creators publish a recap clip, a highlight reel, or a "thanks for the gifts" video shortly after their Live ends. GET /user-posts/ returns the user's feed in reverse chronological order, so polling it on a sensible cadence is the most reliable way to catch those artifacts.
GET https://api.tikliveapi.com/user-posts/?userid=107955
X-Api-Key: your_key_hereThe response shape is { videos, cursor, hasMore }. You iterate with cursor while hasMore is true to walk the full history, and on subsequent polls you stop as soon as you hit a video you have already seen.
User info for pre and post stream snapshots
The cleanest signal that a Live actually produced an audience uplift is the follower delta. GET /userinfo-by-username/ returns a stats{} object that includes the current follower count, so snapshotting it on a schedule lets you compute the change attributable to a stream.
GET https://api.tikliveapi.com/userinfo-by-username/?username=tiktok
X-Api-Key: your_key_hereA typical pattern is: take a snapshot at minute zero when you detect the stream went live (via the public web indicator), take another snapshot when it ends, and store both in your warehouse alongside any recap videos you discover with /user-posts/. Over time that gives you a per-stream lift metric without ever touching the Live room itself.
If you need to resolve a handle to the numeric ID first, GET /userid/?username=... is the one-call shortcut. Full request and response shapes for every endpoint live in the documentation, and you can try them against your own targets in the playground before writing any code.
The gaps, stated honestly
To save you the discovery cost, here is what TikLiveAPI does not offer today:
- No real-time gift stream. We cannot tell you that user X just sent a Galaxy worth 1000 coins at 14:23:07 UTC.
- No live chat relay. We do not deliver the comment WebSocket, neither raw nor moderated.
- No concurrent viewer count. We do not return the number you see in the corner of the TikTok app while the stream is on air.
- No Live moderation hooks. We cannot ban users, pin messages, or push announcements into a room.
- No room search. We do not have an endpoint that returns "all rooms currently live in country X with more than 1000 viewers."
If a stakeholder asks for any of the above, treat it as a hard gap and source it from a Live-focused provider, not from us.
Workarounds for the common use cases
"I want to know if a creator went live"
The cheapest reliable signal is a low frequency poll of the public Live page itself, paired with a follower snapshot via /userinfo-by-username/ so you can later compute lift. We do not provide the "is live" boolean, but the moment the stream ends you can start polling /user-posts/ for the recap.
"I want to estimate gift revenue per stream"
Real-time gift totals are out of reach without a Live-specific provider. A rough proxy is to combine the recap video's view and like counts (visible in the /user-posts/ response) with the follower delta from the two snapshots described earlier. It is an estimate, not a ledger, and you should be honest with stakeholders about that.
"I want a leaderboard of who streams the most in my niche"
Use /search-user/?keyword=... to assemble your candidate list, then walk /user-posts/ per creator and count entries whose metadata indicates they are recap or highlight clips. Most creators tag those clearly. Cache aggressively; recompute the leaderboard daily, not hourly.
"I want to know who is following a streamer right now"
GET /user-followers/?userid=... returns a paginated follower list with cursor and hasMore, so a diff between two snapshots tells you who joined or left across a window that includes a stream. This is the closest stand-in for "viewers who converted" that the public surface allows.
The third-party landscape
If your product genuinely needs real-time Live data, you will end up integrating with a provider whose whole stack is built around it. Without endorsing any specific name, the category typically offers one or more of:
- WebSocket relays for chat and gifts, billed per concurrent connection or per event.
- REST snapshots of currently-live rooms, often with regional filters.
- Historical gift archives for already-ended streams, useful for retrospective analytics.
These providers tend to be priced higher than feed-style APIs because maintaining a working Live connection is materially harder than scraping a public profile page. A common shipping pattern is to use a Live-focused vendor for the room itself and a feed-focused vendor (us, for example) for everything that surrounds it: the creator's profile, follower base, prior posts, and the post-stream recap. You pay each provider for the slice they are best at and avoid asking either to stretch.
How to advocate for Live endpoints
We track endpoint requests carefully, and Live coverage is on the roadmap conversation every quarter. The single most useful thing you can do, if Live data is critical to your product, is write to us with the specific shape you need.
A good request includes the use case in one sentence, the fields you would read from a sample response, and the polling or streaming cadence you have in mind. Vague "please add Live" notes are harder to prioritize than "we need a GET /live-status/?userid=... that returns whether the user is currently on air, the room ID, and the started_at timestamp; we would poll it once a minute for a list of 500 creators." The contact page is the right channel; messages there land in the same queue the team reviews when scoping new endpoints.
Pricing for any future Live coverage will be discussed openly on the pricing page once the work is scoped. We will not surprise existing customers with retroactive credit changes.
FAQ
Does TikLiveAPI have a /live/ endpoint?
Not in 2026. We expose 37 endpoints across users, posts, search, and discovery, none of which target a live room directly. The closest workarounds are /user-posts/ for post-stream recap discovery and /userinfo-by-username/ for follower snapshots that bracket a stream.
Can I detect when a creator goes live using your API?
Not directly. You can pair an external "is live" signal with our endpoints to capture the surrounding context, but the live state itself is not something we return.
What about gift transactions?
We do not return gift events of any kind. If you need them, integrate a Live-focused provider for that one signal and keep using us for profile, post, and follower data.
Is the official TikTok Open API enough on its own?
If your product is a per-creator tool where each creator installs your app and grants OAuth scopes, yes, it can be enough. If your product watches creators who have not installed anything, the Open API does not cover you, and you will need a third-party data layer for the public-facing pieces.
Where do I see the exact request and response shapes?
Every endpoint is documented at /documentation/ with a live example, and the playground lets you fire real requests against any creator handle without writing code first.
Is there a sister post that covers Live data possibilities in more depth?
Yes, see TikTok Live streaming data: what is possible today for a focused walkthrough of the workarounds above with longer code examples.
Closing thought
The TikTok Live landscape rewards specificity. Generic "Live API" shopping leads to disappointment because the data is genuinely split across an official surface that requires creator opt-in, a public surface that exposes very little, and a private real-time channel that only specialist vendors maintain. Decide which slice your product actually needs, then stack providers accordingly. TikLiveAPI handles the public, post-stream half of that stack well, and we will keep being clear about the half we do not.
