Skip Worknote Updates for Specific Service on incident.annotated Webhook
Hi team,
I'm integrating PagerDuty with ServiceNow using the V3 webhook for incident events. While handling the incident.annotated event, I noticed that the webhook payload does not include key fields like status, service_id, or escalation_policy.id.
My current requirement is to prevent worknote updates in ServiceNow when a PagerDuty incident note is added — but only for one specific service.
Could you please advise:
Is there a way to enrich the incident.annotated payload to include service_id or escalation_policy.id?
Alternatively, is there a recommended approach to identify the service from the webhook and conditionally skip worknote updates in ServiceNow?
Any guidance or best practices would be greatly appreciated.
Page 1 / 1
Hi @Mohan Mallapu,
You actually can identify the service directly from the incident.annotated webhook payload, no extra API call needed! The payload’s event.data object includes a service field, which contains the id of the service related to the incident.
To implement your filter, just check event.data.service.id in your webhook handler and compare it to your target service. If it matches, you can skip the worknote update in ServiceNow.
Thank you for the response. I tried with the same; however, I am unable to get the service ID.
Could you please share the sample payload for incident.annotated event type??
Hi @Mohan Mallapu,
Absolutely, a sample payload for the incident.annotated event type from PagerDuty Webhooks V3 looks like this. You’ll see that the service object (with its id) is included under event.data:
You can ignore my previous responses, I wrongly assumed the payload sent would be for the incident and not limited to incident_note:
This means that, unfortunately for now, you cannot filter by service using only the webhook payload for this event type. The best practice in this scenario is to use the incident.id from the payload and make a follow-up API call to the Get Incident endpoint to retrieve the full incident details, including the service.id.
This is currently a limitation, and I’ll put up a request for clarification with the API team, using your use case as reference.
Thank you so much for the quick response. I will go with a REST API call to get the details..