Build in Public · LF-04

TikTok Creator Data API: Preliminary Screening with Profile and Video Samples

Integrate TikTok profile and user_videos endpoints, separate account and video snapshots, calculate clear engagement metrics, handle missing values, and avoid treating public data as conversion results.

When reviewing a list of TikTok creators, sorting by follower count is the common starting point. However, a large following does not guarantee recent video stability, nor does a single viral video imply consistent performance across all content. If a dataset contains only usernames, follower counts, and an ambiguous engagement rate, the list remains difficult to verify and evaluate for outreach.

The TikTok Creator Data API supports evidence-based screening: verify account identity and profile details first, retrieve a well-defined set of video samples, and combine content fit with manual review. This guide uses EveryInfra profile and user_videos endpoints to execute this workflow, without extending public engagement data into sales, buyer personas, or ROI predictions.

Parameter and field definitions are verified against the 2026-09-04 public directory and source code. The following requests serve as templates adapted for authorized scenarios without live account calls in this run; calculation examples use synthetic data.

Distinguishing Official Authorized Display from Data Retrieval

The official TikTok Display API provides creator profiles and videos, including user info, video lists, and video lookup by ID, subject to application and user authorization flows. Official documentation lists user.info.basic and video.list permissions. If users connect their own TikTok accounts, start with this official integration path.

EveryInfra platform/action/params represents a separate request contract. It is distinct from the official Display API, does not reuse official access tokens, and receives no platform endorsement through this documentation reference. Evaluate permissions, fields, and coverage for each path independently.

This guide covers profile and account video samples only. Comments, hashtags, products, or marketplace capabilities require separate actions; do not derive product sales from a profile object or treat product search regional filters as creator nationalities. Narrow the research scope first to identify required fields.

Step 1: Splitting the Research Task into Two Distinct Reads

The profile endpoint returns public profile details, while user_videos returns video records for the account. Although both accept a username, their response structures differ: the former returns an object, while the latter returns an array. Parsing logic cannot simply swap the action parameter.

Check the current contracts of the profile page and video list separately
curl -fsS --max-time 30 \
  'https://api.everyinfra.com/api/v1/social/catalog?platform=tiktok' \
  | jq '.capabilities[]
    | select(.action == "profile" or .action == "user_videos")
    | {action, required_params, optional_params, param_meanings,
       mode, returns_list, default_limit, max_limit, response_fields}'

In this directory, both endpoints require a username and use sync mode. user_videos defaults to 10 items with a maximum of 50 items, whereas profile is a single object without a list limit. Usernames refer to account handles rather than display nicknames, full profile URLs, or internal IDs. Examples use handles without the @ symbol to match the current public directory.

Usernames are used for requests, while stable account IDs provide long-term association. When a handle changes, do not treat the new handle as a brand-new creator, but avoid matching solely on similar avatars or nicknames. Prioritize IDs when available, and retain unverified states during identity conflicts or missing IDs.

Step 2: Retrieving Profiles and Confirming Objects Before Scoring

Assuming the server is configured with EVERYINFRA_API_KEY and an authorized EVERYINFRA_TIKTOK_USERNAME, execute a single profile request and retain HTTP status and body for initial checks. Do not expose keys in frontend code or public analysis sheets.

Read one account's profile template
: "${EVERYINFRA_API_KEY:?set the API Key first}"
: "${EVERYINFRA_TIKTOK_USERNAME:?paste the authorized account short name}"
jq -cn --arg username "${EVERYINFRA_TIKTOK_USERNAME}" '{
  platform: "tiktok", action: "profile", params: {username: $username}
}' | curl --silent --show-error --include --max-time 180 \
  'https://api.everyinfra.com/api/v1/social' \
  -H "Authorization: Bearer ${EVERYINFRA_API_KEY}" \
  -H 'Content-Type: application/json' --data-binary @-

The current implementation places profile objects within results, alongside request tracking and billing metadata. Verify that username, user_id, and source URL match the target. If no object is returned, do not generate a zeroed-out account profile. Distinguish inaccessible content, retrieval failures, and genuinely missing public data.

Profile fields help understand account bios and scale, including bio, follower_count, following_count, video_count, is_verified, and is_private. They do not prove audience age, purchasing behavior, or sensitive creator attributes. When is_private is true, do not assume videos are readable or attempt workarounds.

