TikTok Refill Policies Explained: Retention Windows, Drop Tracking and Service Guarantees
A TikTok follower refill policy is a provider’s written rule for whether delivered followers that later disappear may be replaced. Its retention window defines the period in which a drop can be documented and reviewed. Eligibility still depends on the service terms, order record, delivery status and available evidence. A refill guarantee does not mean followers cannot drop or will remain permanently.
What Is a Refill and Retention Window?
A refill is a provider-side process that may replace some of the quantity lost after an SMM service order. It is different from an initial delivery, a new order, a cancellation and a refund.
The retention window is the period during which the provider accepts or evaluates documented drops. The service description should state when that window begins. It might be tied to order completion, final delivery or another recorded event. The start point must not be assumed because providers and services can define it differently.
A refill guarantee belongs to a specific service order. It does not cover every change in the target account’s total follower count. The relevant relationship is:
SMM service order → recorded delivery → stated retention window → documented count change → refill review
The applicable conditions should be attached to the service selected when the order was placed. Switching services, targeting options or providers can introduce different rules even when every order points to the same TikTok account.
When comparing TikTok services and policy details, read the description attached to the exact service rather than applying one service’s refill terms to the entire catalog.
Targeting also matters. A country-targeted service, for example, may have different delivery inputs or conditions from a non-targeted service. The order ID and service ID help support identify which terms governed the original delivery.
How a Refill Process Works
The process begins with an order record. Its inputs may include the order ID, service ID, target link or username, targeting selection, ordered quantity, starting count and submission time.
During delivery, the SMM panel records status changes. A provider API may expose some of the same order information to resellers or automated systems. Exact fields, status names and refresh intervals vary by provider.
The output of a refill review may be a status update, a request for more evidence or a refill action. It may also determine that the available records do not establish eligibility. None of these outcomes should be assumed before the service terms and order history are checked.
Order Statuses and Error States
Statuses commonly represent operational stages such as waiting, processing, partial delivery, completion or cancellation. These are general classifications rather than universal labels. The dashboard or API documentation remains the source of truth for the provider’s actual terminology.
A completed status normally records the provider’s fulfillment state. It does not promise permanent retention or prove that every later change came from that order.
A partial status indicates that the full ordered quantity was not recorded as delivered. A cancellation may occur before delivery or after partial activity. In either case, the ordered quantity alone should not be used as the delivered quantity.
Possible error conditions include an invalid target, an inaccessible or restricted account, a changed username, a removed target or a mismatch between the submitted link and service requirements. Whether an error affects refill eligibility depends on the conditions published for that service.
Measurement and Decision Method: How We Measure
A refill claim should be treated as a time-based measurement record. The goal is to document what changed, when it changed and which order terms might apply without claiming that every decrease came from the purchased service.
Data Input and Source
| Field | Definition | Preferred record |
|---|---|---|
| Order ID | The provider’s identifier for the transaction | Dashboard or provider API |
| Service terms | The conditions attached to the selected service | Dated service description or order record |
| Starting count | The target’s recorded follower count when the order began | Provider record plus a timestamped account snapshot |
| Delivered count | The quantity the provider recorded as delivered | Dashboard or provider API |
| Status history | Recorded order-state changes | Dashboard export, API record or timestamped screenshots |
| Observation timestamps | The dates and times at which counts were recorded | Consistent manual or automated log |
| Current count | The target’s follower count at the latest observation | Same source used for earlier observations |
| Measurement window | The interval between the selected baseline and current observation | Calculated from recorded timestamps |
| Denominator | The quantity used to express a drop rate | Declared with the calculation |
| Comparison group | Like-for-like orders or periods used for context | Same service, targeting and status conditions where possible |
| Stated refill window | The provider’s published period for reviewing drops | Service description or order terms |
TikTok’s official Research API documentation defines follower_count as the number of followers an account has. That value is an account-level count rather than an order-level attribution record.[1]
A visible account count, dashboard record and provider API response can therefore serve different purposes. The TikTok count records the account state at an observation time. The provider record connects delivery information to an order ID.
Formula or Classification
A simple count change can be recorded as:
Observed count change = Current count − Starting count
A negative result shows that the account count is below the selected baseline. It does not identify which followers disappeared.
When a verified post-delivery count is available, an observed decline can be recorded as:
Observed decline = Post-delivery reference count − Current count
A drop rate may then be expressed as:
Recorded drop rate = Observed decline ÷ Selected denominator × 100
There is no universal denominator for refill claims. One record may use the provider-reported delivered quantity. Another may use the observed increase above the starting count. These choices can produce different percentages.
The selected baseline matters as much as the formula. A count taken before delivery, at completion or several days later describes a different measurement window. Every calculation should therefore state its baseline, denominator and observation timestamps.
Comparison Group
For a single order, earlier account periods can provide context but cannot prove attribution. Organic follows and unfollows may occur during both the delivery and retention window.
For multiple orders, compare records that share the same service ID, targeting conditions, completion state and observation window. Do not combine completed orders with partial or canceled orders. Do not combine different services simply because they delivered the same metric.
A comparison group helps identify whether a pattern is isolated or repeated. It does not override the terms attached to an individual order.
Confounder Log
The evidence record should note any event that could change the count or obscure attribution. Relevant confounders include organic follows and unfollows, concurrent orders, delivery from another provider, a username change, account privacy changes, target restrictions, platform count-display delays and inconsistent observation times.
If the original order used drip feed, record the applicable cycle and completion timestamps. This establishes which delivery event may start the refill window without turning the refill review into a delivery-pacing analysis.
Platform enforcement is another possible confounder. TikTok states that it acts against fake engagement and has removed fake followers and prevented fake follow requests. This means an SMM provider cannot guarantee permanent retention or protection from platform action.[2]
Step-by-Step Application
Confirm the Terms Before Ordering
Record the service name, service ID, refill wording and stated retention window. Confirm which event starts the window and whether the terms identify target-access, targeting or order-status conditions.
Do not rely on a general promise elsewhere on the website when the selected service has its own description. Provider-specific periods or exclusions should only be treated as valid when they appear in the applicable terms.
Capture the Baseline and Order Details
At submission, save the order ID, target, targeting option, ordered quantity, starting count and timestamp. Use the same timezone throughout the record.
If the provider captures its own starting count, retain that value. A separate timestamped account snapshot can provide supporting context but should not silently replace the provider’s recorded baseline.
Follow Delivery and Status Changes
Record each meaningful status change shown in the dashboard or API. Keep the delivered quantity separate from the ordered quantity.
For a partial or canceled order, use the provider’s recorded delivery information when evaluating the count change. A request for 1,000 followers does not prove that 1,000 were delivered.
Record Comparable Count Snapshots
Take observations from the same source where possible. A consistent daily snapshot is more useful than several irregular screenshots with unknown times.
Keep the full timestamps. A date without a time may be insufficient when delivery, completion and a count change occurred on the same day.
Prepare the Buyer-Side Evidence Checklist
| Evidence | What to preserve |
|---|---|
| Relevant order ID | The exact order connected to the claim |
| Service terms | The refill language and conditions active for that service |
| Starting count | The recorded baseline and its timestamp |
| Delivered count | The provider-reported quantity actually delivered |
| Status history | Processing, partial, completion, cancellation or refill records as displayed |
| Observation timestamps | The time of every account-count observation |
| Current count | The most recent count from the same observation source |
| Stated refill window | Its duration plus the event that starts it |
Turning the Result Into an Action
First classify the record as an observed count change, a documented drop, an active-window observation or a potentially eligible refill request.
Submit the evidence with the order ID and describe the measured change without claiming certainty about its cause. Support can then compare the record with the applicable service conditions.
Keep the final support response and any resulting status changes. They complete the order history and prevent the same claim from being reconstructed from incomplete screenshots later.
Example and Decision Table
The following example is hypothetical and demonstrates the measurement method. It is not a Tiksta policy or a promise of refill eligibility.
Suppose an account has a starting count of 10,000. The panel later records 1,000 delivered and marks the order complete. A timestamped observation after delivery shows 10,850 followers. A later observation shows 10,600.
The account declined by 250 from the verified post-delivery observation. Using the provider-reported delivery as the denominator produces a recorded rate of 25%. Using the observed increase of 850 produces approximately 29.4%.
Neither calculation is automatically correct for a refill decision. The applicable service terms determine the required baseline, denominator, window and conditions. The example documents a count change but does not prove which followers disappeared.
| Record state | Supported classification | What remains unresolved |
|---|---|---|
| One lower count with no reliable baseline or timestamp | Observed count change | Size, timing and attribution of the drop |
| Consistent starting, post-delivery and current snapshots | Documented drop between observations | Whether the lost followers came from the order |
| Documented drop inside a verified service window | Active retention-window observation | Whether every eligibility condition is satisfied |
| Documented drop, active window, matching order and applicable conditions | Potentially eligible refill request | Provider review and final outcome |
| Partial or canceled order | Order with incomplete or interrupted fulfillment | Actual delivered quantity and applicable policy treatment |
| Current count below the original starting count | Total account loss exceeds the observed order-period gain | Which losses relate to the order, earlier followers or other activity |
| Concurrent orders on the same target | Overlapping delivery record | Which order contributed to each count change |
| Removed, private or restricted target | Measurement interruption | Current count, continued access and any applicable service condition |
Limitations and Misinterpretations
A Refill Guarantee Does Not Prevent Drops
A refill guarantee describes a possible remedy under stated conditions. It does not prevent count changes or establish permanent retention.
A Retention Window Is Not a Stability Promise
A retention window defines the period used for observation or claim review according to the service terms. It does not promise that followers will remain for its full duration.
Completed Does Not Mean Permanent
A completed status records a provider-side order state. It does not establish permanent retention or prove that the visible account count increased by the same amount.
Ordered Quantity Is Not Always Delivered Quantity
Partial delivery and cancellation must be evaluated through the status history. The originally requested quantity cannot replace the provider’s actual delivery record.
Count Changes Do Not Prove Attribution
A lower current count does not automatically equal an order-specific drop. Organic audience changes, overlapping orders and platform removals can affect the same total.
A count below the original starting count is especially difficult to attribute. The account has lost more than the measured gain above that baseline, so an aggregate count cannot identify which follower group disappeared.
Concurrent orders create the same attribution problem. Two services, providers or targeting selections may affect one visible count while producing separate dashboard records.
Target Changes Can Interrupt Measurement
Removed or restricted targets can interrupt both delivery and measurement. A changed username or inconsistent target reference can also disconnect screenshots from the original order record.
Observation Times and System Records May Differ
Inconsistent observation times weaken the timeline. Comparing a morning baseline with an evening count several days later may capture unrelated account activity that occurred between those observations.
Dashboard and API records may also update at different times. A public count, provider status and API response should not be treated as perfectly synchronized unless the provider documents that behavior.
Next Measurement and Related Resources
After a refill review, preserve the final status, response timestamp, any replacement quantity and the next account-count observation. This creates a complete record of the original delivery, documented change and provider decision.
For recurring orders, use the same fields and observation schedule each time. Compare only orders with compatible services, targeting conditions, statuses and retention windows.
The next decision should be based on the written service conditions and the quality of the evidence record. The purpose of the measurement is not to force a refill conclusion. It is to show what changed, which order may apply and what support needs to evaluate the claim consistently.
Sources
TikTok for Developers. “Query User Info.” Current documentation reviewed September 20, 2026.
TikTok Newsroom. “How TikTok Counters Deceptive Behaviour.” Current page reviewed September 20, 2026.
