DEV Community: eKYC Pro

Designing Adaptive Verification: Using the Services List API for Dynamic Integration Logic

eKYC Pro — Tue, 01 Sep 2026 03:20:20 +0000

When building registration flows that require identity verification, developers often fall into the trap of hardcoding service availability. Hardcoding assumptions about which platforms are currently checkable—such as WhatsApp, Facebook, or Netflix—leads to brittle integrations that break when provider status changes. Instead, you should architect your frontend and backend to dynamically query the available services.

The Problem with Static Configuration

If your UI displays a list of verification options that you manually maintain, you risk showing options that are temporarily unavailable. This creates a poor user experience where a user selects a verification method, only to receive a failure message after submission. A more robust approach treats service availability as a dynamic state rather than a constant.

Architecting for Dynamic Discovery

By integrating the GET https://api.ekycpro.com/v1/services endpoint, your application can fetch the current state of supported check types in real-time. This allows your system to normalize the available options before rendering a form or deciding which API call to trigger.

Implementation Strategy

Fetch and Cache: On application startup or periodically, query the services list.
Filter by Data Type: Use the data_type field (phone or email) to match the user's input against the services that actually support that identifier.
Check Availability: Only present services where the enabled boolean is true.

Conceptual Integration Logic

// Conceptual: Fetching and filtering services
async function getAvailableServices(inputType) {
 const response = await fetch('https://api.ekycpro.com/v1/services');
 const data = await response.json();

 if (data.success) {
 return data.services.filter(s => s.data_type === inputType && s.enabled === true);
 }
 return [];
}

Managing API Constraints

When implementing this dynamic discovery, keep in mind that the API has rate limits that restrict requests per minute and that concurrency is also limited. Always refer to the current API documentation for applicable limits. Avoid aggressive polling; instead, use a strategy that refreshes the service list at a reasonable interval or upon specific application events.

Best Practices for Data Modeling

When you receive the services array, map these values to your internal UI components. This ensures that your "adapter layer" is decoupled from the API's internal structure. If a service is disabled, your UI can gracefully hide the option or provide a fallback, rather than failing during the verification request.

Conclusion

By moving away from hardcoded configurations and toward a dynamic discovery model, you create a more resilient verification workflow. This ensures that your application remains in sync with the actual availability of checkable services, providing a smoother experience for your users and reducing the maintenance burden on your engineering team.

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

Integrating Proactive Balance Tracking into Your Verification Pipeline

eKYC Pro — Mon, 31 Aug 2026 03:21:22 +0000

In identity verification workflows, operational continuity is paramount. When building authentication pipelines that rely on external identity signals—such as platform registration checks or risk scoring—a sudden service interruption due to exhausted credits can lead to poor user experiences and failed verification attempts.

To build resilient systems, developers should treat account balance as a critical operational dependency. By implementing a "go/no-go" gate using the Balance Query API, you can ensure your system has sufficient credit before triggering high-volume identity checks.

The Architecture of a Pre-Check Gate

The most robust approach is to treat your verification pipeline as a state-aware flow. Instead of blindly firing requests, your application should verify its operational status by querying the /v1/balance endpoint. This acts as a circuit breaker, preventing unnecessary API calls when the account balance is insufficient.

Step 1: Define Your Threshold

Before integrating, define a minimum credit threshold based on your typical traffic volume. This threshold acts as your safety buffer, ensuring you always have enough capacity to handle incoming authentication requests.

Step 2: Implement the Balance Check

Use the /v1/balance endpoint to retrieve your current credit standing. This is a simple GET request requiring your X-API-Key header.

// Conceptual: Pre-check gate logic
async function verifyAccountCapacity(minThreshold) {
 const response = await fetch('https://api.ekycpro.com/v1/balance', {
 method: 'GET',
 headers: { 'X-API-Key': process.env.API_KEY }
 });

 if (response.status === 200) {
 const data = await response.json();
 return data.balance >= minThreshold;
 }

 // Handle errors or unauthorized states
 return false;
}

Step 3: Integrate into the Verification Flow

Wrap your primary verification calls—whether using the Per-call API for specific registration signals or the Unified Score API for risk assessment—within a conditional block that checks the result of your balance query.

