Use-case playbook
A safe Telegram contact list cleaning workflow
A reliable Telegram list-cleaning process preserves source rows, normalizes phone numbers, removes duplicates, checks registration, separates retryable failures from completed false results, and combines the technical status with consent and suppression rules.
Reviewed July 21, 2026
What should a cleaned contact record contain?
Keep the original number, normalized E.164 value, normalization status, completed Telegram result or retry state, verification timestamp, and final routing decision. Invalid input, registered=false, and a temporary service failure require different actions and must never share one generic rejected value.
Build a staged and reversible pipeline
Each stage should add structured evidence while keeping the original value available for correction.
- 1
Preserve the source
Assign a stable row ID and retain the original phone value, source, import time, and country context.
- 2
Normalize and deduplicate
Create one E.164 value, flag ambiguous rows, and group duplicates by the canonical identifier.
- 3
Run service_type=tg
Send one normalized number per synchronous request and checkpoint each completed row.
- 4
Classify the outcome
Separate registered, unregistered, invalid, retryable, and billing-blocked records.
- 5
Apply routing policy
Combine registration with consent, suppression, recipient preferences, and applicable rules before outreach.
Recommended output model
Structured output supports targeted retries and audits without repeating completed checks.
| Field | Purpose | Example |
|---|---|---|
| source_phone | Preserves the imported value | +1 (415) 555-2671 |
| normalized_phone | Canonical request and deduplication key | +14155552671 |
| normalization_status | Separates valid and ambiguous input | valid / needs_review |
| verification_status | Separates completed and operational states | registered / unregistered / retry |
| verified_at | Dates the point-in-time decision | ISO 8601 timestamp |
| routing_decision | Records the action and reason | keep / suppress / review |
Respect synchronous limits when processing a list
The API accepts one phone number per request. Use a bounded worker queue instead of releasing the entire file at once.
- Keep no more than three checks in flight per user.
- Stay within 200 requests per minute across dashboard and API.
- A 429 is not charged; retry it after the window or concurrency slot recovers, and retry 503 or undetermined rows later.
- Do not retry completed registered=false rows unless a newer status is required.
- Checkpoint progress so interrupted jobs resume without replaying completed rows.
Registration is not outreach permission
A registered result improves routing data but does not establish identity, lawful purpose, or consent.
- Apply opt-out and suppression lists after normalization so formatting differences cannot bypass them.
- Restrict exported phone and result fields to systems that need them.
- Set a review policy appropriate to the workflow instead of assuming results remain current forever.
- Store consent source and recipient preferences separately from the Telegram result.