TikTok Research API access: is_random order vs Sume order
The Research API returns videos by decreasing ID unless is_random is true. Sume's order=play_count sorts a bounded 24-item sample, not a full ranking.
On the TikTok Research API, results come back in decreasing video-ID order unless is_random is true, which returns 1 to 100 videos in random order. Sume's tiktok_search_keyword has order: recent (default) or play_count, and it sorts a bounded sample locally, so "most played" means most played among at most 24 items.
TikTok facts are from its Query Videos page (updated September 1, 2026); Sume facts from the OpenAPI document behind the API reference, read 2026-09-30.
How does the Research API order results?
Per the page: with is_random set to true the API returns 1 to 100 videos in random order; otherwise the order is decreasing by video ID. There is no play-count sort in that description, so ranking by views is work you do after the response.
What does order=play_count do on Sume?
| Control | TikTok Research API | Sume tiktok_search_keyword |
|---|---|---|
| Default order | Decreasing video ID | order: "recent" |
| Random | is_random: true | Not offered |
| By plays | Not described | order: "play_count" |
| Platform-side sort | Not described | sort_by: relevance, most-liked, date-posted |
| Sample size | Up to 100 videos | At most 24 items and 3 feed pages |
Is play_count a ranking of everything?
No. The schema's own description reads: "Sort the bounded sample locally; play_count is not an all-time account ranking." The route fetches up to 3 feed pages, keeps at most 24 items, then orders those. A video with more plays that never entered the sample cannot appear. Widen the sample by changing query, region or date_posted, not by raising limit past 24.
What should I use for a fair sample?
Run several narrow queries, for example per region (a two-letter code such as US or KR), and compare the sorted results. For region-wise trend lists see trending videos by region. If you need randomized research samples, use the Research API; Sume does not offer a random mode.
Sources
Related posts
More in Developers
- Join voiceover clips inside one timeline render with audio.parts
Timeline 1.0 takes up to 20 gapless audio.parts slices with source_in and duration. Skip the timeline-audio job when the join is only for one render.
- Timeline 1.0 limits: 200 slots, 1800 s, 20 audio parts, 8 fades
The numbers that cap one Timeline 1.0 render: 1 to 200 video slots, 1 to 1800 s of audio, 20 audio parts, 12-slot single strategy and 8 chained fades.
- Timeline render warnings: padded or looped short sources explained
A Timeline 1.0 slot longer than its source renders with a soft warning, not a failure, and /plan cannot predict it. Read warnings[] and probe clips first.
- Token bucket vs fixed window: what a reset header means
Anthropic says its limits replenish continuously; Sume's docs call ratelimit-reset the seconds until the window resets. How to pace a client for each.
Written by Sume