DEV Community: eKYC Pro

Tutorial: Building a Credit-Aware Verification Pipeline

eKYC Pro — Mon, 21 Sep 2026 22:55:33 +0000

In high-volume identity verification workflows, unexpected service interruptions can disrupt the user experience. When integrating verification services, it is critical to implement proactive checks to ensure your account has sufficient resources before triggering a request. This tutorial demonstrates how to build a credit-aware gate using the Balance API to prevent unnecessary failures.

The Problem: Proactive Resource Management

When you rely on synchronous APIs for identity signals—such as checking platform registration or risk scores—a lack of available credits can lead to service errors. By implementing a pre-flight balance check, you can gracefully handle account states before attempting a verification task.

Step 1: Implementing the Balance Check

Before executing your primary verification logic (such as a Per-call or Unified Score request), your application should verify that your account balance is sufficient. Using the GET https://api.ekycpro.com/v1/balance endpoint, you can retrieve your current credit status.

Conceptual Implementation

# Conceptual logic for a credit-aware gate
def check_and_verify(identifier):
 # 1. Query current balance
 balance_data = fetch_account_balance()

 if balance_data['balance'] > MINIMUM_REQUIRED_CREDITS:
 # 2. Proceed with verification only if balance is sufficient
 return perform_verification(identifier)
 else:
 # 3. Handle insufficient funds gracefully
 log_error("Insufficient credits to proceed")
 return None

Step 2: Handling API Responses

When calling the Balance API, ensure your integration handles the documented status codes:

200: The request was successful, and the balance field provides your current credit count.
401: Check that your X-API-Key header is correctly configured.
502: This indicates a failure in the balance query. Implement a retry strategy or a fallback mechanism to prevent your primary pipeline from stalling.

Step 3: Integrating into Your Workflow

By placing this check at the start of your request pipeline, you create a "go/no-go" gate. This pattern is particularly useful for:

Unified Score API: Ensuring you have the resources to pull risk signals for a user.
Combo Check API: Validating your budget before applying a group of selected services to an identifier.
Per-call Services: Preventing 502 errors by confirming credit availability before requesting service-specific registration signals.

Conclusion

Integrating a balance check is a simple but effective way to improve the reliability of your identity verification pipeline. By treating your account balance as a prerequisite for your API calls, you can reduce failed requests and maintain a smoother integration. For more details on the available endpoints, refer to the official documentation.

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

Integrating Telegram Number Checks into Synchronous Risk Workflows

eKYC Pro — Mon, 21 Sep 2026 03:21:56 +0000

When building onboarding flows, developers often need to verify account presence without overstepping into identity verification. Using a synchronous check to confirm whether a phone number is associated with a specific platform like Telegram allows you to add a layer of validation to your risk-review process.

This guide explores how to integrate these checks into your application while treating the returned signal as an account-presence indicator rather than universal identity proof.

1. Understanding the Integration Boundary

When you submit a phone number to a checker service, you receive a signal indicating if that identifier is registered on the platform. It is critical to treat this result as a supporting signal for your own customer-defined decision logic.

Because these checks are synchronous, your application waits for the response before proceeding. This makes them ideal for inline risk-review steps, such as toggling specific UI features or flagging accounts for manual review.

2. Implementing the Request Pattern

To perform a check, your application sends an identifier to the API endpoint. The request must include your authentication credentials in the X-API-Key header.

Implementation Checklist:

Format the Identifier: Ensure the phone number is provided in E.164 format to ensure compatibility.
Define the Service: Specify the target platform type in your request body.
Handle the Response: Parse the success boolean to confirm the request completed, then inspect the registration signal to update your local application state.

3. Error Handling and Resilience

Robust integrations must account for potential failures during the request cycle. Since the API operates on a request-response flow, your code should be prepared to handle standard HTTP status codes:

400 (Bad Request): Verify your request body and identifier format.
401 (Unauthorized): Check that your X-API-Key is valid and present in the request header.
500 (Server Error): Implement a retry strategy using an exponential backoff approach to avoid overwhelming the service during transient issues.

4. Designing for Failure

Never assume that a missing registration signal implies a user is invalid. If the API returns an error or a negative registration result, your system should default to a safe state—typically by allowing the user to proceed with additional verification steps or flagging the account for a human-in-the-loop review.

