Viber Activity Checker API Workflow for Automated Checks
Of all the checks in this stack, activity is the one whose data expires fastest. A format from March can still be trusted in July. An activity tier from March is a guess, because accounts go quiet on their own schedule. That is why the API route for Viber Activity is not a convenience. It is the core of the workflow. Viber Activity Checker is the ZelNum page tied to this job: Viber Activity Checker.
Quick answer
push the list through the API, receive the activity tier per record, and store it with a checked timestamp. Re-run on a schedule and compare tiers between runs. The output is not a single snapshot. It is a drift line: how many active rows went quiet, how many inactive came back.
The API workflow
- Submit the job. a single request per batch, record set attached and a stable record ID per row.
- Poll or receive callbacks. At low volume polling works fine; webhooks earn their keep when you act on results the moment they land.
- Store per record. Keep the activity tier, the country if relevant, and the checked timestamp together with the record ID.
- Compare one run to the next. Movement between runs is the real output of the pipeline.
Keep the first call small. Put a handful of records through, check that the response comes back in the shape you expect, then widen out.
Choosing the re-check cadence
Activity is the fastest-decaying field in the stack, so the schedule matters more than the volume of any single run. A cadence that fits the list beats a cadence that fits the calendar:
| List type | Suggested cadence | Why |
|---|---|---|
| List you send to regularly | Monthly baseline | Drift shows up between sends, while you can still act on it |
| List under periodic re-verification | Quarterly deep re-check | Enough movement between runs to make the drift line readable |
| Fresh import | Before the first send | Imported tiers start aging the day they are written; confirm them at the source |
Whatever interval you pick, keep it fixed. Comparing a January run to an April run is straightforward when the runs sit 90 days apart. Comparing a January run to a run that happened whenever someone remembered is not a trend, it is an anecdote.
Tracking the drift
Three consecutive quarterly checks, one after another:
| Run | Active | Inactive | Not on Viber |
|---|---|---|---|
| January | 58% | 27% | 15% |
| April | 54% | 31% | 15% |
| July | 51% | 34% | 15% |
(The numbers here are for illustration; they make no claim about product performance.)
The active share slides down while the inactive tier climbs. Those three rows amount to one warning that the list is cooling, and the campaign should be sized to match. A single registration check would never show this.
Reading the tiers as campaign inputs
Each tier maps to a different action, and the mapping shifts as the list matures.
| Tier | What it means | Default action |
|---|---|---|
| Active | The account exists and shows recent use | Send to the current campaign |
| Inactive | Registered on Viber but quiet | Hold back, or send a re-engagement touch first |
| Not on Viber | No Viber account on this number | Route to another channel |
The ratio between tiers is what sizes the send. A list where active rows still outnumber inactive ones can carry a full campaign. Once inactive approaches active, re-engagement and list hygiene move ahead of sending. We treat the active-to-inactive ratio as the single number worth watching between runs, because it moves before the campaign results do.
Webhooks or polling?
For most teams, polling at a short interval is the easier path. Should you go with webhooks, build the callback to be idempotent: the same event arriving twice can neither double-charge nor write twice. And a single missed callback must never spawn a second paid job or let a blank response clobber a clean result.
Export fields worth keeping
| Field | Why you need it |
|---|---|
record_id |
Ties each result to its source row. |
activity_tier |
Active / inactive / not on Viber. |
checked_at |
The timestamp that makes the drift line possible. |
status / reason |
The routing decision and why. |
Drop checked_at and the pipeline stops being a time series. Keep it and every future run adds to the trend.
Keeping the activity tier in sync with the record
An activity tier is one column in a contact record, and it ages alongside the others. A number can read active on Viber in January and disconnected by April, and the porting mechanics behind why carrier data goes stale apply to Viber reachability the same way they apply to SMS routing. Re-checking activity on a schedule while the phone data underneath stays frozen means the two answers slowly stop agreeing.
The fix is to run the underlying checks in the same cycle. A validation pass over the same list refreshes the phone fields, and if a row reads not on Viber and you are unsure whether it was ever a real account, the registration-level tools compared in best Viber number checkers answer that question separately. One job per list per cycle keeps every column timestamped from the same day, which is what makes the drift line honest.
Mistakes to avoid
- Automating the check but not the response. A chart nobody reads is decoration. Route the tiers into the campaign workflow, or the schedule is just a report generator.
- Treating the last run as the current truth. An active tier from March is a guess by July.
- Comparing runs without timestamps. Two snapshots without checked timestamps are just two numbers; the trend needs the time axis.
When results look wrong
Most results that look bad trace back to inputs rather than to the check itself. The patterns below cover the ones we see most, and none of them require rebuilding the pipeline.
- Sudden swings between runs. Compare the checked timestamps first. If a run went out against a different list version, the drift is in the input, not the audience.
- A large unknown share. Unknowns cluster around formatting problems and throttled requests. The intake-side checks in bulk phone number validation prevent most of them. Retry the rest on the next run instead of treating them as failures.
- A not-on-Viber share that keeps growing. This often means a list that aged out of the market entirely. Cross-check a sample against other channel data before writing off the whole list.
Handling these well is a matter of reading the export the same way you read campaign data: with the time axis attached and the input version noted. Do that and the anomalies usually explain themselves.
FAQ
Why is the schedule the core of an activity check?
Because activity decays on its own. The value of the API is that it re-checks on a schedule and shows the drift, and drift is what the campaign decision runs on.
How often should the API run?
Monthly is a good baseline for a list you send to regularly; quarterly for a deep re-check. Which interval you pick matters less than having a fixed one at all.
Webhooks or polling?
Polling, for most teams. It is simpler, has fewer failure modes, and at low volume the latency costs you nothing.
What does the drift line tell me?
It tells you whether the list is cooling or warming, and at what rate. That is the input for sizing the campaign and timing re-engagement.
What happens to unknown rows?
They are queued for another run. An unknown isn’t a dead row; a later run often settles it.
Related ZelNum pages
- Viber Activity Checker Use Cases shows how various teams interpret one export.
- Bulk Viber Activity Checker: the batch-file guide walks through the file format.
Julian works on verification API integrations, batch jobs, CSV workflows, task polling, retry handling, result exports, and developer documentation. His guides explain how teams can integrate verification APIs safely and connect results with internal data systems.
View full author profile →