Indian DTH/D2H Recharge Plans AI Agent / LLM
TelecomEverything an AI coding assistant needs to write a working Indian DTH/D2H Recharge Plans 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
# Indian DTH/D2H Recharge Plans API — Way2API®
- **Endpoint:** `POST https://app.way2api.com/api/v1/dth/recharge-plans`
- **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-recharge-plans
## What it does
Indian DTH/D2H Recharge Plans API — Get every DTH pack an Indian satellite TV operator sells: Tata Play, Airtel Digital TV, Dish TV, d2h and Sun Direct. Each pack comes back with its plan_name, the language it is filed under, its channels and hd_channels counts, and a prices list giving the amount for every duration the pack can be bought for, with the duration as readable validity text and as a number of months in validity_months. Prices and channel counts are numbers, not text to be parsed. A pack offered in several languages is listed once under each, exactly as the operator files it. Pass the operator returned by the DTH Operator Check API straight in to go from a subscriber ID to the packs that connection can buy.
## Request body (application/json)
| Parameter | Type | Required | Description |
| --- | --- | --- | --- |
| `operator` | string | yes | DTH operator. Accepted values: airtel_dth, dish_tv, sun_direct, tata_play (alias tata_sky), videocon_d2h (alias d2h) — the same values DTH Operator Check returns and DTH Advance Information accepts. Case, spaces and punctuation are ignored. |
## Example request
```bash
curl -X POST https://app.way2api.com/api/v1/dth/recharge-plans \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{"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": {
"operator": "dish_tv",
"plan_count": 2,
"plans": [
{
"plan_name": "Family Kannada HD",
"language": "kannada",
"channels": 48,
"hd_channels": 11,
"prices": [
{
"amount": 288,
"validity": "1 month",
"validity_months": 1
}
]
},
{
"plan_name": "Popular Telugu",
"language": "telugu",
"channels": 28,
"hd_channels": 0,
"prices": [
{
"amount": 125,
"validity": "1 month",
"validity_months": 1
},
{
"amount": 913,
"validity": "3 months",
"validity_months": 3
},
{
"amount": 1825,
"validity": "6 months",
"validity_months": 6
},
{
"amount": 3651,
"validity": "12 months",
"validity_months": 12
}
]
}
]
}
}
}
```
## Error response — 400
```json
{
"status": "FAILED",
"status_code": 400,
"charged": false,
"success": false,
"message": "DTH plans could not be fetched for this operator right now. Please try again shortly.",
"message_code": "REQUEST_FAILED",
"order_id": "W2A1739512345abcdef01",
"data": {
"order_id": "W2A1739512345abcdef01",
"error_code": "VENDOR_ERROR"
}
}
```
## 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 Indian DTH/D2H Recharge Plans 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 Indian DTH/D2H Recharge Plans 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.