Operational Best Practices

Rate Limiting: Note that the API has rate limits that restrict requests per minute and that concurrency is also limited. Please refer to the official API documentation for applicable limits to ensure your monitoring logic does not exceed them.
Error Handling: Always account for non-200 status codes. If the balance query returns a 502 or other failure, treat the state as "unknown" and implement a safe fallback—such as logging the error or alerting your operations team—rather than proceeding with the verification.
Security: As outlined in OWASP A07 & A08, maintaining the integrity of your identity pipeline requires trusting the signals you receive. By validating your own account status before relying on external verification data, you create a more predictable and secure integration.

Conclusion

By integrating proactive balance tracking into your pipeline, you shift from a reactive stance to a controlled, resilient architecture. This simple gate ensures that your verification services remain available when your users need them most. For full details on endpoints and integration, visit the official documentation.

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

Mapping Instagram Registration Signals to Application Logic

eKYC Pro — Sun, 30 Aug 2026 03:22:38 +0000

When building modern user onboarding flows, developers often look for ways to reduce friction while maintaining security. One common strategy is to verify if a submitted phone number is associated with an existing social media account, such as Instagram. By integrating the Instagram Checker API, you can receive a signal indicating whether a specific identifier has an account presence. However, it is critical to treat this as a supporting signal rather than a definitive proof of identity.

The Role of Registration Signals

The Instagram Checker API provides a synchronous request-response flow that returns a registered boolean. This signal acts as a single data point that your application can use to inform its decision-making logic. For instance, you might use this signal to:

Personalize Onboarding: Tailor the user experience based on the likelihood of an existing account.
Trigger Secondary Verification: If a phone number shows no registration signal, you may choose to initiate additional verification steps to ensure the user is who they claim to be.

Architecture and Security Best Practices

When integrating these checks, your architecture must prioritize secure credential handling. Never hardcode your X-API-Key in your source code or client-side applications. Instead, store your credentials in secure environment variables or a dedicated secret management service.

Your application should act as a proxy between your frontend and the API. Your server-side code should handle the request to POST /v1/check, ensuring that sensitive headers are never exposed to the client. This boundary protects your API key and allows you to implement server-side logic to interpret the registered signal before passing a response to the end user.

Implementation Considerations

When designing your integration, keep the following in mind:

Decision Support: Always treat the registration signal as one input among many. It is not a substitute for robust identity verification or intent analysis.
Rate Limiting: The API has rate limits that restrict requests per minute and concurrency is also limited. Please refer to the current API documentation for applicable limits.
Error Handling: Ensure your application gracefully handles non-200 status codes, such as 400, 401, or 500 errors, which may occur if the request is malformed, unauthorized, or if there is a server-side issue.

Conclusion

Using registration signals like those provided by the Instagram Checker API can significantly enhance your onboarding flow. By treating these outputs as supporting signals within a broader risk-review strategy, you can create a more personalized and secure experience for your users. For the most up-to-date information on implementation, please consult the official API documentation.

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

Designing Decision-Support Logic for Combo Check API Integrations

eKYC Pro — Sat, 29 Aug 2026 03:22:53 +0000

When building user onboarding or risk-review workflows, the challenge often lies in how to interpret incoming data signals. Should you treat a user's digital footprint as a single "pass/fail" gate, or as a collection of independent data points?

For developers integrating identity verification signals, the choice between CSV/TXT upload workflows, individual Per-call API requests, and the Combo Check API often depends on your application's specific decision-support requirements.

Choosing Your Integration Path

1. CSV/TXT Upload Workflow

This approach is best suited for bulk analysis or periodic auditing where immediate, real-time decision-making is not required. It is an operational choice for processing large lists of identifiers asynchronously.

2. Per-call API Integration

Use the Per-call API when your logic requires a specific, granular signal from a single service. This is ideal for lightweight checks where you only need to confirm presence on one platform (e.g., verifying a WhatsApp presence to trigger a specific communication channel).

3. Combo Check API

When your business logic requires a comprehensive view of a user's digital presence, the Combo Check API allows you to verify one identifier against multiple services in a single request. By retrieving all signals at once, you can build more nuanced, multi-factor decision rules.

Designing Robust Decision Logic