By keeping the registration check as one of many signals in your risk-scoring pipeline, you maintain a balanced approach to security that doesn't rely on a single point of failure.

Conclusion

Integrating platform registration checks provides a valuable tool for modern risk workflows. By treating these signals as account-presence indicators and implementing rigorous error handling, you can enhance your onboarding experience while maintaining a clear distinction between platform registration and verified identity.

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

Explore eKYC Pro per-call APIs

Structuring Image Profile Data: Normalizing Portrait Attribute Responses

eKYC Pro — Sun, 20 Sep 2026 03:22:42 +0000

When building automated profile management systems, integrating computer vision APIs introduces a common architectural challenge: handling conditional response data. The Image Profile API provides valuable insights into portrait attributes, but because it handles a wide variety of inputs—from high-quality individual portraits to group photos or abstract avatars—the response schema is inherently dynamic.

To ensure your application remains resilient, you must implement a robust normalization layer that treats portrait attributes as optional rather than guaranteed.

Understanding the Data Boundary

The Image Profile API returns structured data based on the model's ability to identify specific features. According to the official documentation, fields like age and gender are only returned when the model can confidently identify the subject. If you submit a group photo or a landscape, these fields may be omitted entirely from the response.

The Normalization Checklist

Before passing API results to your downstream business logic, apply these three rules:

Always Check success First: Never assume the presence of a data object. If success is false, the request could not be processed and no attributes will be available.
Defensive Field Access: Treat age and gender as nullable. If your application requires these fields for user categorization, define a fallback value (e.g., unknown or null) to prevent runtime errors.
Category-Aware Logic: Use the category field to determine the reliability of the other attributes. An individual portrait provides high-confidence data, while a group photo or cartoon avatar should trigger a different path in your application logic.

Implementation Pattern

Instead of mapping the API response directly to your database, create an adapter layer. This layer acts as a buffer, ensuring your internal system only receives a schema it understands.

// Conceptual: Adapter pattern for normalizing portrait attributes
function normalizeProfileData(apiResponse) {
 if (!apiResponse.success) {
 return { status: 'unprocessed', attributes: null };
 }

 const { data } = apiResponse;

 return {
 status: 'success',
 // Use default values for missing attributes
 age: data.age ?? 'not_detected',
 gender: data.gender ?? 'unknown',
 category: data.category,
 // Ensure consistent types for downstream consumption
 isIndividual: data.category === 'individual portrait'
 };
}

Testing Your Integration

Testing your normalization logic is critical because you cannot control the input images provided by users. Create a suite of fixture files that represent the different category types:

Positive Case: An individual portrait that returns all expected fields.
Edge Case: A group photo where age and gender are missing.
Failure Case: An invalid image URL that returns success: false.

By mocking these responses during your unit tests, you can verify that your application handles missing fields gracefully without crashing or defaulting to incorrect business logic.

Conclusion

Robust integrations are built on the assumption that external APIs may return partial or unexpected data. By implementing a normalization layer that accounts for the conditional nature of portrait attributes, you create a stable foundation for your profile management system. Always refer to the Image Profile API documentation to stay updated on the latest response structures and field definitions.

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

Handling Threads Checker API Failures: A Defensive Integration Approach

eKYC Pro — Fri, 18 Sep 2026 03:21:49 +0000

When integrating external identity signals like the Threads Checker API into your onboarding or risk-review workflows, your application must distinguish between valid identification signals and transient service-side states. Relying on a single, happy-path assumption can lead to unnecessary friction for your users.

Understanding the Integration Boundary

The Threads Checker API provides a synchronous request-response flow for verifying account presence. As with any service relying on third-party platform signals, you may encounter scenarios where the service is temporarily unavailable.

For example, a request might return a success: false response with an error message indicating worker threads: server too busy. This is a clear signal that the service is currently experiencing high load, rather than an indication that the phone number is invalid.

Implementing Defensive Logic

To build a resilient integration, your adapter layer should separate input validation errors from transient service errors.

1. Security and Credential Handling

Always manage your X-API-Key using secure environment variables or a dedicated secret management vault. Never hardcode credentials in your source code. When your application receives an error response, ensure your logging mechanism does not inadvertently leak these credentials or PII (Personally Identifiable Information) into your monitoring logs.

