CIBIL Credit Report PDF AI Agent / LLM

# CIBIL Credit Report PDF API — Way2API®

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

## What it does

CIBIL Credit Report PDF API — The same TransUnion CIBIL enquiry as the CIBIL Credit Report API, returning the CIBIL score and a download URL for the official credit report as a PDF. The URL is served by Way2API, is tied to the order_id of the enquiry that produced it and carries its own signature, so it opens straight in a browser, an e-mail or your own app and needs no API key. Add ?download=1 to force a file download instead of opening it inline. Treat the link itself as the credential: anyone holding it can read the report, so share it only with the person it belongs to. The download is free — the enquiry is what is charged — and the link stays valid for 7 days after the enquiry, after which the stored copy is deleted. Requires the individual's explicit consent. Ideal for loan files, credit committee packs, customer copies and audit retention. Use the CIBIL Credit Report API instead when you need to read the report programmatically.

## Request body (application/json)

| Parameter | Type | Required | Description |
| --- | --- | --- | --- |
| `name` | string | yes | Full name of the individual as it appears on their PAN. 2 to 100 characters. |
| `mobile` | string | yes | 10-digit Indian mobile number of the individual, starting 6-9. Ideally the number registered with their lenders. |
| `pan` | string | yes | 10-character PAN of the individual, e.g. ABCDE1234F. Case-insensitive. |
| `gender` | string | yes | Gender of the individual: "male", "female" or "transgender". Case-insensitive; "M", "F" and "T" are also accepted. |
| `consent` | string | yes | Must be "Y". A credit bureau enquiry is only lawful with the individual's explicit consent, and you must have obtained and retained it. |

## Example request

```bash
curl -X POST https://app.way2api.com/api/v1/credit-report-cibil/fetch-report-pdf \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name":"Ananya Sharma","mobile":"9876543210","pan":"ABCDE1234F","gender":"female","consent":"Y"}'
```

## 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": {
            "name": "ANANYA SHARMA",
            "mobile": "9876543210",
            "pan": "ABCDE1234F",
            "credit_score": 762,
            "report_url": "https://way2api.com/api/v1/credit-report-cibil/report/W2A1739512345abcdef01/3f1c9a7d54e0b28c6a4d19f7be03c5d281af6e94"
        }
    }
}
```

## Error response — 422

```json
{
    "status": "SUCCESS",
    "status_code": 422,
    "charged": true,
    "success": false,
    "message": "No credit records were found for the details provided.",
    "message_code": "NO_RECORD_FOUND",
    "order_id": "W2A1739512345abcdef01",
    "data": {
        "order_id": "W2A1739512345abcdef01",
        "error_code": "no_record"
    }
}
```

## 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.