TikTok Creator Monitoring API: Uploads, Reposts and Lives (2026)

Why watching a creator is the hard case

Everything on the developer platform is scoped to consent you have to collect first. The display surfaces return videos for a creator who has connected their own account to your app. The posting surfaces publish on that creator's behalf. The research surface is gated behind an application and an approval process. All of it points the same direction: a creator authorizes you first. None of it answers the question people actually have, which is "tell me the moment this public creator uploads." There is no endpoint for that, and no combination of scopes turns one into it.

So the demand goes somewhere else. Trading desks watch the finance and crypto creators who move retail attention. Brand and agency teams watch the creators their competitors work with and the ones they pay themselves, partly to catch a drop and partly to verify a post actually ran. Media teams watch the creators who break things on TikTok before they reach anywhere else. Community and bot builders just want a Discord channel that fills itself. Every one of those is a watchlist problem, and a watchlist problem needs push, not a request you have to remember to make.

Four things a TikTok feed has to carry

"New video" is the obvious one and it is not enough. The 1322 TikTok feed watches creators by @username and emits five event types, because a creator does four distinct things worth knowing about:

• They upload. tiktok.upload.created, with the video id, URL, description and cover.
• They repost someone else. tiktok.repost.created carries original_author alongside the creator who reposted, so a repost never gets mistaken for an upload and you can still see whose video is spreading.
• They go live, and then stop. tiktok.live.started and tiktok.live.ended are separate events, which is what lets a bot open an alert and later close the same one.
• Their video becomes downloadable. Media for a tracked video becomes available shortly after the upload is announced, and tiktok.media.ready is the signal that the file can be fetched.

That last one is the difference between an archive that works and a retry loop. If you fetch the file the instant you hear about the video, you are guessing. If you wait for the media-ready event for thatvideo_id, you make one request and it succeeds. The full endpoint reference is in the API docs.

The event contract

Every WebSocket frame is one JSON object carrying the schema string1322.tiktok.event.v1. You branch ontype, read the creator fromaccount, and read the payload fromobject. Trimmed upload event:

{
  "schema": "1322.tiktok.event.v1", "event_id": "01J9Z8QX4T7C2V1M0K3R5B6N7P", "type": "tiktok.upload.created", "platform": "tiktok", "account": { "username": "examplecreator", "display_name": "Example Creator" }, "object": {
    "video_id": "7300000000000000000", "url": "https://www.tiktok.com/@examplecreator/video/7300000000000000000", "description": "new video"
  }, "delivery": { "mode": "live_only" }
}

Two fields do quiet work. event_id is unique per event, so a reconnect never double-fires your alert if you keep a small seen-set. Anddelivery.mode sayslive_only out loud: this is a stream, not a backlog. Nothing is queued for you while your client is down, which is the honest trade for a feed that exists to tell you about things as they happen.

Two credentials, two headers

This is the one thing worth reading twice before you write any code. TikTok access issues two separate credentials. REST calls, the ones that manage the tracked list and fetch media, use your API key in theX-API-Key header. The WebSocket uses a different WebSocket credential, sent asAuthorization: Bearer on the connection request. They are not interchangeable, and neither is accepted in the URL, so there is no?key= to paste into a browser tab. Adding a creator is one REST call:

curl -X POST "https://tiktok.1322.io/v1/track" \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"username": "examplecreator"}'

And a minimal Python consumer for the stream:

import asyncio, json, websockets

WS_URL = "wss://tiktok.1322.io/ws/..."      # websocket.path from GET /v1/dashboard
WS_CREDENTIAL = "your-websocket-credential"  # NOT the REST API key

async def main():
    async with websockets.connect(
        WS_URL, additional_headers={"Authorization": f"Bearer {WS_CREDENTIAL}"}, ) as ws:
        async for raw in ws:
            e = json.loads(raw)
            who = e["account"].get("username")
            obj = e.get("object") or {}
            if e["type"] == "tiktok.upload.created":
                alert(f"@{who} posted: {obj.get('url')}")
            elif e["type"] == "tiktok.repost.created":
                orig = (obj.get("original_author") or {}).get("username")
                alert(f"@{who} reposted @{orig}")
            elif e["type"] == "tiktok.media.ready":
                download(obj["video_id"])  # file exists now, one request

asyncio.run(main())

If you would rather not run a consumer at all, the included Discord bot posts tracked-creator events straight into a channel and manages the tracked list from chat, the same pattern covered in alerts in Discord and Telegram.

Lives are a state machine, not a post

Most tools that claim live notifications fire once and forget. That is fine for a ping and useless for anything with state. Because start and end arrive as separate events carrying the sameroom_id, you can model a session properly: post the alert on tiktok.live.started, keep the message id, then edit it to "ended" ontiktok.live.ended instead of leaving a stale "LIVE NOW" card in the channel overnight.

open_sessions = {}

if e["type"] == "tiktok.live.started":
    room = e["object"]["room_id"]
    open_sessions[room] = post_alert(f"@{who} is live")
elif e["type"] == "tiktok.live.ended":
    room = e["object"]["room_id"]
    msg = open_sessions.pop(room, None)
    if msg:
        edit_alert(msg, f"@{who} finished the live session")

What it costs

TikTok monitoring is a standalone subscription, priced on how many creators you watch: $200 per month for 5, $350 for 15, and $550 for 30. REST management and Discord bot delivery are included on every plan; WebSocket delivery is a $100 monthly add-on for teams consuming the stream in their own code. It runs on the same account as the other six sources, so a desk already watching X or Truth Social adds TikTok without a second vendor, a second billing relationship, or a second event vocabulary to learn. Plans and the full event list are on the TikTok monitoring API page, and the alternatives are laid out in TikTok API alternatives compared.

FAQ