Profile

lookup · $0.0010

One creator, by their opaque id.

POST https://api.sorina.sh/v1/tiktok/users

Body

fieldtypewhat it is

sec_user_id string

The opaque MS4wLj… id. Not the @handle and not the numeric uid — /search/users is the one route that turns a name into one of these.

A type written with ? is optional. Unknown fields are rejected rather than ignored, and the whole body is capped at 64 KiB.

Example

curl -X POST https://api.sorina.sh/v1/tiktok/users \
  -H "authorization: Bearer $SORINA_KEY" \
  -H 'content-type: application/json' \
  -d '{"sec_user_id":"MS4wLjABAAAAU9BRVzC8oCaegVnia8IbqWhPb_-dbU7s00Y3wS1_Nx8g5RUaYvyXrpejgjdxTwd6"}'

What comes back

JSON, and not a flat user object: the platform answers with the profile screen, so the data is scattered through nested component trees rather than sitting at fixed paths.

common is the flat, stable part. common.user_profile_info carries uid, sec_uid, username, nickname and avatar; common.user_account_info carries is_private_account and verification; common.user_statics_info carries aweme_count.

Follower, following and like counts are not in common — they live in the header tree under nodes named relation_info_follower, relation_info_following and relation_info_like, and are repeated together in nav_bar under nav_bar_end_more, which is the convenient one to read.

Walk the tree for the keys you want rather than mirroring it into a struct. Which components appear is a rendering decision, and it changes.

/comments