Distinguish identically named fields: profile like_count is an account-level metric, while video like_count belongs to that specific video. Do not mix them into a single unscoped like count column, nor divide account cumulative counts by recent video views.

Step 3: Fetching Video Samples and Recording Selection Criteria

Read that account's video list template separately
: "${EVERYINFRA_API_KEY:?set the API Key first}"
: "${EVERYINFRA_TIKTOK_USERNAME:?paste the authorized account short name}"
jq -cn --arg username "${EVERYINFRA_TIKTOK_USERNAME}" '{
  platform: "tiktok",
  action: "user_videos",
  params: {username: $username, limit: 5}
}' | curl --silent --show-error --include --max-time 180 \
  'https://api.everyinfra.com/api/v1/social' \
  -H "Authorization: Bearer ${EVERYINFRA_API_KEY}" \
  -H 'Content-Type: application/json' --data-binary @-

The five items here validate fields rather than serving as statistically representative sample sizes. Requests execute and bill independently of profile reads; profile success does not guarantee video list success. Save request IDs, timestamps, and billing data for both requests separately.

When sorting is required, the current user_videos directory lists newest, oldest, and popular; align selections with research goals. Popular samples highlight standout content rather than baseline performance, while chronological samples require checking for pinned items, missing entries, publish times, and window alignment.

The until parameter sets an upper bound on video publish time, not collection time or a validated pagination cursor. The current list contract offers no pagination guarantee for complete history traversal; repeated date adjustments do not prove zero omission. Minimal examples start without filters, adding them incrementally while verifying results.

Parameters may appear across multiple actions in the directory. Listing a parameter does not guarantee applicability to all targets; for example, video sorting does not interpret as sorting by creator follower count. When parameter effects are unconfirmed, keep them in integration tests rather than research conclusions.

As an interface boundary contrast, the official TikTok authorized video/list specifies cursor, has_more, and per-page max_count. Do not apply official pagination parameters to EveryInfra user_videos: pagination support depends entirely on the specific endpoint contract and results.

Step 4: Storing Accounts, Videos, and Observations Separately

Data can be organized into three object types: account tables for identity and profile observations, video tables associating content and accounts via video IDs, and observation tables storing metric values, conditions, and timestamps from specific requests. This structure avoids duplicating creator profiles when video view counts update.

  • Account observation: user_id, requested handle, returned handle, profile reference, available counts, observation timestamp, and request ID.
  • Video observation: video ID, URL, text, author handle, posted_at, engagement/view counts, observation timestamp, and request ID.
  • Derived analysis: utilized videos, excluded records, metric formula version, calculation timestamp, and manual notes.
Read video field meanings and the unknown-field list
curl -fsS --max-time 30 \
  'https://api.everyinfra.com/api/v1/social/fields?platform=tiktok&action=user_videos' \
  | jq '{fields, undocumented}'

The video directory lists like_count, comment_count, share_count, and view_count. Official video documentation explains likes, comments, shares, and views to help verify terminology, but this does not guarantee EveryInfra returns all official fields. Parse each endpoint according to its actual response.

Distinguish null values, missing fields, and 0. Unreported view counts cannot be filled as zero, and missing share counts should not enter engagement calculations silently. posted_at and observed_at differ: the former indicates publication time, while the latter records observation time.

Step 5: Defining Formulas Before Calculating Engagement Rates

No single engagement rate formula fits all teams. For demonstration, define a sample metric: engagement-to-view ratio = sum of likes, comments, and shares in qualified samples ÷ total views in the same sample. The numerator tracks engagement events and the denominator tracks views—neither represents unique users nor conversion rates.

This guide includes records with valid non-negative integer counts and views greater than zero, listing incomplete records separately. This conservative rule prevents masking missing data with zeros. Custom definitions require adjusted rules and version tracking; results across different formulas cannot be ranked together.

