गाड़ी का RC वेरिफ़िकेशन API: डीलर और फ्लीट ऐप के लिए पूरी गाइड

मुख्य बातें

• Endpoint: POST https://api-b2b.stampmitra.in/v1/verify/rc, body में एक ही ज़रूरी field: vehicleNumber (जैसे MH12AB1234)।
• Authentication: Authorization: Bearer <api-key> या x-api-key। Sandbox key sk_test_ से और production key sk_live_ से शुरू होती है।
• API key पर verification.rc.read scope होना ज़रूरी है, वरना 403 आता है।
• हर सफल response में referenceId (format SMV-YYYYMMDD-XXXXXXX) होता है। इसे अपने रिकॉर्ड में सेव करें।
• Production में सिर्फ़ पूरी हुई verification पर पैसा कटता है, प्रति कॉल ₹9। Sandbox में wallet से कुछ नहीं कटता।
• Rate limit का उदाहरण-संदेश docs में है: इस endpoint के लिए 60 सेकंड में 60 requests। अपने ऐप में queue और backoff रखें।
• RC की जानकारी एक निर्णय में मदद करती है, पूरा निर्णय नहीं। बीमा, चालान, हाइपोथिकेशन जैसी बातें अलग से जाँचनी पड़ सकती हैं।
• नंबर, मालिक का नाम और chassis जैसा निजी डेटा सोच-समझकर और कम से कम समय के लिए रखें।

Vehicle RC verification API असल में करती क्या है?

RC यानी Registration Certificate, वह दस्तावेज़ जो बताता है कि कोई गाड़ी किसके नाम पर, किस नंबर से और किस ब्लॉक में रजिस्टर है। जब आप API को vehicleNumber भेजते हैं, StampMitra आपका नंबर पहले अपने यहाँ format के हिसाब से जाँचता है। फ़ॉर्मेट गलत हो तो तुरंत 400 लौट आता है और कुछ नहीं कटता। फ़ॉर्मेट ठीक हो तो नंबर आगे वेरिफ़िकेशन सेवा को जाता है और नतीजा normalize होकर आपको मिलता है।

एक कॉल में क्या-क्या मिलता है

Docs में दिया गया असली response नमूना इन field से बना है: referenceId, regNo, registrationStatus, ownerName, ownerFatherName, vehicleClass, vehicleManufacturerName, model, vehicleColor, chassis, engine, registrationDate, rcStatus, rcExpiryDate, insuranceUpto और isCommercial। यानी एक नज़र में आप गाड़ी की पहचान, मालिक, रजिस्ट्रेशन की स्थिति और बीमा की तारीख देख सकते हैं।

क्या यह सरकारी सेवा है?

नहीं। StampMitra, Bani Global Industries LLP (LLPIN ACI-6373) द्वारा चलाया जाने वाला एक निजी LegalTech प्लेटफ़ॉर्म है। यह किसी सरकारी एजेंसी या लॉ फ़र्म का हिस्सा नहीं है और न ही कानूनी सलाह देता है। गाड़ी रजिस्ट्रेशन की मूल व्यवस्था परिवहन विभाग और सड़क परिवहन मंत्रालय की है। API उस जानकारी तक आपके ऐप को एक सीधा, एक जैसा रास्ता देती है। कोई भी बड़ा फ़ैसला लेने से पहले अपने वकील या संबंधित विशेषज्ञ से पूछ लें।

फ़ॉर्मेट की जाँच और असली जाँच का फ़र्क

दो अलग चीज़ें अक्सर गड्डमड्ड हो जाती हैं। पहली है यह देखना कि नंबर देखने में ठीक लगता है या नहीं: राज्य का कोड, ज़िले का नंबर, अक्षर और चार अंक। दूसरी है यह जानना कि ऐसी कोई गाड़ी सच में दर्ज है या नहीं और किसके नाम है। पहली जाँच आपके अपने कोड में मुफ़्त हो सकती है। दूसरी के लिए API चाहिए। अगर आप सिर्फ़ पहली करके मान लें कि गाड़ी असली है, तो कोई भी ठीक दिखने वाला नंबर लिखकर आपको धोखा दे सकता है। इसलिए पहली जाँच सस्ता छन्ना है और दूसरी असली पुष्टि।

किसे ज़रूरत पड़ती है: सही और गलत इस्तेमाल

हर ऐप को RC वेरिफ़िकेशन नहीं चाहिए। नीचे की तालिका बताती है कि कब यह API सही बैठती है और कब कोई और चीज़ बेहतर है।

सीधा नियम: जब आपका फ़ैसला "यह गाड़ी इसी नंबर और इसी मालिक के नाम से दर्ज है" पर टिका हो, तब API लगाइए। जब फ़ैसला किसी ऐसी चीज़ पर टिका हो जो response में है ही नहीं, तब कोई दूसरा स्रोत जोड़िए।

तीन सवाल जो हर टीम को पूछने चाहिए

API जोड़ने से पहले तीन सवाल लिख लीजिए। एक, हमारा कौन-सा फ़ैसला इस जाँच पर रुका है? दो, उस फ़ैसले के लिए कौन-से field चाहिए और कौन-से नहीं? तीन, जाँच में गड़बड़ मिले तो अगला कदम क्या होगा: सौदा रोकना, इंसान को भेजना या ग्राहक से और कागज़ माँगना? जवाब साफ़ हों तो इंटीग्रेशन छोटा और काम का बनता है। जवाब धुँधले हों तो आप बस पैसे खर्च करके ऐसा डेटा जमा करेंगे जिसका कोई इस्तेमाल नहीं।

