DEV Community: eKYC Pro

Building Decision-Support Logic with the Threads Checker API

eKYC Pro — Mon, 10 Aug 2026 01:27:44 +0000

In modern software development, we often treat external API responses as binary truths. When integrating identity or registration signals, it is tempting to use a simple if (registered) { grantAccess() } pattern. However, treating a platform registration signal as an absolute source of truth is a common pitfall. Instead, developers should treat these signals as one component of a broader, custom-defined user validation strategy.

The Role of Registration Signals

When using the Threads Checker API, you receive a signal indicating whether a specific phone number is associated with a Threads account. This is a powerful data point, but it is not a proxy for identity verification or fraud prevention. It is a registration signal—a piece of evidence that helps you refine your own internal decision-making logic.

Implementation: Integrating the Threads Checker

To integrate this signal into your application, you interact with the POST /v1/check endpoint. This is a synchronous request-response flow. Here is how you can structure your integration layer:

1. Define Your Adapter

Encapsulate the API call to ensure you handle the response consistently. The API requires an X-API-Key header and a JSON body containing the service_type and identifier.

// Conceptual integration structure
{
 "service_type": "threads",
 "identifier": "+1234567890"
}

2. Normalize the Response

Your application logic should interpret the data.registered boolean as a signal to be weighted alongside other factors, rather than an immediate trigger for user lifecycle events.

Success (200): The request completed successfully. You receive a data.registered boolean and a data.checked_at timestamp.
Error Handling: Be prepared for 400 (Bad request), 401 (Unauthorized), or 500 (Internal server error) statuses. Always implement robust error handling rather than assuming the service will always return a successful payload.

Decision-Support vs. Absolute Truth

Why treat this as decision support?

Context Matters: A registration signal confirms account existence, not the intent of the person holding that account.
Multi-Layered Strategy: By combining registration signals with other internal checks (such as account age, historical behavior, or custom risk thresholds), you build a more resilient system than one relying on a single third-party signal.
Evidence-Based Design: Just as passing a unit test doesn't guarantee your code is bug-free, receiving a registered: true response doesn't guarantee the user is who they claim to be. Use the data to inform your risk engine, not to automate final business outcomes.

Conclusion

Integrating the Threads Checker API is straightforward, but its value is maximized when you treat the output as a supporting signal. By building an abstraction layer around the v1/check endpoint, you can easily incorporate this data into your custom validation workflows, ensuring your application remains flexible and evidence-based.

This article was drafted with AI assistance and reviewed before publishing.

Read the eKYC Pro API docs

How to Integrate Instagram Email Verification into User Onboarding

eKYC Pro — Sun, 09 Aug 2026 01:25:40 +0000

When building user onboarding flows, verifying the legitimacy of provided contact information is a critical step in maintaining platform integrity. For applications that rely on social identity, checking whether an email address is already associated with an Instagram account can provide a valuable signal to help guide your registration logic.

This guide walks through implementing a synchronous check for Instagram email registration status using the Per-call API.

1. Security First: Managing API Credentials

Before writing code, ensure your API keys are handled securely. Never hardcode your X-API-Key in your source code or commit it to version control.

Environment Variables: Store your key in a .env file or your CI/CD provider's secret manager.
Access Boundaries: Ensure your server-side code is the only layer that interacts with the API, preventing your secret from being exposed to the client-side browser environment.

2. Implementation Workflow

To perform an Instagram email check, you will send a POST request to the /v1/check endpoint. The integration follows a synchronous request-response pattern.

The Request Structure

Your application should construct a JSON payload specifying the service_type as instagram_email and the identifier as the user's email address.

{
 "service_type": "instagram_email",
 "identifier": "user@example.com"
}

Handling the Response

The API returns a JSON object containing the registered boolean. This signal serves as a supporting account-presence indicator for your internal onboarding logic.

{
 "success": true,
 "data": {
 "id": "chk_a1b2c3d4e5f6",
 "identifier": "user@example.com",
 "registered": true,
 "billed": true
 }
}

3. Integration Checklist

When implementing this in your backend, keep the following patterns in mind:

Validation: Ensure the email format is valid before sending the request to avoid unnecessary 400 Bad Request errors.
Error Handling: Implement robust checks for 401 Unauthorized (check your key rotation) and 500 Server Error statuses to handle API availability gracefully.
Signal Normalization: Treat the data.registered boolean as a single data point. Combine this with your internal application state to decide whether to trigger additional verification steps or proceed with account creation.

Conclusion

By integrating a platform-registration check into your onboarding, you can better understand the context of your incoming users. Always remember to treat these signals as supporting data points within your broader registration workflow, and keep your API keys secured within your server-side environment.

