Preparing a CSV or TXT File for Bulk Phone Number Checks

A technical workflow guide for preparing and processing a bulk phone number check CSV TXT file using a synchronous API, focusing on E.164 formatting and rate limit management.

To process a bulk phone number check CSV TXT file for Telegram registration verification using TG Validator, you must format all numbers in the E.164 standard. Because the platform operates as a synchronous, single-identifier API, bulk lists are processed by iterating through your file client-side. Your implementation must manage the request flow to respect the 200-requests-per-minute rate limit and the 3-concurrent-checks limit. Each successful request returns an account-presence signal indicating Telegram registration status at the time of the check.

Preparing Your Data for Verification

When preparing a CSV or TXT file for verification, every phone number must be formatted according to the E.164 standard. This international numbering plan requires a plus sign followed by the country code and the subscriber number. TG Validator strictly requires E.164 formatting for all inputs. Ensuring your list adheres to this standard before initiating checks supports accurate processing and avoids invalid phone number errors.

Understanding the Synchronous Workflow

TG Validator is a focused Telegram-verification product that operates synchronously. This means it does not support asynchronous batch uploads or native file processing. Instead, one request returns one result in the same HTTP response. To process a bulk list, your client-side application must read the CSV or TXT file and submit each number individually to the POST /api/v1/check endpoint. The request requires an X-API-Key header and a JSON body containing "service_type": "tg" and the "identifier" field with the E.164 number.

Managing API Limits and Performance

Because you are iterating through a list, your script must handle API usage controls safely. The public API enforces a 200-requests-per-minute rate limit and a 3-concurrent-checks limit per user. If your script exceeds these thresholds, the API returns specific error codes for rate limit exceeded or all concurrency slots occupied. Rate and concurrency limit rejections are not charged and create no check result. Implementing client-side throttling and retry logic helps keep your bulk processing within these documented boundaries. Billing is per check, and any failed or undetermined checks are refunded automatically.

Interpreting Registration Results

Each successful check returns a documented code, message, and data response envelope. For Telegram checks, the service_type=tg request returns the registration status in the data.registered field. This result acts strictly as an account-presence signal at the time of the check. You can monitor your overall processing progress, check history, and balance spend through the TG Validator dashboard, which supports usage reports and 7-day trends.

FAQ

What format should my phone numbers be in?

All phone numbers must be submitted in the E.164 format, which includes a plus sign, country code, and subscriber number.

Does TG Validator support batch file uploads?

No, the platform operates as a synchronous API where one request returns one result in the same HTTP response. Bulk lists must be processed client-side by submitting individual requests.

What does a registered status actually mean?

A registered result reports the Telegram registration status at the time of the check.

How do I handle rate limit errors?

Your client-side implementation should respect the 200-requests-per-minute rate limit and 3-concurrent-checks limit. Rejections for exceeding these limits are not charged and do not create a check result.