रफ़्तार कार्स का सफ़र: डीलर ऐप में RC जाँच कहाँ बैठती है

मान लीजिए "रफ़्तार कार्स" एक मध्यम आकार का डीलर है जो ग्राहकों से पुरानी कारें ख़रीदता है। उनका ऐप एजेंट के फ़ोन पर चलता है। एजेंट ग्राहक के घर जाता है, गाड़ी की फ़ोटो लेता है और नंबर डालता है। पहले एजेंट कागज़ की फ़ोटो भेजता था और ऑफ़िस में कोई उसे पोर्टल पर देखकर मिलाता था। इसमें घंटों लगते थे और कभी-कभी सौदा हाथ से निकल जाता था।

नया प्रवाह

नया प्रवाह चार क़दम का है। एजेंट नंबर डालता है। ऐप आपके अपने backend को कॉल करता है, फ़ोन से सीधे StampMitra नहीं। backend /v1/verify/rc बुलाता है। response आने पर backend तीन चीज़ें मिलाता है: registrationStatus और rcStatus ठीक हैं या नहीं, ownerName ग्राहक के बताए नाम से मेल खाता है या नहीं, और insuranceUpto आज की तारीख से आगे है या नहीं। तीनों में से कोई भी गड़बड़ हो तो एजेंट की स्क्रीन पर पीला निशान दिखता है और सौदा "जाँच बाकी" में चला जाता है।

यहाँ API key फ़ोन में क्यों नहीं रखते

अगर key ऐप के अंदर रख दी तो कोई भी ऐप खोलकर उसे निकाल सकता है, और फिर आपके wallet से पैसे कटवा सकता है। इसलिए key हमेशा server पर रहती है। आगे के उदाहरण इसी बात को मानकर लिखे हैं। इस बारे में API keys का दस्तावेज़ भी देखिए।

एजेंट की स्क्रीन पर क्या दिखे

एजेंट के लिए कच्चा JSON बेकार है। स्क्रीन पर तीन रंग रखिए। हरा: सब मेल खाता है। पीला: कुछ मेल नहीं खा रहा, जैसे बीमा की तारीख निकल गई या नाम थोड़ा अलग है। लाल: गाड़ी का स्टेटस ठीक नहीं या जाँच पूरी ही नहीं हुई। हर पीले या लाल निशान के साथ एक पंक्ति में कारण लिखिए, जैसे "बीमा की तारीख निकल चुकी है"। नीचे छोटे अक्षरों में referenceId रखिए ताकि ऑफ़िस वाले बाद में उसी जाँच को ढूँढ सकें। एजेंट को मालिक का पिता का नाम या chassis जैसी चीज़ें हर बार दिखाने की ज़रूरत नहीं, उन्हें "विवरण देखें" के पीछे रखिए।

पहला कदम: API key और सही scope

RC endpoint पर कॉल करने के लिए आपके पास ऐसी API key होनी चाहिए जिस पर verification.rc.read scope हो। Scope नहीं होगा तो key सही होने पर भी 403 आएगा, और संदेश कुछ ऐसा होगा: "API key is valid but lacks the required scope for this endpoint."

Sandbox key कैसे मिलती है

StampMitra पर signup करने पर self-serve तरीके से आपको sk_test_ वाली sandbox key मिलती है। इसमें क्रेडिट कार्ड या हाथ से अनुमोदन की ज़रूरत नहीं बताई गई है। Production key (sk_live_) के लिए आपकी संस्था का KYC-approved होना ज़रूरी है। Sandbox और production keys का फ़र्क अलग गाइड में विस्तार से है।

Key भेजने के दो तरीके

दोनों में से कोई भी चलेगा:

Authorization: Bearer sk_test_xxxxxxxxxxxx
# या
x-api-key: sk_test_xxxxxxxxxxxx

Key को environment variable में रखिए

कोड में key कभी न लिखें। STAMPMITRA_API_KEY जैसा एक environment variable बनाइए (StampMitra के quickstart में भी यही नाम इस्तेमाल हुआ है), और उसे सिर्फ़ server पर पढ़िए। Git में .env फ़ाइल कभी commit न करें, और log में key या पूरा header न छापें।

पहली कॉल: cURL से सीधा परीक्षण

सबसे पहले बिना किसी लाइब्रेरी के एक कॉल करके देखिए कि सब जुड़ा है। नीचे docs वाला ही नमूना नंबर है, MH12AB1234।

curl -X POST "https://api-b2b.stampmitra.in/v1/verify/rc" \
  -H "Authorization: Bearer $STAMPMITRA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"vehicleNumber":"MH12AB1234"}'

सफल response कैसा दिखता है

Docs में दिया असली नमूना:

{
  "referenceId": "SMV-20260927-3D71Q9",
  "regNo": "MH12AB1234",
  "registrationStatus": "VALID",
  "ownerName": "RAHUL KUMAR",
  "ownerFatherName": "SURESH KUMAR",
  "vehicleClass": "LMV",
  "vehicleManufacturerName": "MARUTI SUZUKI",
  "model": "SWIFT",
  "vehicleColor": "WHITE",
  "chassis": "MA3ERLF1S00123456",
  "engine": "K12MN1234567",
  "registrationDate": "2019-05-14",
  "rcStatus": "ACTIVE",
  "rcExpiryDate": "2034-05-13",
  "insuranceUpto": "2025-05-13",
  "isCommercial": false
}

