Respostas de Notificação

Faça uma pergunta em uma notificação e leia a resposta pela API. O PushWard registra qual botão o usuário tocou ou qual resposta digitou, então você não precisa de um webhook próprio.

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.