Understanding the Services List API: A Guide to Dynamic Integration Readiness

When integrating identity verification into your application, hardcoding supported platforms can lead to brittle systems. If a service provider changes availability or you decide to expand your verification coverage, a static configuration requires a code deployment. Instead, you can use the Services List API to build a dynamic, resilient integration that adapts to real-time service availability.

Why Dynamic Readiness Matters

Verification signals—such as platform registration status or risk scores—should be treated as inputs for your internal business logic rather than absolute proof of identity. By querying the GET https://api.ekycpro.com/v1/services endpoint, you can programmatically determine which identifiers (phone or email) are currently supported, allowing your UI to adjust its input fields automatically.

Step 1: Fetching Available Services

Start by implementing a fetcher that retrieves the current service inventory. This ensures that your application only attempts to verify identifiers that the system is currently prepared to process.

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

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

Step 2: Normalizing Your UI Logic

Once you have the list, you can map the data_type field to your frontend components. For example, if your application requires a phone-first approach, you can filter the service list to show only those where data_type is phone and enabled is true.

Implementation Checklist

1. Filter by Requirement: Use the data_type field to distinguish between phone and email verification requirements.
2. Check Availability: Always verify the enabled boolean. Even if a service is listed, a false status indicates that the platform is not currently available for checking.
3. Decouple Signals: Remember that individual service signals (Per-call), combined signals (Combo), and risk scores (Unified Score) are distinct. Use the Services List API to determine if you can run a check, then route to the appropriate API family based on your specific decision-support needs.

Step 3: Testing and Sandboxing

When building your integration, treat the Services List API as your primary source of truth for test fixtures. By mocking the response from /v1/services, you can simulate scenarios where specific platforms are temporarily disabled, allowing you to test your UI's fallback behavior without waiting for real-world outages.

Conclusion

Verifying an identifier is a critical step in security, but it is not authorization. By using the Services List API to dynamically configure your verification flow, you create a more robust system that gracefully handles service changes. Always treat the resulting signals as decision-support data, and ensure your application logic remains the final arbiter for user access and risk management.

For more details on integrating specific verification types, refer to the official documentation.

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