Driving License PDF AI Agent / LLM

# Driving License PDF API — Way2API®

- **Endpoint:** `POST https://app.way2api.com/api/v1/driving-license/pdf`
- **Auth:** `Authorization: Bearer YOUR_API_KEY` (or `X-API-Key: YOUR_API_KEY`)
- **Content-Type:** `application/json`
- **Category:** General
- **Availability:** Available in India
- **Docs:** https://app.way2api.com/documentation/driving-license-pdf

## What it does

Driving License PDF API — Turn an Indian driving licence number and date of birth into a printable driving licence document. Send the licence number and receive a pdf_url pointing at a ready-to-print government smart-card / A4 PDF of the licence, laid out as the physical card and carrying the holder photograph, name, parent or spouse name, date of birth, blood group, address, issue and expiry dates, the authorisation to drive with each vehicle class and its date of issue, the issuing authority, the state licence face and a scannable QR record. The response is the document link only — this endpoint sells the licence document, not the fields. If you need the licence data as JSON to read programmatically, use the Driving License Verification endpoint; if you need both in one call, use Driving License Text and PDF. pdf_url is an empty string in the rare case where a document could not be produced, so check it before following the link. Generated documents stay downloadable for a limited time — fetch and store the file promptly rather than holding the link. Built for driver onboarding, KYC and branch verification, insurance and claims files, and any workflow that needs a printable licence.

## Request body (application/json)

| Parameter | Type | Required | Description |
| --- | --- | --- | --- |
| `dl_number` | string | yes | Driving license number (10-20 characters, e.g. MH0320140001234). Case-insensitive, no spaces or hyphens. |
| `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/pdf \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"dl_number":"MH0320140001234","dob":"15/06/1992"}'
```

## 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": {
            "pdf_url": "https://docs.example-renderer.com/upload/dl2_1786426531_70e7ff519ee00a12.pdf"
        }
    }
}
```

## 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": "no_record",
        "result": {
            "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.