2. Error Categorization

Instead of treating every success: false result as a failure of the input data, categorize your responses:

Input Validation (400): The identifier format is incorrect or the service_type is unsupported. These should be flagged for user correction.
Authentication (401): The X-API-Key is missing or invalid. This requires an immediate infrastructure check.
Transient Service State: The API returns a failure due to server-side capacity. This is where your defensive logic should trigger a graceful fallback.

3. Conceptual Fallback Pattern

// Conceptual: Defensive integration pattern
async function verifyThreadsPresence(phoneNumber) {
 const response = await callThreadsApi(phoneNumber);

 if (response.success) {
 return response.data.registered;
 }

 if (response.error.includes("server too busy")) {
 // Log the transient issue and trigger a fallback policy
 // e.g., queue for retry or proceed with a default risk score
 return handleTransientFailure();
 }

 throw new Error("Invalid input or configuration");
}

Best Practices for Decision Support

Remember that registration signals are intended as decision-support inputs, not definitive proof of identity. When the Threads Checker API is unavailable, your internal policy should define what the system does next.

Avoid Blocking: If your business logic allows, consider defaulting to a "neutral" status rather than rejecting the user entirely when the API experiences transient load.
Configurable Retries: If you implement retries, ensure they are non-aggressive and configurable, respecting the service's current operational state.

By treating the API as a component that can provide both signals and state-based feedback, you can build a more robust onboarding experience that remains functional even when specific upstream services are under pressure.

For more details on integrating these signals, consult the official documentation.

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

Handling Error States in WhatsApp Number Verification

eKYC Pro — Thu, 17 Sep 2026 03:21:10 +0000

Integrating third-party identity signals into your registration flow requires more than just a "happy path" implementation. When building an onboarding process that relies on platform-registration signals, you must account for scenarios where the requested identifier is not available or the request fails.

In this guide, we look at how to implement robust error handling for the WhatsApp Checker API to ensure your application remains resilient.

The Role of Synchronous Checks

The WhatsApp Checker API provides a synchronous request-response flow to verify account presence. By sending a single phone number in E.164 format to the /v1/check endpoint, you receive a signal indicating whether that identifier is registered on WhatsApp. This signal serves as a tool to support your custom registration or verification logic.

Implementing a Robust Integration

When integrating, you should treat the API response as a signal that informs your next step. However, the system may return errors if the identifier is not found in the cache or if the request is malformed.

Step 1: Define Your Error Handling Strategy

Always check the success boolean in the response before parsing the data. If success is false, your application should be prepared to handle the error state gracefully without blocking the user.

Step 2: Handling the 400 Status

A common scenario is receiving a 400 status code when an identifier is not found in the cache. Rather than failing the entire registration, you can use this as a trigger to initiate a fallback flow, such as prompting the user for an alternative verification method.

Step 3: Conceptual Implementation

Below is a conceptual pattern for managing these responses:

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

 if (response.status === 200) {
 const result = await response.json();
 return result.data.registered;
 } else if (response.status === 400) {
 // Handle cache-miss or invalid identifier
 return triggerFallbackFlow();
 }
 } catch (error) {
 // Handle network-level issues
 console.error('API connection failed', error);
 }
}

Best Practices for Production

Separate Concerns: Keep your API integration logic isolated from your primary business logic. This allows you to swap or update your verification strategies without refactoring your entire registration pipeline.
Log Strategically: While you should log errors for debugging, ensure you are not logging sensitive identifier data in plain text.
Graceful Degradation: If the API returns a 500 status, ensure your application has a default behavior that allows the user to proceed or try again later, preventing a hard crash.

Conclusion

By anticipating error states like cache misses, you can build a more reliable onboarding experience. Use the WhatsApp Checker API signals as one part of your broader decision-support framework to maintain a smooth user journey. For further details on request structures and status codes, consult the official documentation.

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

Understanding the WhatsApp Registration Signal: A Boundary Case Analysis

eKYC Pro — Wed, 16 Sep 2026 03:22:55 +0000

In modern onboarding workflows, developers often look for signals to validate user identity. A common approach is to verify if a provided phone number is registered with a specific platform, such as WhatsApp. However, relying on a registered signal requires a nuanced understanding of what that data point actually represents.

The Signal vs. The Identity