Offline JavaScript: handle missing values and zero denominators explicitly
function interactionPerView(rows) {
  const seen = new Set();
  let events = 0, views = 0, used = 0;
  const excluded = [];
  for (const row of rows) {
    if (typeof row.id !== "string" || !row.id || seen.has(row.id)) {
      throw new Error("missing or duplicate video id");
    }
    seen.add(row.id);
    const counts = [row.like_count, row.comment_count,
                    row.share_count, row.view_count];
    if (!counts.every(x => Number.isSafeInteger(x) && x >= 0)
        || row.view_count === 0) {
      excluded.push(row.id);
      continue;
    }
    events += row.like_count + row.comment_count + row.share_count;
    views += row.view_count;
    if (!Number.isSafeInteger(events) || !Number.isSafeInteger(views)) {
      throw new Error("aggregate exceeds safe integer range");
    }
    used++;
  }
  return {used, excluded, events, views,
          ratio: views > 0 ? events / views : null};
}

console.log(interactionPerView([
  {id: "synthetic-a", like_count: 8, comment_count: 1,
   share_count: 1, view_count: 100},
  {id: "synthetic-b", like_count: 7, comment_count: 1,
   share_count: 1, view_count: 10},
  {id: "synthetic-c", like_count: null, comment_count: 1,
   share_count: 0, view_count: 20}
]));

Among three synthetic records, the first two enter calculations while the third is excluded due to a missing like count. Total engagement equals 19, total views equal 110, and the engagement-to-view ratio is approximately 17.27%. Averaging individual ratios yields 50%; these answer different questions. The former weights by view volume, while the latter weights videos equally. State the choice clearly in reports.

This example is neither a creator scoring benchmark nor an industry standard. Accounts can feature standout content alongside average performance, and content duration, publication timing, and selection criteria affect comparability. Presenting sample sizes, exclusions, total views, and observation windows is more useful than a single percentage.

Step 6: Allowing Manual Interpretation in Screening Results

Public data helps prioritize accounts to review but should not replace content inspection. When reviewing video groups, check topic relevance, target audience fit, and sufficient recent content. Conclusions on content suitability require specific evidence rather than a black-box score.

Avoid inferring sensitive personal attributes from bios, names, avatars, or languages. Commercial partnerships requiring verified audience data, conversions, or fulfillment metrics should use proper authorization and collaboration workflows. Without such evidence, mark fields as unknown rather than using models to fabricate complete profiles.

Product research requires clear methodologies. Mentions of products, profile links, or store info do not bridge the evidentiary gap to actual sales, net revenue, or ROI. The two actions in this guide do not prove commercial outcomes; do not inject estimated GMV into output tables as platform facts.

Step 7: Tracking Changes Through Repeated Observations

Single profile or video calls provide snapshots. Analyzing growth requires comparable observations: consistent identities, matching field definitions, clear observation intervals, and successful data retrieval across runs. A subsequent failure does not mean follower or view counts dropped to zero.

Distinguish fixed video sets from rolling video sets. Tracking a fixed group captures count changes over time, whereas fetching recent groups introduces content set shifts. Chaining these sequences into a single curve without tracking video membership makes the curve uninterpretable.

Disappearing videos do not prove deletion; they may fall outside the current sample. Renames, pin changes, timestamp parsing failures, and field gaps belong in quality notes. Do not automatically label creators as abnormal or untrustworthy when data volume drops.

When tracing screening variations, adopt W3C PROV entities, activities, and derivations: link video samples, rule versions, and generated lists. This borrowing applies conceptual principles without mandating RDF adoption or claiming compliance with PROV exchange specifications.

Preserving Recoverable Records on Error

Check auth, capability permissions, and account conditions separately for 401, 403, and quota issues. Fix parameter errors based on response hints rather than repeating failing requests. Unrecognized response shapes go to review queues; do not combine profile empty objects and video list empty arrays into a single success state.

Following network timeouts, servers may have completed requests; do not retry blindly assuming zero duplicate charges. Retain start/stop timestamps, actions, non-sensitive parameter summaries, and tracking IDs before verifying call logs. Actual costs depend on billing and invoices, not final research row counts.

Delivering a Verifiable Screening List

Usable creator screening records require selection rationales and evidence boundaries: account identity, sample sources, observation timestamps, calculation rules, exclusions, content review notes, and pending partner confirmations. Do not package single API responses as complete due diligence or treat public data readability as unlimited permission to store and redisplay.

Verify profiles, videos, and metrics with an authorized account before scaling up. Data APIs reduce manual collection effort; screening quality depends on clear metric explanations and grounding every judgment in actual samples.