RC Details Advanced AI Agent / LLM
VerificationEverything an AI coding assistant needs to write a working RC Details Advanced 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 Advanced API — Way2API®
- **Endpoint:** `POST https://app.way2api.com/api/v1/rc/advanced`
- **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-advanced
## What it does
RC Details Advanced API — Enhanced RC data + Father Name + Mobile number + a ready-to-print RC PDF, etc, all in one call. The most complete Registration Certificate (RC) record for an Indian vehicle: each lookup queries two registry sources and merges them into one record. Every field the primary source returns is used as-is, and the second source fills the fields the primary left blank — typically emission norms and the vehicle class description, and the whole record when the primary has none. The merged record is then drawn as a smart-card / A4 PDF of the certificate and returned as pdf_url, so one call gives you both the data to read and a document to file or hand over. The fields have exactly the same names, order and format as the Vehicle RC Verification and RC Details Lite APIs, with pdf_url as the only addition and nothing duplicated: ISO YYYY-MM-DD dates and a fixed rc_status value set. Unlike RC Details Lite, mobile_number carries the owner's registered mobile number when the registry returns one, and an empty string when it does not; it is never printed on the PDF. pdf_url is an empty string in the rare case where a document could not be produced — the record itself is unaffected, so check it before following the link — and generated documents stay downloadable for a limited time, so fetch and store the file promptly. A chassis number supplied by the second source is partly masked, and response_metadata.masked_chassis is then true. Because two sources are queried and a document is drawn, a call takes a few seconds longer than RC Details Lite. Built for underwriting, lending, onboarding and RTO paperwork that need the fullest record and a printable certificate.
## 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/advanced \
-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": "9876543210",
"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": "BHARAT STAGE VI",
"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": "Motor Car(LMV)",
"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
},
"pdf_url": "https://docs.example-renderer.com/upload/rc2_1786426531_70e7ff519ee00a12.pdf"
}
}
}
```
## 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
},
"pdf_url": ""
}
}
}
```
## 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 Advanced 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 Advanced 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.