Credit Report Equifax AI Agent / LLM

Business
POST /api/v1/credit-report/fetch Bearer

Everything an AI coding assistant needs to write a working Credit Report Equifax 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

# Credit Report Equifax API — Way2API®

- **Endpoint:** `POST https://app.way2api.com/api/v1/credit-report/fetch`
- **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/credit-report-equifax

## What it does

Credit Report API — Fetch a detailed credit report (JSON) for an individual using their Aadhaar or PAN number. Returns the credit score and the full credit report data including inquiry details, account summaries, and credit history. Useful for lending decisions, KYC verification, and risk assessment. Consent is automatically set to "Y".

## Request body (application/json)

| Parameter | Type | Required | Description |
| --- | --- | --- | --- |
| `name` | string | yes | Full name of the individual. |
| `number` | string | yes | 12-digit Aadhaar number or 10-character PAN (based on fetch_by). |
| `fetch_by` | string | yes | Type of ID document: "aadhaar" or "pan". |
| `mobile` | string | yes | 10-digit mobile number of the individual. |

## Example request

```bash
curl -X POST https://app.way2api.com/api/v1/credit-report/fetch \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name":"Ananya Sharma","mobile":"9876543210","number":"123456789012","fetch_by":"aadhaar"}'
```

## 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": {
            "number": "123456789012",
            "fetch_by": "aadhaar",
            "mobile": "9876543210",
            "name": "Ananya Sharma",
            "credit_score": "750",
            "credit_report": {
                "InquiryResponseHeader": [],
                "CCRResponse": []
            },
            "credit_report_link": ""
        }
    }
}
```

## 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": {
            "number": "123456789012",
            "fetch_by": "aadhaar",
            "mobile": "9876543210",
            "name": "Ananya Sharma",
            "credit_score": "",
            "credit_report": [],
            "credit_report_link": ""
        }
    }
}
```

## 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 Credit Report Equifax 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 Credit Report Equifax 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.

Prefer to read it yourself?

Overview What this API does, availability, and a quick start. Request Endpoint, authentication headers, every request parameter with its type, and a sample request body. Response The full success response payload, field by field. Error Codes HTTP status codes, error payload shape, and how to handle failures. Code Examples Ready-to-run examples in cURL, PHP, JavaScript and Python. Rate Limits Per-minute and per-day request limits, and what happens on breach.