DTH Advance Information AI Agent / LLM
TelecomEverything an AI coding assistant needs to write a working DTH Advance Information 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
# DTH Advance Information API — Way2API®
- **Endpoint:** `POST https://app.way2api.com/api/v1/dth/info`
- **Auth:** `Authorization: Bearer YOUR_API_KEY` (or `X-API-Key: YOUR_API_KEY`)
- **Content-Type:** `application/json`
- **Category:** Telecom
- **Availability:** Available in India
- **Docs:** https://app.way2api.com/documentation/dth-info
## What it does
DTH Advance Information API — Pull the full subscriber profile behind a DTH customer ID / VC number. Returns the account name, registered_mobile, current balance, monthly_amount, account status, plan, next_recharge_date, last_recharge_date, last_recharge_amount, switch_off_date and the installation address (with city, district, state and pin_code). Built for DTH recharge platforms and retailer apps that need to confirm the right account and its dues before taking a payment. Fields the operator does not publish for a given account are returned as empty strings (or "N/A" where the operator sends that).
## Request body (application/json)
| Parameter | Type | Required | Description |
| --- | --- | --- | --- |
| `dth_number` | string | yes | DTH subscriber / customer ID — 9 to 13 digits (e.g. 01234567890). The exact prefix and length are set by the operator and differ between them, so the operator rejects a well-formed ID that does not match its own scheme. |
| `operator` | string | yes | DTH operator of the connection. Accepted values: airtel_dth, dish_tv, reliance_bigtv, sun_direct, tata_play (alias tata_sky), videocon_d2h (alias d2h). Use the DTH Operator Check API if the operator is unknown. |
## Example request
```bash
curl -X POST https://app.way2api.com/api/v1/dth/info \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{"dth_number":"01234567890","operator":"dish_tv"}'
```
## 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": {
"dth_number": "01234567890",
"operator": "dish_tv",
"customer_id": "9700000123",
"name": "Lakshmi Priya",
"registered_mobile": "98XXXXXX10",
"balance": "194.73",
"monthly_amount": "",
"status": "1",
"plan": "",
"next_recharge_date": "8/4/2026 12:00:00 AM",
"last_recharge_date": "N/A",
"last_recharge_amount": "N/A",
"switch_off_date": "8/7/2026 12:00:00 AM",
"address": "12 MAIN ROAD, VILLIANUR, PONDICHERRY, Pin - 605110",
"city": "PONDICHERRY",
"district": "",
"state": "PONDICHERRY",
"pin_code": "605110"
}
}
}
```
## Error response — 400
```json
{
"status": "FAILED",
"status_code": 400,
"charged": false,
"success": false,
"message": "Customer Id Starts with 0 and is 11 digits long",
"message_code": "REQUEST_FAILED",
"order_id": "W2A1739512345abcdef01",
"data": {
"order_id": "W2A1739512345abcdef01",
"error_code": "1"
}
}
```
## 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 DTH Advance Information 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 DTH Advance Information 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.