When consuming data from the Combo Check API, it is critical to treat each service result as an independent input. Because the API returns a structured object containing results for each service, your application should parse these individually.

Handling Partial Results

Integration logic must account for the reality of distributed systems. The Combo Check API runs selected services in parallel. In some cases, individual services may return a null registration status or a specific error (such as a timeout).

Instead of treating a null result as a failure of the entire request, your application logic should:

Validate the success flag: Confirm the overall request was processed.
Iterate through the results object: Check the registered status for each service key.
Handle exceptions: If a specific service returns an error or a null value, implement a fallback or a retry strategy using the individual /v1/check endpoint for that specific service.

Best Practices for Decision Rules

Decouple Signals: Do not create a monolithic "is_valid" flag. Instead, map registration signals to internal business requirements. For example, require a "High" score from the Unified Score API for high-value transactions, while using Combo Check signals to verify secondary platform presence for account recovery.
Rate Limiting: Note that the API has rate limits that restrict requests per minute and that concurrency is also limited. Always consult the current API documentation for applicable limits to ensure your polling or request frequency remains within operational bounds.
Graceful Degradation: If a service check times out, your system should be designed to either proceed with the available data or prompt the user for additional verification, rather than failing the entire onboarding flow.

Conclusion

By treating service signals as independent, modular inputs, you can create more resilient onboarding flows. Whether you are using the Combo Check API to aggregate multiple signals or the Unified Score API to obtain a risk-based PTS score, the key is to design your application to interpret these outputs as decision-support signals rather than deterministic outcomes.

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

Integrating Instagram Account Presence Signals into User Onboarding

eKYC Pro — Fri, 28 Aug 2026 03:20:14 +0000

In modern user onboarding, verifying the authenticity of a phone number is a critical step in maintaining platform integrity. By using account presence signals, you can gain a clearer understanding of whether a provided identifier is associated with an active Instagram account. This tutorial walks through how to integrate the Instagram Checker API into your registration workflow.

Understanding the Integration Boundary

When a user submits their phone number during sign-up, you can use the Instagram Checker API to perform a synchronous check. This process provides a boolean signal that indicates whether the identifier is registered on the platform.

It is important to treat this result as a supporting signal for your own internal decision-making logic, rather than a definitive guarantee of user identity. Your application should use this data to inform custom gates, such as flagging accounts for manual review or triggering additional verification steps.

Step 1: Prepare Your Request

The API requires a POST request to the /v1/check endpoint. You must include your X-API-Key in the request header to authenticate the call.

Ensure your payload specifies the service_type as instagram and provides the identifier in E.164 format. Note that the API has rate limits that restrict requests per minute and that concurrency is also limited. Please refer to the current API documentation for applicable limits and best practices regarding request volume.

Step 2: Mapping the Response

The API returns a JSON object containing a success boolean and a data object. The key field to parse for your onboarding gate is data.registered.

Conceptual Logic for Normalization

// Conceptual: Mapping the presence signal to your registration flow
async function verifyUserPresence(phoneNumber) {
 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: 'instagram',
 identifier: phoneNumber
 })
 });

 const result = await response.json();

 if (result.success) {
 return result.data.registered; // true or false
 }

 throw new Error('Verification request failed');
}

Step 3: Implementing the Registration Gate

Once you have the registered boolean, you can map it to your downstream storage or business logic. For example:

If true: Proceed with standard user creation.
If false: Trigger an alternative verification flow, such as requiring an email address or SMS verification code, before allowing the account to be created.

By normalizing this signal into your registration pipeline, you create a more robust onboarding process that accounts for platform-specific presence data.

Conclusion

Integrating Instagram account presence signals allows you to add a layer of intelligence to your user registration. By checking identifiers synchronously, you can make informed decisions about how to handle new sign-ups. Always consult the official API documentation to ensure your implementation adheres to current rate limits and integration standards.

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

Dynamic UI Orchestration: Using the Services List API to Manage Frontend Verification Options

eKYC Pro — Wed, 26 Aug 2026 03:21:19 +0000

Building a robust registration or verification flow requires more than just collecting user input; it requires knowing exactly which verification services are available at any given moment. Hardcoding your UI to support specific platforms can lead to broken user experiences if a service becomes temporarily unavailable or if your account configuration changes.

