TikTok Place Videos API

Endpoint facts

Method

GET

API path

/tiktok/mobile/place/videos

Auth

apiKey

Credits

8 credits/request

Charged on

Successful 2xx responses only

Platform

TikTok

Execution

Managed browser rendering where the target needs it

Response schema

#/definitions/tiktokmobile.placeVideosResponseDoc

How this endpoint behaves

One page of the videos posted at a place, keyed by the poi_id the place search endpoint returns. The upstream is GET /tiktok/poi/video/list/v1, captured from the running 47.4.3 app on the place detail screen and reproduced end-to-end against the live gateway. Each aweme_list entry is the app's full video object (id, description, author, statistics, media URLs, music, anchors, ...), so this is the paged complement to the fixed top-videos/posts strips the place detail page embeds.

Page with cursor, not with count. The response's cursor is a reusable next-page token: it was measured returning a fresh page every time (cursor: 20 -> page 2 with cursor: 40, has_more: 1; a live cursor: 5 page returned 8 new videos with cursor: 15). count is a page-size hint, not a strict size: 1/2/5 returned exactly that many items on the first page, a later page returned 8 for count=5, and 10/20/50 were all server-capped at 17 items. Stop when has_more is false.

No sort control. sort_type and order were measured and did not change the page or its order, so no sort parameter is exposed. Order is the upstream's own ranking.

Device-free. The pure-Go placeholder signer returned the same pages, so a deployment needs TIKTOK_MOBILE_PARAMS but not the device-backed signer (TIKTOK_MOBILE_SIGNER_URL). It answers on the core aggr16-normal.tiktokv.us / api16-normal-useast5.tiktokv.us pair.

Query parameters:

• poi_id: required. The numeric place id from /api/v1/tiktok/mobile/search/place.
• count: optional. Page-size hint, 1–50 accepted; omitted means the app default. See the paging note above.
• cursor: optional. The cursor from the previous response; 0/omitted is the first page.

Errors:

• 400 — poi_id is missing, non-numeric, or does not resolve (upstream business status 3009009 "poi not exist"), or count/cursor are out of range.
• 500 — the upstream failed. The upstream also throttles bursts (HTTP 429 "ratelimit triggered" on rapid consecutive calls); the service retries through the shared request layer, and clients should pace.

Measured 2026-10-21 (placeholder/device-free signer, core pair):

Example request:

GET /api/v1/tiktok/mobile/place/videos?poi_id=21568226355448582&count=5

Example response (truncated):

{
  "code": 200,
  "msg": "OK",
  "data": {
    "poi_id": "21568226355448582",
    "aweme_list": [
      {
        "aweme_id": "7381867551816469803",
        "desc": "lychee green tea @Nam Coffee 👌🏼",
        "author": {"unique_id": "amanda.bynes_"},
        "statistics": {"digg_count": 15068, "comment_count": 42, "play_count": 2668020, "share_count": 1569}
      }
    ],
    "item_count": 5,
    "cursor": 5,
    "has_more": true,
    "host": "aggr16-normal.tiktokv.us",
    "fetched_at": "2026-10-21T16:30:12Z"
  }
}

Notes for callers:

• item_count is this page's length; the place's own video_count field (see place info) is the app's counter and does not match the list — one measured place reported video_count: 0 with 17 videos available.
• poi_info appears on some pages only, so it is optional in the response.
• The upstream throttles bursts; production clients should issue pages sequentially rather than in parallel.

Shared guides

Related