Building Dynamic Verification Flows: Automating Service Discovery with the Services List API

Hardcoding supported services into your application configuration is a common pitfall that leads to brittle integration layers. When your verification logic depends on static lists, you risk breaking your workflow every time a service status changes or a new identifier type is added.

Instead of manual updates, you can build dynamic verification flows that programmatically fetch supported check types and their current availability. This guide walks you through integrating the Services List API to decouple your application logic from static configuration.

Why Automate Service Discovery?

By leveraging the GET /v1/services endpoint, your application can adapt to changes in real-time. Whether you are building a system that handles phone-based checks or email-based identity verification, fetching the available services at runtime ensures your UI and backend logic only attempt operations that are currently supported.

Step 1: Fetching the Service Registry

The foundation of a dynamic flow is the ability to retrieve the current inventory of services. The API provides a straightforward GET request to list all supported types.

curl --location 'https://api.ekycpro.com/v1/services'

Step 2: Parsing the Response

The response returns a success boolean and an array of services. Each object in the array contains the type (the identifier for the service), the data_type (either phone or email), and an enabled flag indicating if the service is currently available for checking.

Example Response Structure

{
 "success": true,
 "services": [
 { "type": "facebook", "data_type": "phone", "enabled": true },
 { "type": "instagram", "data_type": "phone", "enabled": true },
 { "type": "netflix", "data_type": "email", "enabled": true }
 ]
}

Step 3: Implementing the Adapter Logic

Rather than mapping services manually, build an adapter layer that filters the response based on the user's input. This allows your application to dynamically decide which verification methods to present to the end-user.

Conceptual Implementation Pattern

// Conceptual: Filter services based on input type and availability
function getAvailableChecks(inputData, servicesList) {
 return servicesList.filter(service => 
 service.data_type === inputData.type && 
 service.enabled === true
 );
}

Best Practices for Integration

1. Cache Wisely: While the API provides real-time availability, consider caching the results of the service list in your application memory for a short duration to reduce redundant network calls.
2. Handle Availability Gracefully: Always check the enabled field before triggering a check. If a service is marked false, hide that option in your UI to prevent unnecessary errors.
3. Decouple Logic: Treat the service list as the "Source of Truth." By basing your application's capabilities on this response, you ensure that your integration remains resilient to upstream changes without requiring code deployments.

Conclusion

By moving away from static configuration files and toward a dynamic discovery model, you create a more robust verification pipeline. Using the Services List API, your application becomes self-aware of its capabilities, allowing for a smoother, more reliable user experience.

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

---

Read the eKYC Pro API docs