When you integrate a service like the WhatsApp Checker API, you receive a boolean indicator of account presence. It is critical to recognize that this is a point-in-time account-presence indicator. It confirms that the identifier exists within the platform's user base at the moment of the check. It does not, however, serve as a universal proof of ownership or identity.

Architectural Boundaries

When designing your integration, treat the registered response as a supporting signal rather than a definitive authentication factor. In a typical POST request to /v1/check, the API returns a response confirming the registration status of an E.164-formatted identifier.

// Conceptual response structure
{
 "success": true,
 "data": {
 "registered": true
 }
}

If you treat this signal as a binary "is this the legitimate owner" check, you risk creating a security gap. A phone number might be registered on a platform by a previous owner, a temporary user, or a malicious actor who has recycled the number.

Best Practices for Risk-Aware Integration

To build a robust system, consider these architectural principles:

Signal Layering: Use the registration signal as one input among many. If your application requires higher assurance, combine this with other verification methods (e.g., SMS OTP or multi-factor authentication) rather than relying on platform existence alone.
Security and Credentials: Always handle your X-API-Key with care. Use environment variables to inject credentials into your application at runtime, ensuring they are never hardcoded in your source files. Treat the API key as a sensitive secret with access boundaries limited to the specific services required for your onboarding flow.
Decision Support: Design your application logic to treat the registered flag as a piece of metadata that informs a broader risk-scoring engine. For instance, a registration signal might trigger a "medium risk" flag in your internal dashboard, prompting a manual review or a secondary challenge, rather than triggering an automated account creation.

Conclusion

Platform registration signals are valuable tools for reducing friction and identifying potential anomalies, but they are not a substitute for identity verification. By framing these signals as one component of a layered security architecture, you can build more resilient onboarding flows that account for the reality of modern digital identity.

For more details on implementation, refer to the official documentation.

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

Boundary Cases in WhatsApp Business Verification: What the Registration Signal Actually Proves

eKYC Pro — Tue, 15 Sep 2026 03:23:04 +0000

In modern web applications, the registration flow is the "second front door." Developers spend significant resources hardening login forms, implementing rate limits, and enforcing multi-factor authentication. However, the integrity of your user base often depends on the signals you collect during onboarding—specifically, verifying that a provided identifier corresponds to a legitimate entity.

The Signal vs. The Identity

It is common to integrate a ws_business check to automate parts of a user onboarding flow, such as wholesale account approval. The logic often follows a simple path: if the API returns a positive signal for a WhatsApp Business account, the user is deemed a "verified business" and granted elevated access.

However, it is critical to distinguish between account presence and identity legitimacy. A ws_business signal confirms that a specific phone number is registered as a business account on the WhatsApp platform at the time of the check. It does not, and cannot, verify the identity of the person operating that account or the legal standing of the business behind it.

Understanding the Integration Boundary

When using the POST /v1/check endpoint, the API provides a synchronous, point-in-time signal. This is a powerful tool for reducing friction in your onboarding funnel by confirming that a user has an active business presence.

Technical Implementation Note

When integrating this check, ensure your application treats the response as a supporting data point rather than a final verification of identity.

// Conceptual representation of the request
{
 "service_type": "ws_business",
 "identifier": "+1234567890"
}

If the response indicates business: true, you have confirmed the presence of a business-registered account. This signal is best used as one layer in a broader risk-assessment strategy, alongside other identity verification methods.

Best Practices for Decision Logic

Use as a Supporting Signal: Never rely on a single registration signal to grant high-privilege access. Use it to flag accounts for manual review or to trigger additional verification steps.
Avoid Over-Automation: If your business model requires strict identity verification, ensure that the registration signal is part of a multi-factor verification process.
Handle API Responses Gracefully: Always account for the success boolean in your logic. If the request fails (e.g., a 400 or 500 status), your application should have a defined fallback behavior—such as prompting the user for alternative contact information—rather than defaulting to an "approve" or "deny" state.

Conclusion

Integrating platform registration signals like ws_business is an effective way to improve user experience and gather context about your sign-ups. By recognizing that these tools provide account-presence metadata rather than identity proofs, you can build more robust, secure, and resilient onboarding architectures.

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

Explore eKYC Pro per-call APIs

Designing Resilient Verification: Handling Service Availability with the Services List API