For more details on the available endpoints, refer to the official documentation.

This article was drafted with AI assistance and reviewed before publishing.

Designing Identity Guardrails: Input Validation vs. Risk Scoring

eKYC Pro — Sat, 08 Aug 2026 01:24:12 +0000

When building user onboarding flows, developers often face a critical architectural decision: where to place identity verification checks. Should you validate inputs at the point of entry, or should you rely on aggregated risk signals before granting access? Understanding the distinction between per-service signals and unified scoring is essential for building robust, operator-safe onboarding guardrails.

The Anatomy of an Identity Check

In a single-identifier workflow, you are typically verifying a phone number or email against specific platform registries.

Per-Call Service Signals

Per-call services, such as the Instagram Checker API, provide a direct, synchronous account-presence signal. When you submit an identifier via POST /v1/check, you receive a boolean response indicating whether that identifier is registered on the selected platform.

// Example of a per-call service check
{
 "service_type": "instagram",
 "identifier": "+1234567890"
}

This approach is ideal for granular, service-specific validation. However, because it is a point-in-time check, it serves as a supporting signal rather than a definitive proof of identity.

Aggregated Risk Scoring

Alternatively, the Unified Score API provides a broader perspective by combining supported signals into a 0–1000 PTS score, accompanied by a risk label (LOW, MEDIUM, or HIGH). While per-call services tell you if an account exists on a specific platform, the Unified Score offers a synthesized metric that acts as a decision-support tool for your internal logic.

Architectural Considerations: Input vs. Output Guardrails

When implementing these checks, consider the "Guardrails" pattern:

Input Filtering (Pre-Check): Use basic validation to ensure the identifier (e.g., E.164 phone format) is well-formed before hitting the API. This prevents unnecessary 400 Bad Request errors and reduces operational noise.
Output Filtering (Post-Check): Once you receive a response, treat the result (e.g., data.registered) as a variable in your decision engine.

Error Handling and Resilience

Because these checks are synchronous, your application must be prepared to handle various failure modes gracefully:

401 Unauthorized: Ensure your X-API-Key is managed via secure environment variables and rotated periodically.
500 Server Error: Implement a fallback mechanism. If the verification service is unreachable, your system should fail closed or open based on your specific risk tolerance for that onboarding step.

Decision Checklist

When choosing between these approaches, ask yourself:

Do I need platform-specific presence? Use Per-call services (e.g., Instagram, WhatsApp) to confirm if an account exists.
Do I need a normalized risk metric? Use the Unified Score API to obtain a PTS score for broader decision support.
Is the check critical? If the check is a mandatory guardrail, ensure your application logic accounts for potential API downtime by having a clear policy for when a check fails to return a success: true status.

By separating your concerns—using per-call signals for specific platform verification and unified scores for aggregate risk assessment—you create a more maintainable and resilient onboarding pipeline.

This article was drafted with AI assistance and reviewed before publishing.

Explore eKYC Pro per-call APIs

How to Validate User Presence with the WhatsApp Checker API

eKYC Pro — Fri, 07 Aug 2026 01:18:08 +0000

In modern onboarding flows, verifying that a user has an active account on a specific platform is a common requirement. Whether you are building a communication-heavy application or a verification service, checking for account presence helps ensure that your downstream messaging efforts are directed toward reachable users.

This guide explores how to integrate the WhatsApp Checker API to perform synchronous registration checks using phone identifiers.

Understanding the Integration Boundary

The WhatsApp Checker API follows a request-response pattern. You submit a phone number in E.164 format, and the service returns a registration signal. This is a "phone-first" workflow, meaning each request handles a single identifier.

Step 1: Setting Up Your Environment

Before implementing the API call, ensure you have your X-API-Key ready. Since this is an external integration, it is best practice to store your credentials in environment variables rather than hardcoding them into your application logic.

Step 2: Implementing the API Call

To check if a number is registered on WhatsApp, send a POST request to the /v1/check endpoint. The payload requires the service_type set to ws and the identifier string.

curl -X POST 'https://api.ekycpro.com/v1/check' \
-H 'X-API-Key: YOUR_API_KEY' \
-H 'Content-Type: application/json' \
-d '{"service_type": "ws", "identifier": "+1234567890"}'

Step 3: Handling the Response

A successful request returns a JSON object containing the data.registered boolean. This serves as your primary signal for account presence.

success: A boolean indicating if the request completed.
data.registered: The core signal confirming if the identifier is associated with a WhatsApp account.
data.id: A unique identifier for the check request, useful for logging and auditing.

Step 4: Testing and Sandboxing

