Events API: new pull_request payloads are trimmed to the point of being inconsistent and almost useless

[Fs00]

Select Topic Area

Product Feedback

Body

Following the recent breaking changes to the Events REST API, all pull request-related events (PullRequestEvent, PullRequestReviewEvent, PullRequestReviewCommentEvent) have had the pull_request object in their respective payloads trimmed of almost all fields: it now includes only id, url, number, head and base. This overly aggressive trimming is very problematic because it removes fields that are used by third-party clients - one such example is the OctoDroid app - to display those events in a meaningful way without resorting to additional slower API calls. In the case of the OctoDroid app, it was mainly relying on the presence of title and merged fields on pull_request objects (among others), which would be the very bare minimum that should be re-added to the payload.

It's honestly hard to believe that all the removed pull request fields are (quoting the announcement post) "slow to generate and require costly database calls", because the issue object in IssueEvent/IssueCommentEvent payloads has barely been affected by the breaking changes and includes almost all the same fields as before. This makes the payloads unexplainably inconsistent between different event types and, on top of all that, the documentation page for the event types does not even detail which issue/pull_request fields are actually present in the payload.

I also want to add that this API change has been carried out in a way that I would define as unprofessional, with very little consideration of the users of your API:

• no specific details have been shared about which exact fields have been removed until the roll-out began (and even now the documentation is lacking)
• in the announcement post, you wrote "we'll be rolling these changes out behind a feature flag", but the flag has never been shared with the community so that clients could test the changes early
• unlike with new features, there has been no dedicated feedback thread for the breaking changes here on the community forum, as if you didn't really care about user feedback on this topic

The list could go on, but others have already voiced their concerns so I won't repeat them here.

[nemesifier]

+1

I am puzzled that the pull request title was removed. It's really such a performance penalty to join the pull request data to get the title? What's the point of returning the pull request without its title, are they expecting us to make an extra HTTP request for each pull request? That can't possibly scale better than what we had before, this is a mistake.

[uhourri]

I'm experiencing similar issues with the Events API changes in my project ghmap, a tool that maps GitHub events into contributor activities. The field trimming in pull request events is causing functional breakdowns in our mapping logic.

Specifically, the removal of the 'merged' field from PullRequestEvent payloads prevents us from accurately distinguishing between merged and closed pull requests. This fundamentally breaks our activity classification, as we can no longer determine whether a closed PR was merged or simply closed without merging.

Like others have mentioned, we're now forced to make additional API calls for basic information that was previously available in the event payload. This not only impacts performance but also increases our API rate limit usage significantly.

The inconsistency between issue events (which retained most fields) and pull request events (which were heavily trimmed) is particularly confusing. If certain fields are truly costly, why are they still available in issue events but removed from PR events?