Feel free to reach techsupport@surepass.io for any technical support or guidance.
Udyam OTP Async
Overview
Category Details
Child Categories: Udyam OTP Async
APIs in this category: Send OTP, Send OTP Status, Submit OTP, Submit OTP Status
Key Capabilities
Main Functionality
The Udyam OTP Async APIs enable end-to-end, OTP-based verification of Udyam-registered MSME entities. The category covers the complete verification lifecycle — from initiating OTP dispatch to retrieving the final verified registration data — using an asynchronous architecture that supports both webhook callbacks and polling for maximum integration flexibility. On successful verification, the APIs return a comprehensive MSME data payload sourced directly from the Udyam registry, including enterprise classification, financial history, employment details, official address, NIC codes, bank details, and a time-limited certificate link.Asynchronous OTP Dispatch & Delivery Tracking
Initiate OTP delivery to the MSME entity's registered mobile or email using the Send OTP API, then track delivery progress in real time via the Send OTP Status API. The status endpoint returns granular delivery states —
pending, otp_sent, and failed — enabling your application to respond precisely at each stage and avoid prompting users before the OTP has been confirmed as delivered.Secure OTP Submission & Verification
Submit the OTP entered by the user via the Submit OTP API, which links the code to the original session using the
client_id without re-transmitting sensitive registration details. The API handles verification asynchronously, returning an immediate pending acknowledgement while the OTP is validated against the Udyam registry in the background.Verified MSME Data Retrieval
Poll the Submit OTP Status API to retrieve the final verification outcome and — on
completed status — the full Udyam registration dataset. This includes enterprise type, major activity, owner identity, PAN, financial year-wise investment and turnover data, employment breakdown, official and unit addresses, NIC classification codes, portal interest flags, and a pre-signed certificate URL. Seven distinct status values (not_started, pending, completed, failed, update_required, otp_expired, invalid_otp) provide granular control over every possible outcome, enabling tailored application logic and user-facing messaging for each scenario.Common Use Cases
Fintech & Lending
Government & Compliance
B2B Marketplaces
Integration Considerations
Best Practices
otp_sent before displaying the OTP input field in your UI. Prompting users before delivery is confirmed leads to failed submission attempts and poor user experience.data.status values (not_started, pending, completed, failed, update_required, otp_expired, invalid_otp) requires a distinct application response. Map each to a specific user-facing message and next action rather than treating non-completed responses as a single generic failure state.webhook_url in the Send OTP request to receive asynchronous status updates without polling. Reserve the Send OTP Status and Submit OTP Status polling endpoints for environments where inbound webhooks are unavailable, and implement exponential backoff with a polling cap to avoid overloading the API.certificate_link immediately on completed: The pre-signed certificate URL is time-limited. Fetch and store the certificate document in your own secure storage as soon as a completed status is received. Do not persist the URL itself for future use.Important Limitations
otp_expired. Always implement a resend flow and communicate the time constraint clearly in your UI.update_required cannot be resolved by your application: When this status is returned, the MSME entity must update their registration information directly on the official Udyam portal (udyam.gov.in). Your application cannot modify or bypass this requirement — guide users to complete the update before retrying.completed: All Udyam registration fields in the Submit OTP Status response are only populated when data.status is completed. Do not attempt to read enterprise, financial, or address fields for any other status value.client_id is session-scoped: Each client_id is tied to a single OTP verification session. Do not reuse a client_id across multiple verification attempts; initiate a new Send OTP request for each fresh verification.How APIs in this Category Work Together
client_id returned by Send OTP is the shared session identifier that links all subsequent calls — Send OTP Status, Submit OTP, and Submit OTP Status — into a single coherent verification transaction.otp_sent is confirmed, preventing premature submission attempts.pending, Submit OTP Status is the definitive source of truth for the verification outcome — including the full Udyam registration data on completed.webhook_url in the Send OTP request to receive both OTP delivery and final verification status callbacks passively, eliminating the need for active polling of both status endpoints in webhook-capable environments.otp_sent is returned. Present the OTP input to the user, then call Submit OTP with the entered code and client_id. Finally, poll Submit OTP Status — handling all seven possible outcomes — and on completed, extract the full Udyam registration data and archive the certificate. This four-API chain provides a fully automated, consent-driven MSME verification pipeline with no manual steps required.