Human approval in your n8n flow — no Twilio, no WABA.

Your flow reaches the step that spends money, deletes records or emails a customer — and you want a human to say yes first. n8n's native WhatsApp node wants Meta or Twilio credentials, business verification and template approval before it sends anything. pingwa is one HTTP Request node and a join message: the flow POSTs /v1/ask, your phone buzzes with buttons, the flow waits for your tap.

Honest note: if you already run a WABA and message customers, the native node is the right choice — that's what it's for. pingwa is for the other case: the flow asking you, its operator, for a decision.

Manual Trigger → HTTP Request → IF. The HTTP Request node POSTs your question to /v1/ask and long-polls — the flow genuinely pauses there until you answer or 90 seconds pass. The IF node then branches on which button you tapped. Swap the Manual Trigger for whatever actually starts your flow.

The HTTP Request node's settings, spelled out — this is all the template contains:

timeout: 90 in the body is the maximum the API accepts; the node's own 95 s timeout just makes sure n8n outlasts the long-poll instead of cutting it off. Put anything you like in text — an n8n expression interpolating the item being approved works fine.

A successful response looks like this — button_id is positional: b0 is the first button you passed, b1 the second.

{
  "message_id": 123,
  "billing_class": "template",
  "answered": true,
  "reply": {"answer_id": 124, "text": "approve", "button_id": "b0",
            "created_at": "2026-07-16T14:03:07Z"}
}

So the IF node's condition is a plain string-equals: left value {{ $json.reply.button_id }}, right value b0. True branch = approved, false branch = rejected.

If the ask lands outside your 24h reply window (likely, for approvals that arrive out of the blue), the buttons arrive as a numbered list instead of tap buttons — replying 1 (or the button's text, approve) works the same and still maps to b0.

If nobody answers within the 90 seconds, /v1/ask returns HTTP 408 and the HTTP Request node errors. Treat that as a reject — silence should never approve anything. Wire the node's error output to the same path as the false branch (enable “Settings → On Error → Continue (using error output)”). The question was still delivered to your phone; a late tap is retrievable afterwards via GET /v1/messages/<id>/reply if your flow wants a second look.

Same shape: a function node prepares the request, an http request node (set to POST, “return a parsed JSON object”) makes the call, and a second function (or switch) node branches on the button.

// function node BEFORE the http request node
msg.url = "https://pingwa.dev/v1/ask";
msg.method = "POST";
msg.headers = {
  "Authorization": "Bearer " + env.get("PINGWA_KEY"),
  "Content-Type": "application/json"
};
msg.payload = {text: "Approve this step?", buttons: ["approve", "reject"], timeout: 90};
return msg;

// output 1 = approved, output 2 = rejected (set the node to 2 outputs)
if (msg.statusCode === 200 && msg.payload.reply.button_id === "b0") {
  return [msg, null];
}
return [null, msg];  // includes the 408 nobody-answered case → fail-safe reject

In Make, it's the generic HTTP module (“Make a request”): POST the same JSON to /v1/ask with the same Authorization: Bearer header, then add a Router with a filter on reply.button_id equals b0 for the approved route and a fallback route for everything else — rejections and timeouts alike.

Scan the code and get instant access. It opens WhatsApp with “join” ready to send, and your API key comes straight back.

Approvals are exactly the messages you want rare and deliberate — the free plan's 30 paid messages a month cover a lot of “Approve this step?”. Your button-tap replies inside the 24h window are free.