Driving License Verify AI Agent / LLM
Identity and SecurityEverything an AI coding assistant needs to write a working Driving License Verify integration without opening another page: endpoint, authentication, parameters, a real request, both response shapes and the platform rules it cannot infer from a single example. Copy the brief below and paste it into Claude, Cursor, GitHub Copilot, ChatGPT or any other agent.
Machine-readable spec — Markdown
# Driving License Verify API — Way2API®
- **Endpoint:** `POST https://app.way2api.com/api/v1/driving-license/verify`
- **Auth:** `Authorization: Bearer YOUR_API_KEY` (or `X-API-Key: YOUR_API_KEY`)
- **Content-Type:** `application/json`
- **Category:** Identity and Security
- **Availability:** Available in India
- **Docs:** https://app.way2api.com/documentation/driving-license
## What it does
Driving License Verification API — Verify any Indian driving license number with date of birth against government RTO records in real time. Returns the license holder's name, address, gender, father/husband name, date of birth, issue and expiry dates, vehicle classes, issuing authority, and profile image availability. Useful for KYC onboarding, identity verification, ride-hailing driver validation, and fleet compliance. The profile image is excluded from the response for privacy.
## Request body (application/json)
| Parameter | Type | Required | Description |
| --- | --- | --- | --- |
| `dl_number` | string | yes | Driving license number (10-20 characters, e.g. MH0320140001234). |
| `dob` | string | yes | Date of birth of the license holder in dd/mm/yyyy format. |
## Example request
```bash
curl -X POST https://app.way2api.com/api/v1/driving-license/verify \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{"dob":"15/06/1992","dl_number":"MH0320140001234"}'
```
## Success response — 200
```json
{
"status": "SUCCESS",
"status_code": 200,
"charged": true,
"success": true,
"message": "",
"message_code": "OK",
"order_id": "W2A1739512345abcdef01",
"data": {
"order_id": "W2A1739512345abcdef01",
"result": {
"license_number": "MH0320140001234",
"state": "Maharashtra",
"name": "PRIYA PATEL",
"permanent_address": "42 MG ROAD, PUNE, MAHARASHTRA",
"permanent_zip": "411001",
"temporary_address": "42 MG ROAD, PUNE, MAHARASHTRA",
"temporary_zip": "411001",
"citizenship": "",
"ola_name": "RTO PUNE",
"ola_code": "MH032",
"gender": "F",
"father_or_husband_name": "MAHESH PATEL",
"dob": "1992-06-15",
"doe": "2034-08-10",
"transport_doe": "1800-01-01",
"doi": "2014-08-11",
"transport_doi": "1800-01-01",
"has_image": true,
"blood_group": "B+",
"vehicle_classes": [
"MCWG",
"LMV-NT"
],
"less_info": false
}
}
}
```
## Error response — 422
```json
{
"status": "SUCCESS",
"status_code": 422,
"charged": true,
"success": false,
"message": "Verification Failed.",
"message_code": "VERIFICATION_FAILED",
"order_id": "W2A1739512345abcdef01",
"data": {
"order_id": "W2A1739512345abcdef01",
"error_code": "verification_failed",
"result": {
"license_number": "MH0320140001234",
"state": null,
"name": null,
"permanent_address": null,
"gender": null,
"father_or_husband_name": null,
"dob": "1992-06-15",
"doe": null,
"doi": null,
"has_image": false,
"vehicle_classes": [],
"less_info": false
}
}
}
```
## Integration rules
- Every response is JSON carrying `status`, `status_code`, `charged`, `success`, `message`, `message_code` and (once a call reaches the provider) `order_id`. The verification payload is under `data.result`.
- `charged` (boolean) is the authority on billing. Do NOT infer it from the HTTP status: `422` is returned both for input we rejected (not charged) and for a lookup the provider ran and billed us for that returned a negative result (charged).
- `message_code` is a fixed vocabulary — branch on it instead of parsing `message`. Values: `OK`, `ACCEPTED`, `PROVIDER_NO_RESPONSE`, `VERIFICATION_FAILED`, `NO_RECORD_FOUND`, `INVALID_INPUT`, `REQUEST_FAILED`, `MISSING_API_KEY`, `INVALID_API_KEY`, `INSUFFICIENT_BALANCE`, `NO_API_ACCESS`, `NOT_FOUND`, `RATE_LIMITED`, `INTERNAL_ERROR`, `PROVIDER_UNAVAILABLE`.
- `success` reports the verification outcome; `status` reports the ORDER lifecycle (`SUCCESS`/`PENDING`/`FAILED`). They differ on a charged negative result: the order completed and was billed while the verification did not pass.
- A failed verification is still a successful HTTP call — the outcome lives in the response body, so do not treat `200` as "verified".
- Status codes: `200` result returned, `202` pending or provider did not respond (both charged — quote the `order_id`), `401` missing/invalid key, `402` insufficient balance, `403` no access to this service, `422` see `charged`, `429` rate limited (honour the `Retry-After` header), `503` temporarily unavailable.
- Rate limits are per API key, per service, on a 1-minute sliding window.
- Load the API key from an environment variable or secret store. Never hard-code it, never commit it, and never ship it in client-side code — calls must be made from your backend.
Prompts to pair it with
- Write a production-ready Driving License Verify integration in PHP using this spec, with error handling and retries.
- Given this spec, generate typed request/response models and a client class.
- Review my existing Driving License Verify integration against this spec and list what I handle incorrectly.
⚠ Before you paste generated code
Never let an assistant hard-code your API key — load it from an environment variable or a
secret store, and call this endpoint from your backend only. A failed verification is still a
successful HTTP call, so check the success field in the body
rather than treating 200 as verified.