यह सब नमूना डेटा है, किसी असली व्यक्ति या गाड़ी का नहीं। ध्यान दीजिए कि इस नमूने में insuranceUpto की तारीख आज (अक्टूबर 2026) से पहले की है। यानी API ने गाड़ी को "VALID/ACTIVE" बताया, फिर भी बीमा निकल चुका दिख रहा है। यह तुलना आपको अपने कोड में करनी होगी, API अपने आप "अस्वीकार" नहीं करती।

Header और body की चेकलिस्ट

• Method POST, content type application/json।
• Body में vehicleNumber string के रूप में, बिना खाली जगह के।
• Auth header सही, और key पर RC scope।
• सिर्फ़ HTTPS पर बात कीजिए और कॉल हमेशा server से कीजिए।

तारीखों का सही हिसाब

registrationDate, rcExpiryDate और insuranceUpto सब YYYY-MM-DD रूप में आते हैं। इन्हें अपने सर्वर पर तारीख की तरह पढ़िए, स्ट्रिंग की तरह नहीं, और तुलना भारतीय समय के हिसाब से कीजिए। एक आम चूक यह है कि "आज" की तारीख UTC में निकल जाती है और रात के कुछ घंटों में नतीजा एक दिन आगे-पीछे दिखता है। बीमा के लिए यह भी तय कर लीजिए कि आख़िरी तारीख वाले दिन को आप "बाकी" मानेंगे या नहीं, और वही नियम पूरे ऐप में एक जगह लिख दीजिए ताकि हर स्क्रीन एक जैसा बर्ताव करे।

Response के field पढ़ना: कौन-सा field किस फ़ैसले में काम आता है

तालिका में सिर्फ़ वही field हैं जो docs के नमूने में मौजूद हैं। अगर आपको नमूने से बाहर कोई field दिखे तो उसे अनुबंध न मानिए।

नाम मिलाते समय सावधानी

ownerName बड़े अक्षरों में आता है और रिकॉर्ड में नाम का क्रम या स्पेलिंग आपके ग्राहक के बताए नाम से अलग हो सकती है। इसलिए दोनों नामों को बड़े अक्षरों में बदलिए, फालतू खाली जगह हटाइए और फिर तुलना कीजिए। हूबहू न मिले तो सीधा "फ़र्ज़ी" मत मानिए, इंसान से एक बार देखने को कहिए। (PAN API में अलग से name भेजकर मिलान कराने की सुविधा है, पर RC endpoint का docs में सिर्फ़ vehicleNumber है, इसलिए नाम का मिलान आपके कोड में होगा।)

Status field पर भरोसे का तरीका

नमूने में सिर्फ़ VALID और ACTIVE दिखते हैं। बाकी संभावित मान docs में नहीं हैं। इसलिए सुरक्षित तरीका यह है कि सिर्फ़ जाने-पहचाने "अच्छे" मान को पास मानिए और बाकी हर मान को "जाँच बाकी" में डालिए, न कि अपनी तरफ़ से अंदाज़ा लगाकर नए मान गढ़िए।

Node.js में डीलर का backend

रफ़्तार कार्स का backend Node.js में है। नीचे का कोड सिर्फ़ docs वाला endpoint और header इस्तेमाल करता है। Node 18+ में fetch पहले से मिलता है।

// verifyRc.js
const BASE = "https://api-b2b.stampmitra.in";

export function normalizeVehicleNumber(input) {
  return String(input || "").toUpperCase().replace(/[\s-]/g, "");
}

export async function verifyRc(vehicleNumber) {
  const res = await fetch(`${BASE}/v1/verify/rc`, {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.STAMPMITRA_API_KEY}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ vehicleNumber: normalizeVehicleNumber(vehicleNumber) }),
  });

  const data = await res.json();
  if (!res.ok) {
    const e = data.error || {};
    const err = new Error(e.message || "RC verification failed");
    err.status = res.status;
    err.code = e.code;
    err.requestId = e.requestId;
    throw err;
  }
  return data; // referenceId, ownerName, rcStatus ...
}

फ़ैसला लेने वाला हिस्सा

export function dealerDecision(rc, sellerName, today = new Date()) {
  const same = (a, b) =>
    a.toUpperCase().replace(/\s+/g, " ").trim() ===
    b.toUpperCase().replace(/\s+/g, " ").trim();

  const problems = [];
  if (rc.registrationStatus !== "VALID") problems.push("registration_status");
  if (rc.rcStatus !== "ACTIVE") problems.push("rc_status");
  if (!same(rc.ownerName, sellerName)) problems.push("owner_name_mismatch");
  if (new Date(rc.insuranceUpto) < today) problems.push("insurance_expired");

  return {
    referenceId: rc.referenceId,
    ok: problems.length === 0,
    problems,
  };
}

ध्यान दीजिए कि ok: false का मतलब सौदा रद्द नहीं है। बीमा खत्म होना यूज़्ड कार में आम बात है और डीलर नया बीमा करवा देता है। इसीलिए हम problems की सूची लौटाते हैं और एजेंट को ज़रूरत के हिसाब से अलग-अलग कदम दिखाते हैं।

अपना डेटा मॉडल कैसा रखें

Backend में एक टेबल रखिए जिसमें vehicleNumber, referenceId, जाँच की तारीख, नतीजे का सार (पास, चेतावनी, फ़ेल) और जिस उपयोगकर्ता ने जाँच चलाई उसकी पहचान हो। पूरा response JSON अलग से, सीमित अवधि के लिए, एन्क्रिप्टेड जगह में रखा जा सकता है। इससे सपोर्ट के सवाल का जवाब देना आसान होता है, और डेटा हटाने की बारी आए तो एक ही जगह से हट जाता है।