When building integrations, you should avoid hitting production endpoints with live user data during early development. Instead, implement a mock adapter layer in your testing suite. By creating a fixture file that mirrors the expected JSON structure, you can simulate various scenarios—such as successful registration, unregistered numbers, or API errors—without triggering actual billing events.

Mocking Example (Conceptual)

// Example of a test fixture for your integration layer
const mockWhatsAppResponse = {
 "success": true,
 "data": {
 "id": "chk_a1b2c3d4e5f6",
 "identifier": "+1234567890",
 "registered": true,
 "billed": true
 }
};

By decoupling your application logic from the API response, you can write unit tests that validate how your system handles the data.registered boolean without needing a constant network connection.

Conclusion

Integrating the WhatsApp Checker API provides a straightforward way to verify account presence. By focusing on a clean integration boundary and robust testing with fixture files, you can build reliable onboarding workflows that effectively utilize platform registration signals. For more details on the API contract, refer to the official documentation.

This article was drafted with AI assistance and reviewed before publishing.

Implementing Telegram Account Verification in Your User Onboarding Flow

eKYC Pro — Thu, 06 Aug 2026 01:19:52 +0000

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-Key is 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.

Building Reliable Business Account Verification with the WhatsApp Business Checker API

eKYC Pro — Wed, 05 Aug 2026 01:19:17 +0000

Verifying whether a phone number belongs to a legitimate business is a critical step in reducing fraud and ensuring high-quality user onboarding. When building verification workflows, you need a reliable way to confirm account presence without over-complicating your infrastructure.

In this tutorial, we will walk through implementing the WhatsApp Business Checker API to programmatically validate business account status using a synchronous request-response flow.

Understanding the Integration

The WhatsApp Business Checker API allows you to submit a phone number and receive a signal indicating whether that number is registered on WhatsApp and if it is specifically configured as a business account. This is a "phone-first" integration, where each request processes a single identifier.

Prerequisites

An API key from eKYC Pro.
A development environment capable of sending POST requests.

Step 1: Preparing the Request

The API uses a standard POST request to the /v1/check endpoint. You must provide your API key in the X-API-Key header and define the service_type as ws_business in your JSON payload.

Ensure your phone number is formatted in E.164 (e.g., +1234567890) to avoid 400 Bad Request errors.

Step 2: Implementation Pattern

Below is a conceptual implementation of the check. When designing your integration, treat the returned signals as supporting data for your internal decision-making logic.

curl -X POST 'https://api.ekycpro.com/v1/check' \
-H 'X-API-Key: YOUR_API_KEY' \
-H 'Content-Type: application/json' \
-d '{"service_type": "ws_business", "identifier": "+1234567890"}'

Step 3: Handling the Response

The API returns a JSON object containing the verification results. Key fields to monitor include:

data.registered: Indicates if the number is on the platform.
data.business: The core signal indicating if the account is a WhatsApp Business profile.
data.id: A unique identifier for the check, useful for logging and debugging.

Testing and Sandboxing

When building your integration, implement a testing fixture that mocks these responses. Since the API is synchronous, your testing suite should handle the following scenarios:

Successful Verification: success: true with business: true.
Non-Business Accounts: success: true with business: false.
API Errors: Handle 401 Unauthorized (check your key) or 500 Server errors gracefully by implementing a retry strategy or alerting your monitoring system.

Conclusion

By integrating the WhatsApp Business Checker API, you gain a clear, synchronous signal to support your business account verification logic. Remember that this API provides supporting account-presence signals; always combine these with your own internal risk assessment to build a robust verification pipeline. For more details on endpoint specifications, refer to the official documentation.

This article was drafted with AI assistance and reviewed before publishing.

Handling API Errors in Synchronous Verification Workflows

eKYC Pro — Tue, 04 Aug 2026 13:28:32 +0000

When building integrations that rely on external identifier verification, the most robust systems are those that treat errors as expected application states rather than unexpected crashes. Whether you are performing a simple check or integrating complex scoring, handling the request-response lifecycle correctly is critical for maintaining a stable service.

Understanding the Synchronous Request Lifecycle

In a synchronous verification workflow—such as checking if a phone number is registered on a specific platform—your application sends a request and waits for a response. The POST /v1/check endpoint is a primary example of this pattern.

Because these checks rely on external signals, your code must account for the reality that not every request will return a successful result. A successful request returns a 200 status code, but your logic should be prepared for non-success scenarios.

Mapping HTTP Status Codes to Decision Logic

Effective error handling starts with categorizing the HTTP status codes returned by the API. Here is a recommended strategy for mapping these codes to your application logic:

1. The Success Case (200)

When you receive a 200 status, the check has completed. However, success at the transport layer does not always mean the identifier was verified. Always check the success boolean in the response body to confirm the outcome of the verification itself.

