Result guide
How to interpret Telegram verification results
TG Validator separates a completed Telegram registration decision from invalid input, rate limits, insufficient balance, and temporary failures. A robust integration preserves these states instead of reducing every non-true response to false.
Reviewed July 21, 2026
What does registered mean?
registered=true means a completed tg check reported the submitted E.164 number as registered on Telegram at request time. registered=false means the completed check reported it as not registered. A timeout, 429, 503, or undetermined response contains no true-or-false decision and should remain pending for correction or retry.
Classify the response before reading data.registered
The response envelope explains whether a usable registration result exists. Technical control responses must not alter the last known completed status.
| Response | Classification | Store as |
|---|---|---|
| Success + registered=true | Completed registered result | registered=true with timestamp |
| Success + registered=false | Completed unregistered result | registered=false with timestamp |
| 400 | Invalid body, service type, or phone | Input error requiring correction |
| 402 | Insufficient balance | Billing block; no registration decision |
| 429 | Rate or concurrency limit | Retryable control response |
| 503 or undetermined | Temporary service outcome | Pending/retry; never false |
Use a three-state business model
Registered, unregistered, and pending are materially different. Keeping them separate prevents outages and malformed data from suppressing valid contacts.
- 1
Completed registered
Store true, service_type=tg, and the verification timestamp.
- 2
Completed unregistered
Store false with the same audit fields; it is not an input error.
- 3
Pending or retryable
Use for 429, 503, timeouts, and undetermined responses while preserving any previous completed status.
- 4
Rejected input
Return invalid phone or request errors to the normalization pipeline.
Decide when to re-check
Registration status is point-in-time data. The appropriate review window depends on why the organization uses the result and how costly a stale decision would be.
- Record verified_at on every completed decision.
- Do not silently replace a previous completed status with a temporary failure.
- Re-check before time-sensitive routing when the stored result is older than the workflow's policy.
- Avoid continuous polling when no business decision needs a newer value.
Conclusions outside the response scope
The tg product reports registration status only. It does not provide private account content or permission evidence.
- It does not identify the owner of the number.
- It does not reveal messages, chats, groups, contacts, activity, or last seen.
- It does not guarantee future registration or message delivery.
- It does not grant consent to contact the number.