IssueComment events don't indicate whether they are for issues or pull requests


There’s no (easy) way to tell that a comment came in for an issue or a pull request. It’s possible to destructure the URLs in the webhook to differentiate it, but if it is a PR, I usually need to follow up with an API call to get information about the PR (commit, etc.). It’d be nice to just have the PR info in the webhook if it is available.


@mathstuf I do this in my app where I ignore webhooks for issue comments that are for issues versus pull requests.

In the webhook payload, if the issue is a pull request there is a pull_request property within the issue object. This is similar to how the API v3 issues endpoints work:

Note : GitHub’s REST API v3 considers every pull request an issue, but not every issue is a pull request. For this reason, “Issues” endpoints may return both issues and pull requests in the response. You can identify pull requests by the pull_request key.

Be aware that the id of a pull request returned from “Issues” endpoints will be an issue id . To find out the pull request id, use the “List pull requests” endpoint.

It is the same for event payloads but it looks like it is missing from the documentation for IssueComment events. @jamesmartin @kytrinyx @vroldanbet (sorry, not sure who or how best to ping from here) would you like to log an issue on your end to add this to the documentation?


Ah, OK. I just got done coding up “receive a webhook and parse it out” and plan on testing actually getting webhooks here this week. The documentation for webhooks is generally…half-hearted in that they’re “hey, here’s an example” but not “here’s what you can actually get”. Having a GraphQL-like schema for them would help a lot especially for “well the docs say it’s a string, but can it be null?” kinds of things.


@mathstuf, sorry you’re having trouble with the documentation. I’ll open an issue to track updating the IssueComment events documentation to information about Pull Requests, similar to the List issues documentation.

Agreed! We’re currently working on improving the REST API documentation to address these kinds of problems but unfortunately I don’t have a date for when those changes will be live.


Sounds awesome, thanks.

Having done the testing, it does seem that the issue.pull_request field is just some URLs, so it doesn’t allow me to avoid another API call unfortunately since I need more details than provided :frowning: . But it is easier than destructuring a URL :slight_smile: .