By leveraging the Services List API, you can build a dynamic frontend that adapts to your current service availability in real time.

Understanding the Integration Boundary

The GET /v1/services endpoint is your source of truth for service availability. Instead of manually updating your registration form when you add or remove support for a platform, your application can fetch the current list of enabled services and render the appropriate input fields accordingly.

The Data Contract

When you query the API, you receive a list of services, each defined by its type, the required data_type (phone or email), and an enabled boolean flag.

// Conceptual representation of the API response
{
 "success": true,
 "services": [
 { "type": "facebook", "data_type": "phone", "enabled": true },
 { "type": "netflix", "data_type": "email", "enabled": true }
 ]
}

Implementation Strategy

To ensure your UI remains resilient, follow these steps:

Fetch on Initialization: Trigger a request to /v1/services when your application initializes or before rendering the registration component.
Filter by State: Only iterate over services where enabled is true.
Map to UI Components: Use the data_type field to determine whether to render a phone input or an email input.

Testing and Sandboxing

When building this integration, it is critical to test how your UI handles different API states. Use fixture files to simulate various responses from the API:

Happy Path: A response containing a mix of phone and email services.
Partial Outage: A response where specific services have enabled: false.
Empty State: An empty services array to ensure your UI gracefully handles a scenario with no available verification methods.

By mocking these responses in your local test environment, you can verify that your logic correctly toggles input visibility without making actual network calls during development.

Important Considerations

When integrating, keep in mind that the API has rate limits that restrict requests per minute and that concurrency is also limited. Always consult the official API documentation for the most current information regarding these limits to ensure your application remains stable under load.

Conclusion

Dynamic UI orchestration allows you to decouple your frontend logic from your backend service configuration. By treating the Services List API as the primary source for your UI state, you create a more maintainable and reliable verification experience for your users.

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

Designing Decision-Support Logic for WhatsApp Avatar Verification

eKYC Pro — Tue, 25 Aug 2026 03:22:17 +0000

When building user onboarding flows, developers often look for signals to validate account authenticity. Using the WhatsApp Avatar Checker, you can programmatically determine if a phone number is associated with a WhatsApp account that has a profile photo. While this provides a useful data point, it is critical to treat this signal as a non-definitive indicator of account activity rather than a guarantee of identity.

Understanding the Signal

The ws_avatar service type allows you to perform a synchronous check on a phone number. The API returns a boolean avatar field, which indicates the presence of a profile photo.

// Conceptual request
{
 "service_type": "ws_avatar",
 "identifier": "+1234567890"
}

It is tempting to map this directly to a "verified" status. However, a profile photo is merely a supporting signal. It suggests that the account has been configured, but it does not confirm that the user currently controlling the phone number is the same person who set up the account. Your decision-support logic should weigh this alongside other signals rather than using it as a standalone gatekeeper.

Handling Integration Boundaries and Errors

Robust applications must handle API interactions gracefully. The service has rate limits that restrict requests per minute and that concurrency is also limited; please refer to the current API documentation for applicable limits.

When consuming the API, implement a retry policy for transient issues. If you receive a 500 error, your system should employ an exponential backoff strategy to avoid overwhelming the service. Always ensure your integration is operator-safe by logging the unique request ID returned by the service, which helps in tracing specific verification events.

Error Handling Checklist

Validate Input: Ensure the identifier follows E.164 format before sending the request to avoid 400 errors.
Authorization: Securely manage your X-API-Key to prevent 401 unauthorized errors.
Idempotency: While the API is synchronous, ensure your internal database logic handles duplicate results for the same identifier to prevent redundant processing.
Graceful Degradation: If the API returns an error or is unreachable, your application should default to a neutral state rather than blocking the user or incorrectly flagging the account.

Best Practices for Correlation

To build a reliable audit trail, assign a correlation ID to every session lifecycle action, from the initial login attempt to the final risk decision. By linking the ws_avatar check result to a broader session context, you create a trail that allows your team to audit why a specific decision was made during the onboarding process.

Conclusion

