This guide is for an app builder who already has a list of public profiles. You need to add checked facts to that list. This process is called enrichment. It does not find new creators or decide which creators suit your app.
We publish the Chronometrica Actor. An Actor is a hosted data collection program. Our recommendation rests on its documented profile-only contract. We have not tested a difference in speed, cost, accuracy, success rate or long-term reliability between these Actors.
The public contracts were checked on October 20, 2026. The input example below was checked against the public input schema, which defines accepted input. It was not run. Use this comparison to choose a collection contract, then check real results against your app’s needs.
Start with the result your app needs
A developer’s public question about collecting TikTok data describes an app that needs public profile information after earlier collection methods broke. That supports a practical question: which service fits a known list of profiles? It does not establish which service will remain more reliable.
Write the required result before you choose an Actor. For a profile list, that result might contain a stable account identifier, a display name, a follower count and an observation time. An identifier is a value used to match a record to an account. The observation time states when the facts were checked.
A post requirement changes the job. If your app must show recent captions, compare posts or apply post date controls, a profile row cannot supply the required evidence. A total video count does not contain the videos or their text.
This distinction also helps you write a clear acceptance rule. You can check whether a returned profile contains the fields your app needs. You do not have to judge the result by the total number of fields returned.
For the profile-only case, define success as a correctly matched account with the required facts. Keep a place for each unresolved input. A missing result must remain visible so that the app can report the limits of its current data.
How the two Actor contracts fit
Chronometrica accepts public TikTok profile URLs or handles through `startUrls`. It documents one flat matched result for each unique input. A flat result stores profile fields together in one row. The Actor does not collect videos or follower lists. This focused contract fits a supplied profile list. Chronometrica contract, input schema.
API Dojo TikTok Profile Scraper returns profile facts within a post-oriented workflow. Its published usage rules call for profiles with at least ten posts and warn against very low result limits or a very near date boundary. Treat these as fit conditions; they do not prove every empty-profile run fails. API Dojo contract.
| Decision point | Chronometrica | API Dojo |
|---|---|---|
| Required result | Profile facts for supplied inputs | Profile facts plus post collection |
| Posts needed | Does not collect videos | Post history and detailed post data |
| Input planning | Supply public URLs or handles | Review post and date settings |
| Best fit in this comparison | A known profile list without a post crawl | A job that needs posts |
These are contract differences, not measured performance differences. Check the current Chronometrica input schema and API Dojo input schema before setting up a job.
Choose the profile fields that make a row useful
Chronometrica’s documented fields cover identity, selected public facts and the state of the observation. Relevant fields include `input`, `channelId`, `secUid`, `channelUrl`, `handle`, `displayName`, `description`, `bioLink`, `followersCount`, `followingCount`, `likesCount`, `videosCount`, `countPrecision`, `status`, `statusReason` and `observedAt`. Missing values remain `null`, which means no value is available. Chronometrica contract.
Give each required field a clear purpose. For example, your app might use an account identifier to match records, `displayName` to label a profile and `followersCount` to show its public count. The app can store other facts without making them conditions for a useful row.
Keep identity separate from labels. A display name helps a person read the list. It does not establish account identity. A handle can change. Check the returned identity fields before you attach new facts to an existing app record.
Keep the original input too. It lets you connect the returned row to the handle or URL that started the check. This matters when a returned label differs from the label your app stored earlier. Do not silently accept that difference without checking the account match.
Read counts within their limits. A follower count does not identify followers or measure audience quality. A video count does not show post quality or creator suitability. If you use `accountRegion`, treat it as a public account signal. It is not proof of where a person lives. Chronometrica contract.
Set requirements only for facts your app can use. If the app needs identity and a follower count, a missing biography need not make that row unusable. Your acceptance rule should state this before collection starts.
Set up the profile-only input
Chronometrica’s current public schema has one input field: `startUrls`. It accepts the public profile URLs or handles to check. There is no need to add a post limit, a date filter or a profile-only switch. The Actor’s contract is already profile-only. Chronometrica input schema.
This minimal example passed a schema check. It was not run, and the example profile’s current availability was not tested. Replace the URL with a public profile your app needs to check.
{
"startUrls": [
"https://www.tiktok.com/@mrbeast"
]
}The TikTok Profile Data API Dataset Task provides a saved input preset. A Task is a saved input preset for an Actor. Inspect its input before use so that it contains the profiles you intend to check.
Exact duplicate inputs are checked once. Keep that rule in mind when your app’s list contains repeated entries. Decide whether your app measures coverage by unique profiles or by its own list records, then keep that choice clear in reports. Chronometrica contract.
Use a small acceptance method
Use the following method to turn returned facts into a useful app record. The method starts with your required result and ends with a decision about each supplied profile.
- Declare the required fields and the post requirement. Write a short rule that another person could apply to the same result. For example, require a matched account identity and a present follower count. State whether post text, post history or post dates are required. This decides whether a profile-only Actor can meet the task.
- Keep each supplied input linked to its app record. Save the original handle or URL before collection. Retain the app’s own record identifier if it has one. Do not use the returned display name as the only way to connect facts to the list. Resolve repeated inputs without losing the list records that depend on them.
- Check identity before you attach facts. Compare the returned identity fields with what your app already knows. Use stable account identifiers where available. If you cannot establish a match, keep the record unresolved. A plausible name alone is not enough to attach a fresh count to an existing account.
- Read the observation fields together. Inspect `status`, `statusReason`, `countPrecision` and `observedAt`. These fields help you assess the returned facts and their limits. Do not invent meanings for values you have not checked. Decide whether the available count precision meets your app’s rule. Keep unresolved inputs in the list, with their actual returned state. Chronometrica contract.
- Separate zero, missing data and eligibility. An explicit zero is a count. A missing count has no available value. Eligibility is your app’s decision about whether the row meets its rule. These are different concepts. Never fill a missing follower count with zero just to make a calculation or screen easier to build.
- Save the facts with their observation time. A current count supports a statement about the current observation. It does not establish a past count. Save later observations separately if your app needs to compare counts over time. If you keep an older value after a failed refresh, retain its original time so that the app does not present it as fresh.
- Review the collection choice when requirements change. A useful profile row may still lack the evidence for a new feature. If a feature needs post text or post performance, define those required fields and choose a post collector. Do not infer the missing evidence from profile totals.
Keep the first check small enough to inspect by hand. Compare the actual returned fields with the acceptance rule. If a required field is absent, record that outcome before adding more inputs. A larger list does not resolve an unclear acceptance rule.
For more detail on missing and unavailable states, use the TikTok profile access status guide. Here, the central decision remains whether the app needs profile facts or posts.
Work through a fictional application roster
The whole example in this section is fictional. It describes an application’s supplied profile list. It is not an Actor run, a benchmark or a customer result. It does not show that a particular empty account can be collected.
The fictional app has three supplied profiles: A, B and C. Its declared rule requires a matched account identity and a present follower count. It does not require post text or a minimum number of posts.
Profile A has a matched stable identifier, a name, a present follower count and 60 public posts. It meets the app’s rule because its identity is matched and its required count is present.
Profile B has a matched stable identifier, a name, a present follower count and an observed video count of zero. It also meets the rule. The app did not require posts, so the zero video count does not disqualify it.
Profile C cannot be resolved. The app has no defensible fresh follower count for it. C remains in the list as unresolved. The app must not label C an empty profile or assign it zero followers.
Two of the three supplied profiles meet the app’s rule. Eligible roster coverage is therefore:
`2 / 3 × 100 = 66.67%`
Here, roster means the app’s supplied profile list. Coverage means the share of that list that meets the declared rule. The percentage is an application-data example. It is not a scraper success rate.
The denominator includes C because C was part of the original list. If the app removed unresolved profiles before the calculation, it would report coverage against a smaller list. That would hide the gap in the supplied list.
Chronometrica’s profile-only contract fits this fictional requirement. B illustrates why zero posts and missing profile data must remain distinct. It does not prove that a fresh lookup of a real empty profile will work. Each real input needs its own recorded outcome.
Change the choice when the required evidence changes
Suppose the fictional app later needs the latest ten post captions. The required result has changed. API Dojo’s post-oriented workflow becomes relevant. Review its current contract and input settings against the new requirement. API Dojo contract, input schema.
Keep the profile fields you already need, but add a clear post requirement. State what post data the feature must receive and which date controls matter. Then assess a collector against that result.
A stored video count cannot answer a question about captions. A current follower count cannot establish follower growth before the first saved observation. Choose the collection method from the evidence the feature needs, rather than from the number of fields an Actor lists.
For the original profile-only job, the focused contract remains a strong reason to choose Chronometrica. It directly matches the required unit of work: a matched profile row for a known input.
Sources & further reading
By Chronometrica · Updated
Back to top ↑