RC Details Lite AI Agent / LLM
VerificationEverything an AI coding assistant needs to write a working RC Details Lite 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
# RC Details Lite API — Way2API®
- **Endpoint:** `POST https://app.way2api.com/api/v1/rc/lite`
- **Auth:** `Authorization: Bearer YOUR_API_KEY` (or `X-API-Key: YOUR_API_KEY`)
- **Content-Type:** `application/json`
- **Category:** Verification
- **Availability:** Available in India
- **Docs:** https://app.way2api.com/documentation/vehicle-rc-lite
## What it does
RC Details Lite API — Fetch Registration Certificate (RC) details for any Indian vehicle from its registration number: owner name and address, chassis and engine numbers, make and model, fuel type, colour, registering RTO, fitness, road-tax, insurance and PUCC validity, financer and hypothecation, permit details and RC status. The response carries exactly the same fields, in the same order and format, as the Vehicle RC Verification API, so an existing integration can switch endpoints without a code change. Dates are ISO YYYY-MM-DD, rc_status comes from a fixed value set, and mobile_number is always an empty string — the owner's mobile number is never returned. A field the registry did not supply is an empty string, or null where Vehicle RC Verification returns null. Built for used-car listings, insurance quotes, fleet checks and loan files.
## Request body (application/json)
| Parameter | Type | Required | Description |
| --- | --- | --- | --- |
| `rc_number` | string | yes | Vehicle registration number, e.g. DL3CAB1234 or MH12AB1234. Case-insensitive, no spaces or hyphens. |
## Example request
```bash
curl -X POST https://app.way2api.com/api/v1/rc/lite \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{"rc_number":"DL3CAB1234"}'
```
## 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": {
"rc_number": "DL3CAB1234",
"fit_up_to": "2037-03-20",
"registration_date": "2022-03-21",
"owner_name": "Anjali Deshmukh",
"father_name": "Rakesh Deshmukh",
"present_address": "12 Sector 9, Dwarka, New Delhi, Delhi, 110075",
"permanent_address": "12 Sector 9, Dwarka, New Delhi, Delhi, 110075",
"mobile_number": "",
"vehicle_category": "LMV",
"vehicle_chasi_number": "MA1AB2CD3EF456789",
"vehicle_engine_number": "0000A123",
"maker_description": "BMW",
"maker_model": "BMW 220I GRAN COUPE M SPORT",
"body_type": "",
"fuel_type": "PETROL",
"color": "SNAPPER ROCKS BLUE M",
"norms_type": "",
"financer": "EXAMPLE BANK LTD",
"financed": true,
"insurance_company": "Example General Insurance Co. Ltd.",
"insurance_policy_number": "P1234567890",
"insurance_upto": "2027-07-17",
"manufacturing_date": "3/2022",
"manufacturing_date_formatted": "2022-03",
"registered_at": "SOUTH DELHI",
"latest_by": "",
"less_info": false,
"tax_upto": "2037-03-20",
"tax_paid_upto": "2037-03-20",
"cubic_capacity": "1998.00",
"vehicle_gross_weight": "1965",
"no_cylinders": "",
"seat_capacity": "5",
"sleeper_capacity": "",
"standing_capacity": "",
"wheelbase": "",
"unladen_weight": "1512",
"vehicle_category_description": "",
"pucc_number": "",
"pucc_upto": "2027-04-18",
"permit_number": "",
"permit_issue_date": null,
"permit_valid_from": null,
"permit_valid_upto": null,
"permit_type": "",
"national_permit_number": "",
"national_permit_upto": null,
"national_permit_issued_by": null,
"non_use_status": null,
"non_use_from": null,
"non_use_to": null,
"blacklist_status": "",
"noc_details": "",
"owner_number": "",
"rc_status": "ACTIVE",
"masked_name": false,
"challan_details": null,
"variant": null,
"rto_code": "",
"response_metadata": {
"masked_chassis": false,
"masked_engine": false,
"masked_owner_name": false
}
}
}
}
```
## Error response — 422
```json
{
"status": "SUCCESS",
"status_code": 422,
"charged": true,
"success": false,
"message": "No vehicle record was found for the registration number provided.",
"message_code": "VERIFICATION_FAILED",
"order_id": "W2A1739512345abcdef01",
"data": {
"order_id": "W2A1739512345abcdef01",
"error_code": "no_record",
"result": {
"rc_number": "KA12AC3456",
"fit_up_to": "",
"registration_date": "",
"owner_name": "",
"father_name": "",
"present_address": "",
"permanent_address": "",
"mobile_number": "",
"vehicle_category": "",
"vehicle_chasi_number": "",
"vehicle_engine_number": "",
"maker_description": "",
"maker_model": "",
"body_type": "",
"fuel_type": "",
"color": "",
"norms_type": "",
"financer": "",
"financed": false,
"insurance_company": "",
"insurance_policy_number": "",
"insurance_upto": "",
"manufacturing_date": "",
"manufacturing_date_formatted": "",
"registered_at": "",
"latest_by": "",
"less_info": false,
"tax_upto": "",
"tax_paid_upto": "",
"cubic_capacity": "",
"vehicle_gross_weight": "",
"no_cylinders": "",
"seat_capacity": "",
"sleeper_capacity": "",
"standing_capacity": "",
"wheelbase": "",
"unladen_weight": "",
"vehicle_category_description": "",
"pucc_number": "",
"pucc_upto": "",
"permit_number": "",
"permit_issue_date": null,
"permit_valid_from": null,
"permit_valid_upto": null,
"permit_type": "",
"national_permit_number": "",
"national_permit_upto": null,
"national_permit_issued_by": null,
"non_use_status": null,
"non_use_from": null,
"non_use_to": null,
"blacklist_status": "",
"noc_details": "",
"owner_number": "",
"rc_status": "",
"masked_name": false,
"challan_details": null,
"variant": null,
"rto_code": "",
"response_metadata": {
"masked_chassis": false,
"masked_engine": false,
"masked_owner_name": 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 RC Details Lite 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 RC Details Lite 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.