Python में फ्लीट ऑपरेटर का उदाहरण

अब "त्रिवेणी लॉजिस्टिक्स" की कहानी लीजिए। उनके पास कई शहरों में ट्रक हैं और हर महीने नई गाड़ियाँ जुड़ती हैं। ऑपरेशन टीम एक CSV में गाड़ी नंबर डालती है और एक स्क्रिप्ट उन्हें जाँचती है। वही काम Python में, requests के साथ:

import os, time, requests

BASE = "https://api-b2b.stampmitra.in"
HEADERS = {
    "Authorization": f"Bearer {os.environ['STAMPMITRA_API_KEY']}",
    "Content-Type": "application/json",
}

def verify_rc(vehicle_number: str) -> dict:
    r = requests.post(
        f"{BASE}/v1/verify/rc",
        headers=HEADERS,
        json={"vehicleNumber": vehicle_number.upper().replace(" ", "")},
        timeout=30,
    )
    body = r.json()
    if not r.ok:
        e = body.get("error", {})
        raise RuntimeError(f"{r.status_code} {e.get('code')}: {e.get('message')} ({e.get('requestId')})")
    return body

def check_fleet(numbers):
    rows = []
    for n in numbers:
        try:
            rc = verify_rc(n)
            rows.append({
                "regNo": rc["regNo"],
                "referenceId": rc["referenceId"],
                "commercial": rc["isCommercial"],
                "rcStatus": rc["rcStatus"],
                "insuranceUpto": rc["insuranceUpto"],
            })
        except RuntimeError as e:
            rows.append({"regNo": n, "error": str(e)})
        time.sleep(1.1)  # सीमा से नीचे रहने के लिए एक कॉल प्रति सेकंड के आसपास
    return rows

फ्लीट के लिए ख़ास बातें

फ्लीट कंपनी के लिए isCommercial बहुत काम का field है। अगर किसी ट्रक के लिए यह false आए तो वह गाड़ी निजी श्रेणी में दर्ज दिखती है। यह पहली नज़र की चेतावनी है कि आगे के कागज़ात (जैसे परमिट या फिटनेस) अलग से देखने पड़ सकते हैं। ये दूसरे दस्तावेज़ इस endpoint के response का हिस्सा नहीं हैं, इसलिए उन्हें अपनी प्रक्रिया में अलग से जोड़िए।

हर महीने दोबारा जाँच भी की जा सकती है, पर ध्यान रहे कि हर सफल कॉल पर production में पैसे लगते हैं। इसलिए सिर्फ़ उन गाड़ियों की दोबारा जाँच कीजिए जिनकी insuranceUpto या rcExpiryDate पास आ रही है, सबकी नहीं।

CSV से हफ़्ते की रिपोर्ट

फ्लीट वाली स्क्रिप्ट का नतीजा एक रिपोर्ट में बदलना सबसे काम का है। हर पंक्ति में regNo, referenceId, rcStatus, insuranceUpto और "कार्रवाई चाहिए" का निशान रखिए। जिन गाड़ियों में error लिखा आए उन्हें अलग शीट में रखिए और बाद में दोबारा चलाइए। इस तरह ऑपरेशन टीम सिर्फ़ अपवादों पर नज़र डालती है, सैकड़ों ठीक पंक्तियों पर नहीं।

Errors और उन्हें संभालने का तरीका

StampMitra हर गलती एक ही ढाँचे में लौटाता है: { "error": { "code", "message", "requestId" } }। इसमें stack trace या डेटाबेस की गड़बड़ी कभी नहीं दिखती। RC endpoint के docs में ये उदाहरण दिए हैं:

400 पर कटौती क्यों नहीं होती

Docs के अनुसार इनपुट का फ़ॉर्मेट पहले ही जाँच लिया जाता है, इसलिए गलत नंबर 400 के साथ तुरंत लौटता है और उसे वेरिफ़िकेशन के लिए भेजा ही नहीं जाता। फिर भी अपने ऐप में नंबर पहले से साफ़ कीजिए (बड़े अक्षर, खाली जगह और हाइफ़न हटाना)। इससे उपयोगकर्ता का समय और आपके सर्वर की कॉल दोनों बचती हैं।

429 और 502 का फ़र्क

429 का मतलब है कि आप ज़्यादा तेज़ चल रहे हैं। इसका इलाज है धीमा होना, backoff लगाना और queue बनाना। 502 का मतलब है कि पीछे की सेवा उस वक़्त नहीं मिली। उसे थोड़ी देर बाद दोबारा आज़माइए। कभी भी तुरंत बिना रुके लूप में दोबारा कॉल मत कीजिए, वरना आप खुद ही 429 में फँस जाएँगे। हर गलती के लिए requestId सेव कीजिए, क्योंकि सपोर्ट से बात करते समय यही सबसे काम आता है। गलतियों के पूरे पैटर्न के लिए API errors वाली गाइड भी पढ़िए।

"नकारात्मक" नतीजा भी एक पूरा नतीजा है

एक आम ग़लतफ़हमी यह है कि जब API कहे "गाड़ी नहीं मिली" तो यह कोई गड़बड़ है और पैसा वापस आना चाहिए। Docs की टिप्पणी साफ़ है: referenceId हर बार मौजूद रहता है, और सकारात्मक व नकारात्मक दोनों तरह के निर्णय पूरी, billable verification हैं। यानी "नहीं मिला" भी एक सही जवाब है और उस पर प्रति कॉल शुल्क लग सकता है। यह भी लिखा है कि referenceId idempotency key नहीं है, यानी उसे दोबारा भेजकर कॉल को "वही कॉल" नहीं बनाया जा सकता।