Leveraging profile avatar presence is an effective way to enrich your user onboarding data. By positioning this as one of many signals and implementing defensive error handling, you can create a more resilient identity verification workflow. Always consult the official documentation to stay updated on current API capabilities and constraints.

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

Explore eKYC Pro per-call APIs

Building Adaptive Verification Flows: Using the Services List API for Dynamic UI

eKYC Pro — Mon, 24 Aug 2026 03:21:51 +0000

When building onboarding flows that require identity verification, hardcoding a list of supported platforms can lead to a brittle user experience. If a service becomes temporarily unavailable or if you expand your verification suite, your UI might offer options that result in failed requests. By integrating the Services List API, you can create a dynamic interface that adapts to the current availability of your verification services.

Why Dynamic Service Discovery Matters

Rather than assuming platform availability, a robust integration fetches the current state of supported services directly from the API. This ensures that your frontend only displays buttons or inputs for services that are currently active, reducing friction for your users and preventing unnecessary API calls to inactive endpoints.

Step 1: Fetching Available Services

To begin, your application should perform a GET request to the /v1/services endpoint. This call returns the list of all supported service types along with their current operational status.

Conceptual Implementation

// Conceptual: Fetching current service availability
async function getAvailableServices() {
 const response = await fetch('https://api.ekycpro.com/v1/services');
 const documentedResult = await response.json();

 if (documentedResult.success) {
 return documentedResult.services;
 }
 return [];
}

Step 2: Normalizing the UI State

Once you have retrieved the list of services, you can filter them based on the enabled boolean flag. This allows you to map your UI components—such as registration-check buttons for Facebook, Instagram, or Netflix—to the actual availability of the backend.

Filter by data_type: Ensure your UI only presents the relevant verification input (phone or email) based on the service requirements.
Toggle Visibility: Use the enabled field to conditionally render or disable specific UI elements.

Step 3: Handling API Constraints

When implementing this workflow, keep in mind that the API has rate limits that restrict requests per minute and that concurrency is also limited. For production environments, avoid polling the Services List API on every page load. Instead, cache the service list for a reasonable duration or trigger the fetch only when the user initiates the verification stage of your onboarding flow. Please refer to the current API documentation for applicable limits.

Conclusion

By leveraging the Services List API, you shift from a static, hardcoded integration to a resilient, data-driven architecture. This approach ensures your onboarding flows remain accurate and responsive to changes in service availability, providing a smoother experience for your users. For further details on integrating these signals, consult the official documentation.

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

Implementing Resilient Error Handling for Facebook Email Verification

eKYC Pro — Sun, 23 Aug 2026 03:22:16 +0000

Integrating third-party identity signals like the Facebook Email Checker API into your registration workflow requires more than just a successful request path. To build a robust user experience, you must design for the reality of network volatility and input validation errors.

When your application relies on external signals to drive decision support, how you handle failures determines whether your system remains operator-safe or leaves users stuck in a broken state.

Understanding the Integration Boundary

The Facebook Email Checker API operates as a synchronous request-response service. When you submit an identifier via the POST /v1/check endpoint, the API provides a platform registration signal. However, production environments are rarely perfect. The API has rate limits that restrict requests per minute and that concurrency is also limited; please consult the current API documentation for the specific thresholds applicable to your integration.

Categorizing Failure Modes

Effective error handling starts by distinguishing between client-side mistakes and server-side issues. Based on the API specifications, you should implement logic to handle these distinct status codes:

400 Bad Request: This typically indicates an issue with the request body, such as an incorrectly formatted email address. Your application should treat this as a signal to prompt the user to correct their input rather than retrying the request.
401 Unauthorized: This indicates a missing or invalid X-API-Key. This is a configuration error that requires immediate attention from your DevOps team.
500 Server Error: These are transient issues on the provider side. Unlike a 400 error, these are candidates for a retry policy.

Implementing a Resilient Pattern

Do not simply log errors and continue. Instead, wrap your API calls in an adapter layer that normalizes the response. Below is a conceptual pattern for handling these failures:

