How to check Telegram phone-number registration in real time

The product answers one precise question

TG Validator checks whether the submitted phone number is registered on Telegram at the time of the request.

The product accepts one E.164 phone number, uses service_type=tg, and returns the completed result in the same HTTP response. There is no job ID to poll and no callback required before the application can read data.registered.

The scope ends with registration status. The response does not provide a Telegram username, profile, activity status, contacts, groups, or message data. It also does not identify the person who controls the phone number. These are not hidden features; they are outside the product contract.

A completed false is different from a failed check

Returned data	Registration decision	How to use it
status=success, registered=true	Registered at check time	Use true as this request's result
status=success, registered=false	Not registered at check time	Use false as this request's result
status=undetermined, registered=null	No registration decision	Do not create a boolean; no charge is kept

The distinction matters because registered=false is usable information produced by a completed check. An API error is returned through the outer envelope with its own HTTP status and numeric code; it is not another value of data.status or data.registered.

The synchronous request path

1. Prepare E.164 input — Start with known country context and normalize the number to a plus sign, country calling code, and digits.
2. Authenticate the request — Use an API key created in Settings and send it with the documented header.
3. Choose the Telegram product — Set service_type=tg; do not infer the product from unrelated fields.
4. Wait for the same response — The check is synchronous, so the application receives the decision without polling.
5. Read the exact result fields — Consume data.registered when data.status is success; leave it unset when the returned status is undetermined.
6. Record the check time — Treat the result as a current observation, not an indefinite guarantee.

Where real-time behavior helps

The synchronous contract is a good fit for software that needs one current registration decision before it continues. An operator can check a record in the dashboard, an internal application can validate a submitted number, or a backend worker can process records one at a time.

For a larger list, the client still sends one number per request. The client owns scheduling, rate control, concurrency, and progress tracking. This preserves a simple API contract: every completed request has one input, one Telegram registration result, and one observation time.

A minimal application record

Use explicit fields instead of a vague valid label:

Field	Purpose
source_phone	Preserves what the source system supplied
e164_phone	Stores the canonical number that was checked
service_type	Records tg as the result contract
status	Preserves the returned success or undetermined result status
registered	Stores true/false only for completed checks
checked_at	Timestamps the registration observation

If an application needs a newer answer, it should make another synchronous call. It should not change the timestamp on an older value or claim that a cached value is real time.

The integration rule that prevents false data

data.status=success confirms that the registered boolean is the completed registration answer.

This two-stage interpretation keeps input problems and temporary service conditions out of the Telegram status field. It also makes the product promise precise: TG Validator provides a current registration observation synchronously when the check completes, while the integrating system decides when it needs a new observation.