इसका असर आपके डिज़ाइन पर

इसका सीधा नतीजा यह है कि आपको अपने कोड में तीन अलग स्थितियाँ संभालनी होंगी: कॉल सफल और गाड़ी ठीक, कॉल सफल पर गाड़ी में दिक़्क़त (जैसे status ठीक नहीं), और कॉल असफल (4xx/5xx)। तीसरी स्थिति में कोई verification पूरी नहीं हुई, पहली दो में हुई है। UI में इन्हें अलग-अलग संदेश दीजिए। "नहीं मिला" को "सर्वर में गड़बड़" की तरह मत दिखाइए, और उपयोगकर्ता को ग़लत नंबर डालने पर बार-बार कोशिश करने से रोकने के लिए सत्यापित फ़ॉर्मेट वाली जाँच पहले लगाइए।

दोहरी कॉल से बचना

फ़ोन का नेटवर्क कमज़ोर हो तो एजेंट "जाँचें" बटन कई बार दबा देता है। हर दबाव पर अगर backend नई कॉल करे तो कई verification बिल हो सकते हैं। इसलिए backend में पहले अपना रिकॉर्ड देखिए: उसी नंबर के लिए हाल की referenceId मौजूद है तो वही नतीजा दिखाइए। बटन को लोडिंग के दौरान बंद भी रखिए।

निजी डेटा, सहमति और सुरक्षा

RC के response में मालिक का नाम, पिता का नाम, chassis और engine नंबर जैसी चीज़ें होती हैं जो किसी व्यक्ति से जुड़ी हो सकती हैं। यह कानूनी सलाह नहीं है, पर सामान्य अच्छा तरीका नीचे दिया है। Digital Personal Data Protection Act 2023 के सटीक प्रावधान और आपकी भूमिका (data fiduciary या processor) के लिए अपने वकील से पूछिए। मैं यहाँ किसी धारा संख्या का दावा नहीं कर रहा क्योंकि आधिकारिक पाठ इस लेख की तैयारी के समय खुल नहीं सका।

चार आदतें

1. मक़सद तय रखिए। अगर जाँच सिर्फ़ गाड़ी ख़रीदने से पहले की सत्यता के लिए है तो उसी मक़सद के लिए इस्तेमाल कीजिए, मार्केटिंग के लिए नहीं।
2. सहमति और सूचना। जिस व्यक्ति की गाड़ी की जाँच हो रही है उसे बताइए कि जाँच क्यों हो रही है। यह बात आपकी गोपनीयता नीति और ऐप के फ़ॉर्म में साफ़ लिखी हो।
3. कम से कम रखिए। सब कुछ सेव करने के बजाय वही रखिए जो ज़रूरी हो: referenceId, regNo, नतीजे का सार और तारीख। chassis और मालिक का नाम तभी रखिए जब ज़रूरत हो, और काम पूरा होने पर हटाने की अवधि तय कीजिए।
4. पहुँच सीमित रखिए। log में पूरा response मत छापिए। भूमिका के हिसाब से ही लोग यह डेटा देखें।

StampMitra की तरफ़ की सुरक्षा-सुविधाएँ

Pricing पेज के अनुसार हर key पर IP allowlisting और scopes उपलब्ध हैं। Production key को उसी सर्वर के IP तक सीमित रखिए जो API बुलाता है और RC key को सिर्फ़ verification.rc.read scope दीजिए, ताकि चोरी होने पर नुकसान छोटा रहे। संबंधित नीतियाँ आप API सुरक्षा नीति, developer privacy policy और acceptable use policy में पढ़ सकते हैं। यह भी याद रखिए कि किसी और की गाड़ी की जानकारी ऐसे मक़सद से निकालना जो नीति से मेल न खाए, पाबंदी में आ सकता है। इसे अपने उपयोग के साथ ज़रूर जाँचिए।

टेस्ट और असली डेटा को अलग रखना

अपने ऐप में एक साफ़ निशान रखिए कि जाँच sandbox की थी या production की। कई बार टीमें sandbox के नतीजे रिपोर्ट में मिला देती हैं और फिर समझ नहीं पातीं कि गाड़ी का मालिक इतना अजीब क्यों दिख रहा है। इसका आसान उपाय यह है कि key के प्रकार (sk_test_ या sk_live_) के आधार पर हर रिकॉर्ड पर environment लिख दें। साथ ही sandbox key को कभी production सर्वर पर और production key को कभी डेवलपर के लैपटॉप पर न रखें।

Sandbox में टेस्ट कैसे करें

Sandbox में आप sk_test_ key से असली जैसी कॉल करके अपना पूरा कोड परख सकते हैं। Pricing पेज के मुताबिक sandbox कॉल sandbox डेटा पर चलती हैं और wallet से कभी पैसा नहीं काटतीं, और वे metered और audit-logged रहती हैं। इसका मतलब यह भी है कि sandbox में आने वाला डेटा असली गाड़ी का नहीं मानना चाहिए।

क्या-क्या टेस्ट करें

