إجابات الإشعارات

اطرح سؤالًا في إشعار واقرأ الإجابة عبر API. يسجّل PushWard الزر الذي نقر عليه المستخدم أو الرد الذي كتبه، فلا حاجة إلى webhook خاص بك.

Send an action without a url, and without foreground, and PushWard records the tap itself: which action the user chose, and when. Add text_input: true to the same kind of action and the user can type a reply, which is recorded with it. Your code then reads the answer from GET /notifications/answers/{id}.

curl -X POST https://api.pushward.app/notifications \
  -H "Authorization: Bearer hlk_YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "title": "Deploy to production?",
    "body": "Build 1.11.0 passed staging.",
    "source": "ci",
    "actions": [
      { "id": "deploy", "title": "Deploy", "icon": "checkmark.circle" },
      { "id": "hold", "title": "Hold", "icon": "pause.circle", "destructive": true },
      {
        "id": "note",
        "title": "Reply",
        "icon": "arrowshape.turn.up.left",
        "text_input": true,
        "text_input_placeholder": "Why hold?"
      }
    ]
  }'

The response is the notification, with answerable: true when the server will record the answer. Keep its id:

{
  "id": 1234,
  "title": "Deploy to production?",
  "body": "Build 1.11.0 passed staging.",
  "source": "ci",
  "actions": [
    { "id": "deploy", "title": "Deploy", "icon": "checkmark.circle" },
    ...
  ],
  "answerable": true,
  "pushed": true,
  "created_at": "2026-09-28T12:00:00Z",
  "delivery": "all"
}

The actions in the response are the ones you sent. The links PushWard adds to record the answer go only to your devices.

Read the answer

curl "https://api.pushward.app/notifications/answers/1234?wait=25" \
  -H "Authorization: Bearer hlk_YOUR_TOKEN"

{
  "notification_id": 1234,
  "status": "answered",
  "action_id": "note",
  "text": "Waiting for the database migration.",
  "answered_at": "2026-09-28T12:03:41Z"
}

Without wait the request returns right away. With ?wait=N (0-25 seconds) it is held open while the answer is pending and returns as soon as it lands; if the time runs out first it returns with status: "pending". Repeat the request to wait longer. Agents on the MCP server can call wait_for_answer with the notification_id, which does this for them.

From Home Assistant, pushward.get_notification_answer does the same inside an automation. It keeps waiting for as long as its timeout allows (up to 24 hours) and hands action_id and text to the next step. See Home Assistant for an example.

Rules

• Only actions with no url and no foreground are recorded. A url-less foreground action still just opens the app, and an action with a url keeps calling that URL and is never recorded. One notification can mix all three.
• The first answer wins. Once one device has answered, later taps on any device change nothing.
• Answers are kept for 30 days.
• An integration key can read only answers to notifications it sent. Reading an answer needs notifications at send or above, like sending the notification did.
• A notification with nothing to record (none of its actions was url-less and silent), an unknown id and an answer past its 30 days all return 404 with code notification_answer.not_found.
• Too many wait requests open at once for your account return 429 with code answer_wait.limit_exceeded. Retry shortly, or read without wait.
• The recording links count toward the 4 KB push payload. If a long notification leaves no room for them, plain url-less actions go out unrecorded and the response has no answerable; a url-less text_input action fails with 400 instead.
• Scheduled notifications are recorded the same way. Read the answer with the notification_id a sent schedule reports; each send of a repeating schedule is its own notification with its own answer.

For a question that should stay on the Lock Screen until someone answers it, use an approval Live Activity. Its url-less options are recorded the same way, and GET /activities/{slug}?wait=25 waits for the answer.