Integrating identity signals into your registration process is a common requirement for modern B2B SaaS platforms. When you need to verify if a user's provided phone number is associated with a specific messaging platform, you need a reliable way to fetch that signal during your signup flow.
In this guide, we will walk through the implementation of the Telegram Checker API to validate account-presence signals using a synchronous request-response pattern.
Prerequisites
To begin, ensure you have your API key from the eKYC Pro dashboard. The Telegram Checker is designed as a single-identifier workflow, meaning each request handles one phone number at a time.
1. Preparing the Identifier
The API requires the phone number to be provided in E.164 format. Before sending the request, ensure your frontend or backend normalization layer strips non-numeric characters (except for the leading '+') to avoid 400 Bad Request errors.
2. Constructing the Request
Using the /v1/check endpoint, you can query the Telegram platform registration signal. The request must be sent as a POST with your X-API-Key in the header.
curl -X POST 'https://api.ekycpro.com/v1/check' \
-H 'X-API-Key: YOUR_API_KEY' \
-H 'Content-Type: application/json' \
-d '{"service_type": "telegram", "identifier": "+1234567890"}'
3. Handling the Response
The API returns a JSON object containing the registration status. It is important to treat this information as a supporting account-presence signal to inform your internal onboarding logic, rather than a deterministic proof of identity.
Success Response Structure
When the request reaches the server successfully (HTTP 200), you will receive a response similar to this:
{
"success": true,
"data": {
"id": "chk_a1b2c3d4e5f6",
"identifier": "+1234567890",
"registered": true,
"billed": true
}
}
-
data.registered: A boolean indicating whether the identifier is currently registered on Telegram. -
data.id: A unique identifier for the specific check request, useful for audit logging.
4. Error Handling and Status Codes
Robust integrations should account for standard HTTP error states. Always implement basic error handling for the following scenarios:
-
400 Bad Request: Typically indicates an incorrectly formatted identifier or missing
service_type. -
401 Unauthorized: Check that your
X-API-Keyis valid and correctly passed in the header. - 500 Server Error: Indicates an issue on the provider side; implement a standard retry policy if your application logic requires it.
Conclusion
By incorporating the Telegram Checker into your onboarding flow, you gain an additional data point to support your decision-making process. Remember that this tool provides a specific platform registration signal; for more complex requirements, consider how you might integrate other identifiers or scoring signals as your needs evolve. For full technical specifications, refer to the official documentation.
This article was drafted with AI assistance and reviewed before publishing.
Top comments (0)