• ख़ुशी वाला रास्ता: docs वाला नंबर MH12AB1234 भेजिए और देखिए कि आपका कोड सारे field सही तरह पढ़ता है।
• गलत फ़ॉर्मेट: जानबूझकर MH12 या खाली स्ट्रिंग भेजिए। 400 और BAD_REQUEST के साथ संदेश आना चाहिए और आपका UI उसे सही शब्दों में दिखाए।
• गलत key: एक ग़लत key से कॉल कीजिए ताकि 401 वाला रास्ता चले।
• scope की कमी: ऐसी key आज़माइए जिस पर RC scope न हो, 403 देखने के लिए।
• बीमा की तारीख: नमूने की पुरानी insuranceUpto का फ़ायदा उठाकर अपनी "बीमा खत्म" वाली लॉजिक जाँचिए।
• तेज़ी: थोड़े समय में कई कॉल भेजकर देखिए कि आपकी queue और backoff काम करती है। Sandbox की सीमाएँ production जैसी ही होंगी, यह docs में नहीं लिखा है, इसलिए production की सीमा का अंदाज़ा सिर्फ़ sandbox से मत लगाइए।

ऑटोमेटेड टेस्ट

अपने यूनिट टेस्ट में असली API की जगह एक नकली (mock) जवाब रखिए, ताकि CI में कॉल न जाए। एक या दो integration टेस्ट ही sandbox key से चलाइए और उन्हें अलग रखिए। Postman collection से आप बिना कोड लिखे भी endpoint आज़मा सकते हैं।

टीम को समझाने की बातें

Go-live से पहले एक छोटी बैठक में ऑपरेशन, सपोर्ट और बिक्री टीम को बताइए कि जाँच का नतीजा किन शब्दों में दिखेगा और "नहीं मिला" का क्या मतलब है। जब सपोर्ट किसी ग्राहक से कहे कि "आपकी गाड़ी की जाँच में बीमा की तारीख निकली हुई दिखी", तो वह जानता हो कि यह नतीजा एक तारीख पर आधारित है, बीमा कंपनी की पुष्टि नहीं। इतना स्पष्ट हो तो ग़लतफ़हमी और बहस दोनों घटती हैं।

Production में जाने की तैयारी

जब sandbox में सब ठीक चले, तब production की तरफ़ बढ़िए। स्टेप क्रम से:

1. संस्था की KYC। Dashboard से production access के लिए आवेदन कीजिए। मंज़ूरी के बाद ही sk_live_ key बनती है।
2. wallet में क्रेडिट। Dashboard में Billing से API credit wallet भर लीजिए। 402 से बचने के लिए एक न्यूनतम सीमा तय कीजिए और उसके नीचे जाते ही अपनी टीम को सूचना भेजिए।
3. key का स्कोप और IP। RC के लिए अलग key बनाइए और सिर्फ़ उसी सर्वर के IP से चलने दीजिए।
4. लागत का अनुमान। हर सफल कॉल पर ₹9 के हिसाब से महीने की मात्रा गुणा कर लीजिए। मौजूदा कीमत हमेशा pricing पेज पर देखिए।
5. निगरानी। हर कॉल का status, requestId और referenceId लॉग कीजिए। 429, 402 और 502 की गिनती पर अलर्ट लगाइए।
6. पुराने नतीजों की नीति। तय कीजिए कि कितने दिन पुराना नतीजा "ताज़ा" माना जाएगा, ताकि एक ही गाड़ी पर रोज़ पैसे न कटें।

Go-live की जाँच-सूची

key किसी रिपॉज़िटरी में नहीं है, कॉल सिर्फ़ server से जाती है, RC key पर सिर्फ़ ज़रूरी scope है, गलती की हर श्रेणी का UI संदेश है, डेटा रखने की अवधि तय है और टीम को पता है कि "नहीं मिला" भी बिल होता है। इतना हो जाए तो आप तैयार हैं।

एक छोटा लागत-हिसाब

मान लीजिए त्रिवेणी लॉजिस्टिक्स के पास पचास ट्रक हैं और वह हर महीने सबकी जाँच दोहराती है। तब महीने में पचास सफल कॉल होंगी, यानी पचास गुणा ₹9। अगर वह सिर्फ़ उन्हीं ट्रकों की जाँच करे जिनकी बीमा-तारीख अगले तीस दिनों में पड़ रही है, तो कॉल की संख्या घटकर ज़रूरत भर रह जाती है। हर महीने के आख़िर में wallet का खर्च और कॉल की संख्या मिलाकर देखिए। पैमाना बदलते ही यही गणित सैकड़ों या हज़ारों गाड़ियों पर लागू होता है, और तभी नियम बनाना फ़ायदेमंद होता है।

ऑन-कॉल और रोज़ की निगरानी

Production में गया ऐप चुपचाप टूट सकता है, इसलिए रोज़ एक छोटा डैशबोर्ड देखिए: कितनी कॉल हुईं, कितनी में 400, 402, 429 या 502 आया, और औसतन एक कॉल में कितना समय लगा। अचानक 400 बढ़ें तो शायद आपके फ़ॉर्म में कोई गड़बड़ आ गई है। 402 बढ़ें तो wallet भरना है। 502 बढ़ें तो status पेज देखिए और थोड़ी देर बाद दोबारा कोशिश करने की लॉजिक चलने दीजिए। बदलाव की सूचना और नीतियों के लिए संस्था में किसी एक व्यक्ति को ज़िम्मेदार बना दीजिए, ताकि StampMitra की तरफ़ से आने वाली कोई सूचना छूट न जाए।

आम गलतियाँ जो टीमें करती हैं

कुछ गलतियाँ इतनी बार दिखती हैं कि उन्हें अलग से लिख देना ठीक रहेगा।

