Schema Inaccuracy
The schema for these two webhook headers only specifies:
{
"name": "X-Github-Hook-Installation-Target-Id",
"in": "header",
"example": 123123,
"schema": {
"type": "string"
}
},
{
"name": "X-Github-Hook-Installation-Target-Type",
"in": "header",
"example": "repository",
"schema": {
"type": "string"
}
},
the webhooks documentation is not significantly more helpful:
X-GitHub-Hook-Installation-Target-Type: The type of resource where the webhook was created.
X-GitHub-Hook-Installation-Target-ID: The unique identifier of the resource where the webhook was created.
Issue
While some hooks can be distinguished by probing the payload for optional entries like installation or organization entries, not only is this pretty ugly some events don't have such entries because e.g. they're not attached to installations in the case of github apps hooks (ping, github_app_authorization.revoked).
Currently every developer who needs this information has to reverse-engineer the values and hope they didn't miss special cases.
Expected
- enumerate the valid values for
Target-Type (as far as I can tell there's repository for repository hooks and integration for app hooks, I have never tested org hooks so I've no idea what that uses
- specify what
Target-Id maps to for each type, as far as I can tell for repository it's the repository id and for integration it's the app id
- also the
Target-Id is currently typed as a string, but all of them are numbers (/ integers)
Previous reports
Schema Inaccuracy
The schema for these two webhook headers only specifies:
{ "name": "X-Github-Hook-Installation-Target-Id", "in": "header", "example": 123123, "schema": { "type": "string" } }, { "name": "X-Github-Hook-Installation-Target-Type", "in": "header", "example": "repository", "schema": { "type": "string" } },the webhooks documentation is not significantly more helpful:
Issue
While some hooks can be distinguished by probing the payload for optional entries like
installationororganizationentries, not only is this pretty ugly some events don't have such entries because e.g. they're not attached to installations in the case of github apps hooks (ping,github_app_authorization.revoked).Currently every developer who needs this information has to reverse-engineer the values and hope they didn't miss special cases.
Expected
Target-Type(as far as I can tell there'srepositoryfor repository hooks andintegrationfor app hooks, I have never tested org hooks so I've no idea what that usesTarget-Idmaps to for each type, as far as I can tell forrepositoryit's the repository id and forintegrationit's the app idTarget-Idis currently typed as astring, but all of them are numbers (/ integers)Previous reports