Verification methodology
How TG Validator verifies a Telegram number
TG Validator accepts one E.164 phone number with service_type=tg and returns a synchronous Telegram registration result. This reference explains the request lifecycle, billing decision, retry states, and the limits of what a registration check can establish.
Reviewed July 21, 2026
What happens during a Telegram check?
A check validates the request, reserves the current tg product cost, submits one normalized number through the verification service, and returns the outcome in the same HTTP response. A completed true-or-false registration result keeps the charge. A failed, timed-out, or undetermined request returns the balance and must remain unclassified.
The request lifecycle from input to result
The dashboard and REST API share the same verification service, response envelope, balance, rate limit, and concurrency rules.
- 1
Normalize the identifier
Submit one phone number in E.164 form with its country code. Invalid fields are rejected before a verification attempt.
- 2
Send service_type=tg
The tg product asks one focused question: whether the submitted number is registered on Telegram at request time.
- 3
Reserve balance and run synchronously
The product cost is reserved before the request. The caller waits for the same HTTP response instead of polling a task or receiving a webhook.
- 4
Commit or refund
A completed registration result keeps the charge. A failed or undetermined attempt returns the reserved balance and records zero final charge.
Registration outcomes and control responses
A temporary technical response is not a Telegram registration decision. Use the response code before consuming data.registered.
| State | Meaning | Recommended action |
|---|---|---|
| Completed · registered=true | The check reported the number as registered on Telegram at request time. | Store the result with its timestamp. |
| Completed · registered=false | The check reported the number as not registered at request time. | Keep it distinct from invalid or failed requests. |
| 400 | The request body, service type, or phone number is invalid. | Correct the input before retrying. |
| 402 | The account does not have enough balance for the check. | Top up before resubmitting; no registration decision exists. |
| 429 | The per-user rate or concurrency limit was reached. | Back off and queue excess work. |
| 503 or undetermined | No usable decision was produced. | Retry later and never coerce the outcome to false. |
Billing, limits, and retries belong to one contract
Dashboard and API calls draw from the same balance and share per-user controls, which prevents parallel tools from bypassing the published limits.
- Only completed checks retain a balance charge; failed and undetermined attempts are refunded.
- A user can run up to three checks concurrently.
- Dashboard and API use share a limit of 200 requests per minute.
- After 429, wait and increase the delay if the next attempt is also limited.
- After 503, preserve the pending row and retry later.
What the result cannot establish
A registration check is a point-in-time data-quality signal. It does not expose private Telegram content or create a lawful basis for outreach.
- It does not identify the person controlling the phone number.
- It does not reveal messages, chats, groups, contacts, activity, or last seen information.
- It does not guarantee message delivery or future registration status.
- It does not grant consent to contact the person or override recipient preferences.