• Key को ऐप में रखना। मोबाइल या ब्राउज़र के कोड में key डालने से वह कोई भी निकाल सकता है। हमेशा अपना backend बीच में रखिए।
• फ़ॉर्मेट जाँच न करना। बिना साफ़ किए सीधे उपयोगकर्ता का लिखा नंबर भेज देने से 400 बढ़ते हैं। ऊपर के normalizeVehicleNumber जैसा कोई छोटा कदम काफ़ी है।
• हर बार नई कॉल। वही नंबर दोबारा जाँचने के लिए पैसे खर्च होते हैं। अपने यहाँ हाल का नतीजा रखिए।
• 429 पर तुरंत दोबारा कोशिश। यह स्थिति और बिगाड़ता है। प्रतीक्षा बढ़ाते हुए दोबारा कोशिश कीजिए।
• सिर्फ़ registrationStatus देखना। गाड़ी "VALID" होकर भी बीमा बाकी न हो सकता है, या नाम बेचने वाले से अलग हो सकता है। कई field साथ में देखिए।
• "नहीं मिला" को सर्वर की ग़लती समझना। यह एक वैध नतीजा है, जैसा ऊपर बताया गया।
• referenceId न सेव करना। बाद में विवाद या सपोर्ट में इसी की ज़रूरत पड़ती है।
• निजी डेटा लॉग में छोड़ देना। डिबग के लिए छापे गए response बाद में लीक का सबब बनते हैं।
• Sandbox के डेटा पर भरोसा। वहाँ का मालिक और गाड़ी असली नहीं हैं।

कब इंसान से देखने को कहें

सब कुछ स्वचालित नहीं करना चाहिए। अगर नाम सिर्फ़ थोड़ा अलग है, अगर rcStatus आपके जाने-पहचाने मान से अलग है, या अगर गाड़ी की क्लास और विज्ञापन की गाड़ी में फ़र्क दिखे, तो मामला किसी जानकार कर्मचारी को भेजिए। API का काम जाँच तेज़ और एक जैसी करना है। अंतिम निर्णय, खासकर बड़ी रकम वाले सौदे में, इंसान के हाथ में रहे तो बेहतर है।

Troubleshooting: कुछ गड़बड़ हो तो क्रम से देखिए

जब कॉल नहीं चल रही, इस क्रम से जाँच कीजिए। हर क़दम पर एक ही चीज़ बदलिए।

"401 आ रहा है"

पहले देखिए कि environment variable सच में सेट है और उसमें खाली जगह या नई लाइन नहीं है। फिर देखिए कि header का नाम Authorization है और मान Bearer से शुरू होता है (या x-api-key इस्तेमाल हो रहा है)। यह भी देखें कि sandbox key से production URL पर या उलटा कुछ तो नहीं हो रहा।

"403 आ रहा है"

key वैध है पर scope नहीं। Dashboard में उस key के scopes देखिए और verification.rc.read जुड़वाइए। अगर आपकी संस्था को RC उत्पाद की अनुमति ही नहीं मिली, तो सपोर्ट से या [email protected] पर पूछिए।

"400 आ रहा है जबकि नंबर सही लगता है"

नंबर में खाली जगह, हाइफ़न या छोटे अक्षर तो नहीं? Docs का उदाहरण फ़ॉर्मेट MH12AB1234 है। पहले साफ़ कीजिए। फिर भी वही हो तो error का message हूबहू पढ़िए, क्योंकि वह बताता है कि कौन-सा नियम टूटा। BH-series या दूसरे अलग फ़ॉर्मेट वाले नंबर इस endpoint पर चलेंगे या नहीं, यह docs में नहीं लिखा, इसलिए sandbox और production में एक बार आज़माकर देखिए।

"402 आ रहा है"

wallet में पर्याप्त क्रेडिट नहीं। Billing से जोड़िए। अपनी तरफ़ से न्यूनतम बैलेंस पर अलर्ट रखिए ताकि सुबह की भीड़ में यह न रुके।

"कभी चलता है, कभी नहीं"

429 और 502 की गिनती देखिए। अगर 429 है तो कॉल की रफ़्तार घटाइए। अगर 502 है तो backoff के साथ दोबारा कोशिश कीजिए और requestId सपोर्ट को भेजिए। लगातार रहे तो StampMitra का status पेज भी देख लीजिए।

नंबर कहाँ से आता है, इसका भी ध्यान रखिए

गाड़ी का नंबर आप किसी फ़ॉर्म में हाथ से लिखवाते हैं, नंबर-प्लेट की फ़ोटो से पढ़ते हैं या ग्राहक के दिए कागज़ से उतारते हैं। हर तरीके में गलती की गुंजाइश अलग है। हाथ से लिखने में O और 0, I और 1 की गड़बड़ी आम है। फ़ोटो से पढ़ने में कोई अक्षर धुँधला हो सकता है। इसलिए जाँच से पहले उपयोगकर्ता को साफ़ किया हुआ नंबर एक बार दिखाकर पुष्टि करवाइए। इससे गलत नंबर पर पैसे खर्च होने और किसी और की गाड़ी की जानकारी ग़लती से सामने आ जाने, दोनों का जोखिम घटता है।

सपोर्ट के लिए एक अच्छा टिकट कैसा हो

जब कभी सपोर्ट को लिखना पड़े, तो टिकट में requestId, referenceId (अगर मिला हो), कॉल का समय, HTTP स्टेटस और error code ज़रूर रखिए। पूरा API key कभी न भेजें, चाहे सपोर्ट वाला माँगे भी। निजी डेटा वाले response को भेजना ज़रूरी हो तो नाम और chassis जैसे हिस्से ढक दीजिए। साफ़ टिकट पर जवाब जल्दी और ठोस मिलता है।

StampMitra के बाकी APIs के साथ RC को जोड़ना

