Cancel Alert – Shoonya API Documentation

API Endpoint

Method	`POST`
URL	`https://api.shoonya.com/NorenWClientAPI/CancelAlert`
Content-Type	`application/x-www-form-urlencoded`
Payload	`jData=<JSON payload>&jKey=<AccessToken>`

Parameters

Field	Type	Required	Description
uid	string	Required	User ID of the logged-in user.
al_id	string	Required	Alert ID returned by Set Alert.

Field name in source docsVendor documentation lists this field as ai_t under Cancel Alert, but that conflicts with ai_t meaning "alert type" everywhere else. This is almost certainly a documentation typo for al_id — verify against a live call before shipping.

Request Examples

import requests, json
 
payload = {"uid": "AB1234", "al_id": "210408000000004"}
data = f"jData={json.dumps(payload)}&jKey={accessToken}"
 
response = requests.post(
    "https://api.shoonya.com/NorenWClientAPI/CancelAlert",
    data=data,
)
print(response.json())

const payload = { uid: "AB1234", al_id: "210408000000004" };
const data = `jData=${JSON.stringify(payload)}&jKey=${accessToken}`;
 
const res = await fetch("https://api.shoonya.com/NorenWClientAPI/CancelAlert", {
  method: "POST",
  headers: { "Content-Type": "application/x-www-form-urlencoded" },
  body: data,
});
console.log(await res.json());

curl -X POST https://api.shoonya.com/NorenWClientAPI/CancelAlert \
  -H "Content-Type: application/x-www-form-urlencoded" \
  --data-urlencode 'jData={"uid":"AB1234","al_id":"210408000000004"}' \
  --data-urlencode "jKey=$ACCESS_TOKEN"

Response

json

// Success
{
  "request_time": "15:03:33 08-04-2021",
  "stat": "O! delete success",
  "al_id": "210408000000008"
}
 
// Failure
{
  "stat": "Not_Ok",
  "emsg": "Session Expired : Invalid Session Key"
}

Field	Description
stat	Success/failure indication (a status string on success, not a plain `Ok` flag).
al_id	The cancelled Alert ID, echoed back on success.
emsg	Present only on failure.

Best Practices

Verify the al_id/ai_t field-name discrepancy above against a live sandbox call before shipping — send whichever field name actually works and note it in your own code comments, since the vendor docs disagree with themselves on this endpoint.
Confirm an alert is still pending (via a list/pending endpoint) before cancelling if it's been a while since you set it — cancelling an alert that already fired will fail.