// Conceptual: Error handling wrapper
async function verifyEmail(email) {
 try {
 const response = await fetch('https://api.ekycpro.com/v1/check', {
 method: 'POST',
 headers: { 'X-API-Key': process.env.API_KEY },
 body: JSON.stringify({ service_type: 'facebook_email', identifier: email })
 });

 if (response.status === 400) {
 throw new Error('Invalid input format');
 }

 if (response.status >= 500) {
 // Trigger retry logic or fallback
 return handleTransientFailure();
 }

 return await response.json();
 } catch (error) {
 // Log and notify operator
 }
}

Best Practices for Retries

When encountering a 500-level error, avoid aggressive retry loops. Implement a configurable backoff policy that allows the system to recover without overwhelming the endpoint. Always ensure your integration is idempotent; if you are unsure whether a request was processed, verify the status rather than blindly repeating the submission.

Conclusion

By treating the Facebook Email Checker as a fallible dependency, you can build a registration flow that gracefully handles errors. Focus on providing clear feedback for 400-level errors and implementing non-aggressive, configurable retries for transient server issues to ensure your decision-support signals remain reliable.

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

Boundary Conditions: Using Instagram Email Signals for User Onboarding

eKYC Pro — Sat, 22 Aug 2026 03:22:33 +0000

When building user onboarding flows, developers often look for signals to validate the authenticity of a new account. Integrating an email-based platform registration check, such as the Instagram Email Checker, provides a specific, actionable signal: whether an email address is currently associated with an active Instagram account.

However, it is critical to understand the technical boundaries of this signal to ensure your risk engine remains robust.

Understanding the Signal

The Instagram Email Checker returns a boolean registered signal. It is important to treat this as an account-presence signal rather than a universal proof of identity. This signal indicates that the email address is linked to an account on the specified platform at the time of the request. It does not verify the ownership of the email, nor does it guarantee that the account belongs to the person currently interacting with your sign-up form.

Integration Boundaries

When integrating this into your onboarding workflow, consider these architectural best practices:

1. Treat Signals as Inputs, Not Decisions

Your internal risk engine should consume the registered signal as one of many data points. A positive registration signal can serve as a trust-building indicator, while a lack of registration might trigger additional verification steps, such as email confirmation or manual review. Never rely on a single signal as a binary gatekeeper for user access.

2. Handling API Constraints

When implementing the POST /v1/check endpoint, ensure your integration handles the API's operational constraints. The API has rate limits that restrict requests per minute and concurrency is also limited. Please refer to the current API documentation for applicable limits and to ensure your implementation uses an efficient, non-aggressive polling or request strategy.

3. Testing and Sandboxing

Before deploying to production, implement a robust testing strategy:

Fixture Files: Create local fixture files that represent various registered states (true/false) to test your risk engine logic in isolation.
Contract Testing: Validate that your service correctly handles the success boolean and the data.registered field provided by the API response.
Mocking: Use mocks to simulate the API response during your CI/CD pipeline to ensure your application handles potential 400, 401, or 500 status codes gracefully.

Conceptual Implementation

When calling the API, your application should focus on mapping the registration signal into your internal risk scoring model:

// Conceptual: Normalizing the registration signal
async function checkUserRisk(email) {
 const response = await callInstagramChecker(email);

 if (response.success) {
 const isRegistered = response.data.registered;
 // Map the signal to your internal risk engine
 return riskEngine.evaluate({ 
 email, 
 platformPresence: isRegistered 
 });
 }

 // Handle errors or unsuccessful checks
 return riskEngine.defaultPolicy();
}

Conclusion

Platform-registration signals are powerful tools for enhancing user onboarding, but they are most effective when used as part of a layered defense strategy. By respecting the technical boundaries of the Instagram Email Checker and treating its output as a supporting signal, you can build a more resilient and secure sign-up experience. Always consult the official documentation for the latest integration details and rate-limit guidelines.

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

How to Automate Balance Monitoring for your Verification Workflows

eKYC Pro — Fri, 21 Aug 2026 03:22:45 +0000

When building verification pipelines—whether you are integrating a single-identifier check or a complex risk-scoring flow—maintaining service continuity is critical. If your account balance hits zero, your synchronous request-response flow will be interrupted, leading to failed requests.

In this guide, we will walk through how to implement a proactive monitoring pattern for your account credits using the eKYC Pro Balance Query API.

The Importance of Proactive Monitoring