eKYC Pro — Mon, 14 Sep 2026 03:21:17 +0000

Building a robust user registration flow requires more than just collecting data—it requires managing the reliability of your verification signals. When you integrate identity verification services, you often rely on the availability of external platforms. If a specific check becomes unavailable, your application should adapt gracefully rather than failing silently or blocking the user.

By leveraging the Services List API, you can implement a dynamic check that verifies the operational status of your chosen services before initiating a request. This approach allows you to build a more resilient integration that respects real-time service availability.

Why Dynamic Service Discovery Matters

Hardcoding your integration logic to assume all services are always available is a common pitfall. If a platform undergoes maintenance or experiences an outage, your verification flow could encounter errors. Instead of relying on static assumptions, you can query the https://api.ekycpro.com/v1/services endpoint to confirm which services are currently enabled before attempting a check.

Step-by-Step: Implementing a Resilient Verification Flow

Follow these steps to integrate service availability checks into your registration process.

1. Fetch the Current Service Status

Before you trigger a verification request, perform a GET request to the Services List API. This provides a snapshot of all supported services and their current operational state.

// Conceptual: Fetching available services
// GET https://api.ekycpro.com/v1/services

2. Parse and Filter for Required Services

Once you receive the response, iterate through the services array. Check the enabled boolean flag for the specific platform you intend to query. This allows you to filter out services that are temporarily unavailable.

// Conceptual: Normalizing service availability
const serviceList = documentedResult.services;
const isServiceAvailable = (type) => {
 const service = serviceList.find(s => s.type === type);
 return service ? service.enabled : false;
};

3. Adapt Your User Experience

If the service you require is currently marked as enabled: false, you can trigger a fallback mechanism. This might involve:

Graceful Degradation: Skip the unavailable check and proceed with other verification methods.
User Notification: Inform the user that a specific verification step is currently unavailable and offer an alternative path.
Queueing: Log the request for a later retry if your business logic permits asynchronous processing.

Operational Visibility

Monitoring your integration's interaction with the Services List API is essential for observability. By logging the success field from the API response, you can track how often your application detects service downtime. This data provides valuable insight into the reliability of your verification pipeline and helps you refine your error-handling strategies over time.

Conclusion

Resilient software design acknowledges that external dependencies are not always predictable. By checking the Services List API, you shift from a fragile, hardcoded integration to a dynamic system that adapts to real-time conditions. This simple step ensures that your verification flow remains reliable, providing a better experience for your users even when specific platforms face temporary outages. For further details on available endpoints, refer to the official documentation.

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

Designing Decision Logic for Combo Check API Integrations

eKYC Pro — Sun, 13 Sep 2026 03:22:41 +0000

When building user onboarding flows, verifying account presence across multiple platforms—like WhatsApp, Telegram, and VK—is a common requirement. The Combo Check API allows developers to consolidate these checks into a single request, but managing the logic for partial results is crucial for a robust integration.

Choosing Your Integration Strategy

Before implementing, it is important to distinguish between the available verification patterns:

CSV Uploads: Best for bulk, non-real-time auditing of existing user databases.
Per-call API: Ideal for single-service checks where you only need to verify one specific platform at a time.
Combo Check API: Designed for scenarios where you need to evaluate an identifier against multiple services simultaneously to make a unified onboarding decision.

Implementation Strategy: Handling Partial Results

Because the Combo Check API executes service checks in parallel, it is possible for some services to return a result while others encounter a timeout. Your application logic must account for these null registration results.

1. Requesting the Combo

You can either use a pre-configured combo set in your dashboard or override it per request using the service_types array:

// Conceptual request payload
{
 "identifier": "+6281234567890",
 "service_types": ["ws", "telegram", "vk"]
}

2. Normalizing the Response

When processing the response, do not assume every service will return a boolean registered value. Your logic should treat null as an indeterminate state rather than a negative signal.

// Conceptual logic for handling the response
const processComboResults = (data) => {
 const results = data.results;

 for (const [service, status] of Object.entries(results)) {
 if (status.registered === true) {
 // Proceed with service-specific onboarding
 } else if (status.error === "timeout") {
 // Handle as indeterminate: log for retry or flag for manual review
 } else {
 // Handle as not registered
 }
 }
};

Best Practices for Robust Integrations