RC अकेली नहीं चलती। असल कामों में यह दूसरे verification के साथ आती है, और StampMitra के सभी verification endpoint एक जैसी auth, एक जैसे error ढाँचे और referenceId के साथ आते हैं, इसलिए एक बार का कोड आसानी से बाकी में दोहराया जा सकता है।

यूज़्ड कार का सौदा: कई जाँच एक साथ

रफ़्तार कार्स बेचने वाले की पहचान भी जाँचना चाहे तो PAN verification जोड़ सकता है। गाड़ी चलाकर टेस्ट-ड्राइव कराने के लिए ग्राहक का लाइसेंस जाँचना हो तो Driving Licence API उपलब्ध है, जिसमें dlNumber और dob दोनों भेजने पड़ते हैं। हर जाँच अलग कॉल है और अलग referenceId देती है, इसलिए अपने डेटाबेस में सौदे की एक पंक्ति के साथ ये सारे id जोड़कर रखिए।

फ्लीट के लिए व्यावसायिक जाँच

अगर फ्लीट कंपनी किसी ट्रांसपोर्ट पार्टनर को जोड़ती है, तो उसकी कंपनी की जाँच के लिए GSTIN, CIN और Udyam वाली व्यावसायिक वेरिफ़िकेशन गाइड देखिए। गाड़ी के नंबर की जाँच उसके बाद एक और परत बन जाती है।

NBFC और लोन

लोन देने वाली संस्थाएँ RC जाँच को बाकी KYC के साथ एक ही प्रवाह में रखती हैं। इस पर फिनटेक और NBFC के लिए KYC API वाला use-case पढ़ने लायक है। ध्यान रहे कि हाइपोथिकेशन (गाड़ी पर लोन का दावा) जैसी जानकारी इस endpoint के response में नहीं है, इसलिए उसे अलग तरीके से देखना होगा।

AI टूल और SDK

अगर आप Claude, Cursor या Lovable जैसे टूल से इंटीग्रेशन बनवा रहे हैं तो Build with AI पेज पर तैयार prompt मिलते हैं, और MCP व SDKs पेज बताते हैं कि और कौन-से रास्ते उपलब्ध हैं। जो भी बनवाएँ, ऊपर लिखी बातें (key server पर, फ़ॉर्मेट की सफ़ाई, backoff) आख़िर में खुद जाँच लीजिए।

StampMitra आपकी कैसे मदद करता है

StampMitra, Bani Global Industries LLP (LLPIN ACI-6373) द्वारा चलाया जाने वाला एक निजी LegalTech प्लेटफ़ॉर्म है। हम सरकारी संस्था नहीं हैं और न कानूनी सलाह देते हैं, पर डेवलपर के लिए पहचान, व्यवसाय और स्टांप से जुड़े काम को API के रूप में सरल बनाते हैं।

आज की तारीख़ में RC के लिए StampMitra देता है: POST /v1/verify/rc पर एक endpoint जो vehicleNumber लेकर ऊपर बताए सारे field लौटाता है, verification.rc.read scope के साथ API key, sandbox के लिए sk_test_ और production के लिए sk_live_ key, हर कॉल पर referenceId, एक जैसा error ढाँचा जिसमें requestId होता है, और प्रति सफल कॉल की मीटरिंग। Sandbox मुफ़्त है और wallet से कुछ नहीं काटता। Production में हर सफल कॉल की कीमत आप pricing पेज पर देख सकते हैं, जो ऊपर ₹9 के रूप में दिखाई गई है। Per-key IP allowlisting और scopes भी उपलब्ध हैं।

हम जानबूझकर वही बता रहे हैं जो आज docs में है। इस endpoint पर चालान, हाइपोथिकेशन या बीमा कंपनी की पुष्टि जैसे field नहीं हैं, और हम नतीजे की मंज़ूरी या "गारंटी" भी नहीं देते। RC का जवाब आपके फ़ैसले का एक इनपुट है।

शुरुआत का सबसे सीधा रास्ता: signup करके sandbox key लीजिए, quickstart में पहली कॉल चलाइए, फिर Vehicle RC उत्पाद पेज और verification docs देखिए। कोई सवाल हो तो सपोर्ट पेज या [email protected] पर लिखिए, और बिक्री-संबंधी बातचीत के लिए contact है। भुगतान और शर्तों के लिए कानूनी पेज देखिए।

आगे की योजना में हमारा इरादा है कि डेवलपर अनुभव को और बेहतर करें, जैसे ज़्यादा उदाहरण, और स्थानीय भाषा में सामग्री। ये योजनाएँ हैं, आज उपलब्ध सुविधाएँ नहीं, और इनकी समय-सीमा तय नहीं है। जो आज उपलब्ध है, उसी पर अपना इंटीग्रेशन बनाइए।

API reference एक नज़र में

{
  "referenceId": "SMV-20260927-3D71Q9",
  "regNo": "MH12AB1234",
  "registrationStatus": "VALID",
  "ownerName": "RAHUL KUMAR",
  "ownerFatherName": "SURESH KUMAR",
  "vehicleClass": "LMV",
  "vehicleManufacturerName": "MARUTI SUZUKI",
  "model": "SWIFT",
  "vehicleColor": "WHITE",
  "chassis": "MA3ERLF1S00123456",
  "engine": "K12MN1234567",
  "registrationDate": "2019-05-14",
  "rcStatus": "ACTIVE",
  "rcExpiryDate": "2034-05-13",
  "insuranceUpto": "2025-05-13",
  "isCommercial": false
}

अक्सर पूछे जाने वाले सवाल