2. Client-Side Errors (400, 401)

400 Bad Request: This typically indicates an issue with your input, such as an incorrectly formatted phone number or a missing service_type field. Do not retry these requests; instead, log the validation error and notify the user or the upstream system that the input requires correction.
401 Unauthorized: This signals an issue with your X-API-Key. This is a configuration error that requires immediate attention from an operator. Ensure your key is correctly injected into the request headers.

3. Server-Side Errors (500)

500 Server Error: These indicate a temporary issue on the provider's side. This is where your application should implement a controlled retry strategy. Avoid aggressive loops; instead, use an exponential backoff approach to allow the service time to recover.

Implementation Pattern

When designing your adapter layer, encapsulate the API call to separate the transport logic from your business rules.

async function verifyIdentifier(identifier, serviceType) {
 try {
 const response = await fetch('https://api.ekycpro.com/v1/check', {
 method: 'POST',
 headers: {
 'X-API-Key': process.env.API_KEY,
 'Content-Type': 'application/json'
 },
 body: JSON.stringify({ service_type: serviceType, identifier: identifier })
 });

 if (response.status === 200) {
 return await response.json();
 } else if (response.status === 500) {
 // Handle transient failure with retry logic
 throw new Error('Transient server error');
 } else {
 // Handle permanent client errors
 throw new Error(`Request failed with status: ${response.status}`);
 }
 } catch (error) {
 // Log and manage failure states
 console.error('Verification failed:', error.message);
 }
}

Conclusion

Robust error handling is the difference between a brittle integration and a production-ready system. By distinguishing between permanent client errors and transient server issues, you can create a resilient workflow that provides meaningful feedback to your users while gracefully handling the inevitable hiccups of distributed systems. For more details on integrating these services, refer to the official documentation.

This article was drafted with AI assistance and reviewed before publishing.

Optimizing Multi-Service Identifier Verification with Combo Check APIs

eKYC Pro — Mon, 03 Aug 2026 14:44:28 +0000

When building identity verification flows, developers often face a choice: make multiple individual API calls to different services—increasing latency and complexity—or find a way to aggregate those signals. If you are managing user onboarding or account recovery, you need a reliable way to verify identifiers like phone numbers or emails across multiple platforms simultaneously.

In this guide, we will explore how to use a Combo Check API to perform multi-service verification in a single synchronous request-response flow.

The Challenge of Multi-Service Verification

Traditionally, verifying a user across platforms (like WhatsApp, Telegram, or VK) requires hitting separate endpoints for each. This creates a "waterfall" effect where the total time taken is the sum of all individual requests. Furthermore, managing partial failures—where one service might time out while others succeed—adds significant overhead to your application logic.

Implementing the Combo Check Workflow

Instead of managing multiple connections, the Combo Check API allows you to send a single request containing an identifier, and the system handles the distribution to your selected services in parallel.

1. Preparing Your Configuration

Before making calls, define your preferred services in your dashboard. This creates a "combo" configuration. If you need flexibility, the API allows you to override these settings dynamically per request.

2. Executing the Verification

Use the POST /v1/check/combo/phone or POST /v1/check/combo/email endpoints. Here is how you can perform a check with a dynamic service override using curl:

curl --location 'https://api.ekycpro.com/v1/check/combo/phone' \
--header 'X-API-Key: YOUR_API_KEY' \
--header 'Content-Type: application/json' \
--data '{
 "identifier": "+6281234567890",
 "service_types": ["ws", "telegram", "vk"]
}'

3. Handling the Response

The API returns a unified JSON object. Crucially, the system is designed to handle partial success. Even if one service returns an error (such as a timeout), the response will still contain the successful data from the other services.

Key fields to monitor in the response include:

data.results: An object containing the status of each service.
data.results.*.registered: A boolean or null value indicating if the identifier is registered.
data.results.*.error: Present only if a specific service failed (e.g., "timeout").
data.total_cost_usd: The total billing for the aggregated request.

Best Practices for Integration

Set Appropriate Timeouts: Since the system processes services in parallel, ensure your client-side timeout is set to at least 15 seconds to accommodate the processing window.
Manage Partial States: Always check the error field within individual service nodes. If a service returns a "timeout" error, you can choose to retry that specific check using the single-identifier /v1/check endpoint.
Monitor Balance: The system performs a pre-check of your balance against the total cost of the combo. If your balance is insufficient, the entire call will return a 402 status code.

Conclusion

Aggregating identity signals into a single request simplifies your architecture and improves the maintainability of your verification logic. By leveraging a Combo Check approach, you move away from managing complex asynchronous chains and toward a cleaner, synchronous integration pattern.

This article was drafted with AI assistance and reviewed before publishing.