In a production environment, you cannot rely on manual checks. By integrating a balance query into your existing operational dashboard or as a pre-flight check in your CI/CD pipeline, you can trigger alerts before your credit supply is exhausted. This allows your team to manage top-ups or budget adjustments without service downtime.

Step 1: Understanding the Balance Query API

The Balance Query API provides a simple, authenticated way to retrieve your current credit count. It uses a standard GET request to the /v1/balance endpoint.

Request Structure

To query your balance, you must provide your X-API-Key in the request header. Here is how you can perform this check using curl:

curl --location 'https://api.ekycpro.com/v1/balance' \
--header 'X-API-Key: YOUR_API_KEY'

Step 2: Handling the Response

The API returns a JSON object containing your balance as a numeric value. Your integration logic should parse this field to compare it against a defined threshold.

{
 "balance": 9850.50
}

Step 3: Implementing a Monitoring Logic

Rather than checking the balance on every single verification request, it is more efficient to implement a periodic check. You can wrap this in a simple script that runs on a cron job or as part of your internal monitoring service:

Define a Threshold: Set a minimum credit limit (e.g., 500 credits).
Periodic Polling: Execute a GET request to the /v1/balance endpoint.
Alerting: If the returned balance is less than your threshold, trigger an alert via your preferred channel (e.g., Slack, PagerDuty, or email).

Error Handling

When integrating this check, ensure your code accounts for potential API errors:

401 Unauthorized: Check that your X-API-Key is valid and active.
502 Balance query failed: Implement a retry policy for this specific error to ensure your monitoring isn't interrupted by transient network issues.

Conclusion

By treating your account balance as a critical infrastructure metric, you ensure that your verification services—whether they are single-identifier checks or aggregated risk scores—remain available when you need them most. For more details on integrating these services, visit the official documentation.

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

Handling Partial Results in Multi-Service Verification Flows

eKYC Pro — Thu, 20 Aug 2026 03:22:56 +0000

When building identity verification workflows, reliability often hinges on how your application handles non-deterministic outcomes. In a multi-service architecture, such as when using the Combo Check API, you might encounter scenarios where some service nodes return valid registration signals while others return errors due to timeouts.

This guide covers how to architect your integration to parse these partial results effectively.

Understanding the Combo Check Response

The Combo Check API allows you to verify a single identifier against multiple services in one request. Because these checks run in parallel, the API returns a consolidated JSON object. A critical detail for developers is that individual service failures do not cause the entire API call to fail.

When a service fails to return a result within the processing window, it returns an error field (e.g., "timeout") and sets the registered field to null.

Parsing the Response Structure

Your application logic should iterate through the data.results object rather than expecting a uniform response across all requested services. Here is a conceptual approach to mapping these results:

// Conceptual logic for processing the API response
function processComboResults(apiResponse) {
 const results = apiResponse.data.results;

 for (const [service, outcome] of Object.entries(results)) {
 if (outcome.error) {
 console.warn(`Service ${service} failed: ${outcome.error}`);
 // Handle the timeout: log for retry or flag for manual review
 continue;
 }

 if (outcome.registered === null) {
 console.log(`Service ${service} could not determine registration status.`);
 } else {
 console.log(`Service ${service} registered: ${outcome.registered}`);
 }
 }
}

Implementation Checklist

Set Client Timeouts: Ensure your HTTP client is configured with a timeout of at least 15 seconds. This provides enough headroom for the API to process parallel requests and return the status of successful checks even if others time out.
Verify Billing Logic: Note that only determined results are billed. The API response provides a billed_count and total_cost_usd field, allowing you to reconcile costs per service-specific execution.
Implement Individual Retries: If a service returns a timeout error, you do not need to re-run the entire combo. You can isolate the failed service and retry it individually using the /v1/check endpoint.
Handle Null States: Always check for null in the registered field. A null value indicates that the service was unable to verify the identifier, which is distinct from a false (not registered) or true (registered) result.

Conclusion

By treating the Combo Check response as a collection of independent service outcomes, you can build a more resilient verification layer. Instead of failing the entire process due to a single service timeout, focus on extracting the available signals and implementing targeted retries for the specific services that failed to respond.

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

Read the eKYC Pro API docs