Set Appropriate Timeouts: Since the API returns within ~10 seconds, ensure your client-side implementation has a timeout threshold (e.g., 15 seconds) to prevent hanging connections.
Implement Individual Retries: If a specific service returns a timeout error, you can use the Per-call API to attempt a re-verification of that specific service without re-running the entire combo.
Check Balance Early: The API performs a pre-check against your balance. Ensure your application handles 402 status codes gracefully by prompting for account funding if the total cost of the requested combo exceeds your current balance.

Conclusion

By treating the Combo Check API response as a collection of independent signals rather than a single atomic result, you can build resilient onboarding flows that handle network variability gracefully. Always design your decision logic to distinguish between a confirmed "not registered" state and an "indeterminate" state caused by service timeouts.

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

Designing Data Integrity: Standardizing Instagram Email Verification Responses

eKYC Pro — Sat, 12 Sep 2026 03:22:57 +0000

In modern identity workflows, the reliability of your onboarding logic depends entirely on how you normalize external signals. When integrating account-presence checks—such as verifying if an email is registered on Instagram—developers often face the challenge of mapping raw API responses into local user profiles without introducing "silent" data corruption or misinterpreting signal states.

The Anatomy of an Account-Presence Signal

When you query the Instagram Email Checker API, you receive a synchronous response containing a structured data object. Unlike generic validation services, this endpoint provides a specific registered boolean flag. This flag serves as your primary decision-support signal.

To maintain data integrity, treat this signal as an advisory input rather than an absolute proof of identity. Your application logic should map this registered status to your local user database only after validating the success boolean of the API response.

Implementation Strategy: Normalization Checkpoints

When integrating the POST /v1/check endpoint, follow these three steps to ensure your local storage remains consistent:

1. Validate the Envelope

Before inspecting the registration state, verify that the success field is true. If the API returns a non-200 status code (such as 400, 401, or 500), the data object should be considered unreliable or absent.

2. Isolate the Signal

Extract the data.registered boolean. This is your core indicator of account presence. Avoid hardcoding logic that assumes a false value implies an invalid email; it simply indicates that the identifier is not currently associated with an active Instagram account.

3. Map the Traceability

Store the data.id string alongside your local user record. This allows for auditability. If you ever need to perform a security audit of your onboarding flow, having the unique check ID linked to your user record provides a clear trail of the signal used during the decision-making process.

Best Practices for Data Mapping

Decouple Signals: If you are also using other services (like the WhatsApp Checker), keep the mapping logic for each provider isolated. Do not aggregate these signals into a single "verified" flag in your database. Keep the Instagram-specific registered signal separate from other platform-specific indicators.
Handle Nulls: Ensure your database schema accounts for cases where a check might be pending or failed. A null or missing value in your local is_instagram_registered column is safer than a default false.
Auditability: As discussed in Website Security Audit: Prevent Enterprise Breaches, maintaining a clear audit trail is essential for enterprise-grade security. Storing the data.id from your API calls is a low-cost, high-value way to ensure your identity decisions remain transparent.

Conclusion

Standardizing how your system interprets the Instagram Email Checker response is a foundational step in building a robust onboarding pipeline. By focusing on the deterministic nature of the registered signal and maintaining a clean mapping to your local user identity store, you create a more resilient architecture that supports clear, data-backed decision-making.

For more details on integrating these signals, refer to the official documentation.

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

Designing Resilient Verification: Handling Timeout Scenarios in Multi-Service Workflows

eKYC Pro — Thu, 10 Sep 2026 03:22:34 +0000

When building identity verification pipelines, the goal is often to gather as much context as possible about a user's presence across platforms. Using the Combo Check API allows you to query multiple services—like WhatsApp, Telegram, and VK—in a single request. However, distributed systems are rarely perfect. A common challenge arises when one service within a multi-service request experiences a transient delay, resulting in a partial response.

The Anatomy of a Partial Result

The Combo Check API is designed to return a consolidated response even if individual service checks encounter issues. When you submit an identifier to POST /v1/check/combo/phone, the API processes your requested service_types in parallel.

If a specific service fails to respond within the internal processing window, the API returns a timeout error for that specific node in the data.results object. Crucially, the overall API call remains successful (HTTP 200), and you receive the valid, completed signals for the other services in the same payload.

