---
name: tiktok
description: >-
  Drive the user's authenticated TikTok via the browser skill:
  feed/user/comments via the /api endpoints (signing-gated — read via page
  responses). Use for TikTok research as the user.
metadata:
  tags: browser, tiktok, internal-api, recon, social-graph
---

# TikTok — recon plan (hardest: anti-bot signing)

**Internal API:** `https://www.tiktok.com/api/<endpoint>/` with a large param
set **plus anti-bot signing**: `msToken` (cookie + param), `X-Bogus` /
`_signature` / `X-Gnarly` — generated by TikTok's obfuscated `webmssdk` JS.
Hand-crafting signed requests from scratch is impractical; **use the page's own
signer or its own fetches.**

## The winning move: stay in-page, reuse TikTok's signer

Because we run inside the loaded tiktok.com page, the signing code is already
present. Two viable strategies (capture which works):

1. **Reuse the page's fetch path** — trigger the action via the UI (scroll feed,
   open a video, open comments) and **read the resulting `/api/` JSON
   responses** from `list_network_requests` / a fetch-hook. Lowest-friction for
   READS.
2. **Call the in-page signer** — TikTok exposes signing via globals
   (`window.byted_acrawler` / the SDK's sign fn) used to build `X-Bogus`. If
   reachable, sign your own request params in-page, then fetch. Capture the
   exact global + signature param names live (they change).

Auth: cookies (`sessionid`, `tt_csrf_token`, `msToken`) ride same-origin; writes
need `sessionid` + valid signature.

## Endpoints (capture live; param sets are huge + signed)

| Purpose                  | endpoint                                |
| ------------------------ | --------------------------------------- |
| For-You feed             | `/api/recommend/item_list/`             |
| A user's videos          | `/api/post/item_list/?secUid=<…>`       |
| User detail              | `/api/user/detail/?uniqueId=<handle>`   |
| **Comments (who/likes)** | `/api/comment/list/?aweme_id=<id>`      |
| Video detail             | `/api/item/detail/?itemId=<id>`         |
| Search                   | `/api/search/general/full/?keyword=<q>` |
| WRITE: like (digg)       | `/api/commit/item/digg/`                |
| WRITE: follow            | `/api/commit/follow/user/`              |
| WRITE: comment           | `/api/comment/publish/`                 |

## Entity model

`User{id, uniqueId(handle), secUid, nickname, followerCount}` ·
`Video{id(aweme_id), desc, author:User, stats:{diggCount, commentCount, shareCount, playCount}}`
· `Comment{user, text, diggCount}`.

## Capture method

Open tiktok.com → `list_network_requests` for `/api/` → note endpoint + the
signed params (`X-Bogus`, `msToken`, `_signature`) + whether the response is
readable. Probe for the signer global in-page.

## Actions to test (read-first; writes gated + likely blocked)

1. Open a profile/video via UI → read the `/api/` responses (feed, user,
   comments).
2. If a signer global is reachable → try a signed read (e.g. comment/list).
3. **who-commented + diggCount** → engagement graph.
4. (gated, expect friction) digg/follow/comment — explicit confirm.

## Gotchas — manage expectations

- **TikTok has the strongest anti-automation** of the set. Signed-request
  replication is fragile + drifts; expect blocks/captchas on writes.
- Prefer **read via the page's own responses / UI-driving** over hand-signed
  fetches. Writes: minimal, gated, accept they may fail.
- This is the one platform where DOM / UI-driving may beat the API approach.