Can not get req.body from webhook v2

Hi, I am using webhood v2. and configured my webhook ( in the service>extension.

I am using below to handle the post data:’/pagerduty’, function (req, res) {

console.log('req.params = '+ JSON.stringify(req.params));
console.log('req.body = ' + JSON.stringify(req.body));
console.log('req.body.messages = ' + JSON.stringify(req.body.messages));
console.log('req.params.messages = ' + JSON.stringify(req.params.messages));


But always got below errors:

req.params = {}
req.body = undefined
TypeError: Cannot read property ‘messages’ of undefined
at /Users/acostry/Workspace/Git/avm-bot/app.js:38:66
at Layer.handle [as handle_request] (/Users/acostry/Workspace/Git/avm-bot/node_modules/express/lib/router/layer.js:95:5)
at next (/Users/acostry/Workspace/Git/avm-bot/node_modules/express/lib/router/route.js:137:13)
at Route.dispatch (/Users/acostry/Workspace/Git/avm-bot/node_modules/express/lib/router/route.js:112:3)
at Layer.handle [as handle_request] (/Users/acostry/Workspace/Git/avm-bot/node_modules/express/lib/router/layer.js:95:5)
at /Users/acostry/Workspace/Git/avm-bot/node_modules/express/lib/router/index.js:281:22
at Function.process_params (/Users/acostry/Workspace/Git/avm-bot/node_modules/express/lib/router/index.js:335:12)
at next (/Users/acostry/Workspace/Git/avm-bot/node_modules/express/lib/router/index.js:275:10)
at Layer.handle [as handle_request] (/Users/acostry/Workspace/Git/avm-bot/node_modules/express/lib/router/layer.js:91:12)
at trim_prefix (/Users/acostry/Workspace/Git/avm-bot/node_modules/express/lib/router/index.js:317:13)

May I get your kind help to know why? I tried online webhook tool, and worked fine, but not with my above code.

Hello, and welcome!

Under what conditions do you receive the error?

Seeing req.params = {} and req.body = undefined seems like it would only show up for a plain old GET request to the URL w/no query (which would result in empty parameters), i.e. opening the webhook URL in a web browser.

What one could try doing to simulate a PagerDuty webhook would be sending a POST request manually, i.e. with curl or Postman, and body {"messages":["test"]} / Content-Type: application/json / etc.

Hopefully that helps!

Thanks Demitri.
I figured out the issue today with your suggestion and I fixed the issue after I use bodyParser with
I did have another question about below statement:
“PagerDuty expects a 2xx response within 5 seconds for Generic Webhooks and within 16 seconds for webhooks generated from Custom Incident Actions.”
Currently, in my post function, in the first line, I am using res.sendStatus(200); to return a 200 code. Is that enough to avoid my webhook is disabled automatically?

Thanks. Pls see my last post. Really appreciate your help.

The ideal is to avoid any processes that take up time in the synchronous part of the code (before the HTTP response is fully delivered back). This especially applies to call-outs and data transfers with other systems i.e. reads/writes to disk or network things like reaching other HTTP APIs in your network/app cloud. They tie up the process so that it can’t respond until all that finishes. As your webhook ingestion service grows, you will probably have to contend with an increasing amount of these call-outs.

To address this: if possible (I think it may be with Node) it’s most appropriate to send a 202 response header and an empty body immediately once the webhook payload has been persisted, and then continue taking other actions on the payload asynchronously. As long as you can quickly save the payload and have observability into the receipt and processing (i.e. logging), it isn’t even useful to put more info like error messages into the response if things go wrong, and so there’s no need to wait until more information about the status of the webhook’s processing becomes available. The only exception to this is if you actually want PagerDuty to reattempt delivering the webhook.

Apart from that, therefore, there’s nothing really standing in the way of the webhook end sending an empty body response and status 202 (Accepted) and closing the connection very soon, unless there’s no easy way to quickly persist the webhook payload after the HTTP request is concluded (i.e. high disk/network latency), in which case you might want to have PagerDuty retry delivery of the webhook.

It’s worth noting that our webhooks delivery service doesn’t even require any special type of response from the receiving end; it just requires a success status. It does log the response if the receiving end gives an error response, so that our support team can provide this information upon request, but other than that there’s no need to hold up sending the response while other things are being done with the payload.

Thanks for the explanation.
I got your points and it’s very usefully. Currently my webhook is working as expected.

That’s great! Let us know if you run into any other difficulty or have more questions.

Happy hacking!