Example Response with Timeout

{
 "data": {
 "results": {
 "ws": { "registered": true, "error": null },
 "vk": { "registered": null, "error": "timeout" }
 }
 }
}

Implementation: Conditional Retry Strategy

To ensure your application remains resilient, you should implement a handler that inspects the data.results object for any error fields. Rather than discarding the entire transaction, you can isolate the failed service and perform a targeted retry.

Step-by-Step Handling Logic

Parse the Response: Iterate through the data.results object.
Identify Failures: Check if any service node contains an error field with the value "timeout".
Isolate and Retry: For services that timed out, trigger a follow-up request using the dedicated POST /v1/check endpoint. This allows you to fetch the missing signal without re-billing or re-querying the services that already returned a valid result.
Update State: Merge the result from the single-check retry into your local user identity record.

Testing and Sandboxing

Before deploying your retry logic, it is essential to validate how your system handles these partial states.

Create Fixture Files: Generate local JSON files that mimic the structure of a partial response, specifically including the error: "timeout" field.
Contract Testing: Use these fixtures to ensure your parser correctly identifies the timeout and triggers the secondary POST /v1/check call.
Timeout Simulation: Configure your client-side timeout to at least 15s to ensure you allow the API enough time to complete its internal parallel execution before your application layer prematurely terminates the connection.

Conclusion

Resilience in identity workflows is about gracefully handling the reality of distributed service availability. By treating the Combo Check API as a provider of individual signals—some of which may require a secondary attempt—you can build a more robust verification layer. For more details on integrating these checks, refer to the official documentation.

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

Building Resilient Verification Flows: How to Use the Services List API for Dynamic Integration

eKYC Pro — Wed, 09 Sep 2026 03:23:10 +0000

When building registration or risk-review workflows, the user experience often hinges on how gracefully your application handles the availability of external verification signals. If you are integrating eKYC Pro to validate identifiers, you might be tempted to hardcode your supported platform checks. However, a more resilient approach involves programmatically querying the available services before your application even attempts a request.

By leveraging the Services List API, you can build dynamic front-ends that adapt to real-time service availability, preventing unnecessary API calls and providing clearer feedback to your users.

Why Dynamic Service Discovery Matters

Hardcoding platform support creates a brittle integration. If a specific service check is temporarily unavailable, your application might continue to attempt requests, leading to failed workflows and frustrated users. Instead, by integrating a discovery step, you can:

Filter UI Elements: Dynamically show or hide verification options based on the enabled status returned by the API.
Optimize Request Routing: Ensure your application only submits identifiers for services that are currently active, reducing error-handling overhead.
Improve User Experience: Provide context-aware messaging to users if a specific verification method is currently offline.

Implementation Strategy

To build this into your workflow, treat the Services List API as a configuration layer. Instead of assuming platform support, your application should fetch the current state of services during initialization or at regular intervals.

Step 1: Querying Available Services

Use the GET https://api.ekycpro.com/v1/services endpoint to retrieve the full list of supported check types. The response provides a clean list of services, their required data_type (phone or email), and their current enabled status.

Step 2: Normalizing the Data

Once you receive the response, map the enabled services into your application’s state. This allows your UI components to consume a local, reliable source of truth.

// Conceptual example of processing the service list
async function getAvailableServices() {
 const response = await fetch('https://api.ekycpro.com/v1/services');
 const data = await response.json();

 if (data.success) {
 // Filter for services that are enabled and match your input needs
 return data.services.filter(service => service.enabled === true);
 }
 return [];
}

Step 3: Integrating into the Registration Flow

With your list of enabled services, you can now conditionally render your registration form. If a user enters a phone number, your form logic should only present verification options for services where data_type is "phone" and enabled is true.

A Note on Decision Support

Remember that registration signals and risk scores provided by eKYC Pro are intended as decision-support inputs. They provide valuable account-presence signals, but they should be consumed by your own business logic to determine the next steps in your user journey. By dynamically checking service availability first, you ensure that your decision-support pipeline remains stable and responsive.

Conclusion

Integrating the Services List API is a straightforward way to add resilience to your verification workflows. By shifting from static configuration to dynamic discovery, you create a more robust integration that respects the real-time status of the services you rely on.

For more details on integrating these signals, check out the official documentation.

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