ping, push, release, and pull_request. Every other event type is acknowledged with 200 and "ignored": true so GitHub does not retry it, and nothing else happens.
These are events Notra receives from GitHub. Notra does not emit its own webhook events; see No outbound webhooks for polling and streaming alternatives.
Processing order
1
Route check
The organization, integration, and repository IDs in the payload URL must exist, belong together, and the integration must be enabled.
2
Event type
X-GitHub-Event must be one of the four supported types, otherwise the delivery is logged and ignored.3
Duplicate check
Deliveries with an
X-GitHub-Delivery ID seen in the last 24 hours are skipped.4
Signature
The body is verified against the repository’s secret using
X-Hub-Signature-256.5
Filter
Each event type has its own rules (below). Events that do not pass are logged as filtered and return
200.6
Dispatch
Push and release events are saved as context for chat and matched against your event triggers. Merged pull requests are recorded as signals for Iris.
Push
Sent when commits are pushed to the repository.string
required
pushstring
required
pushedFiltering
A push is processed only when both conditions hold:ref is the repository’s default branch (refs/heads/{default_branch})The payload contains at least one commit
Processed payload
This is the shape Notra passes to event triggers and returns underprocessed in the webhook response.
Release
Sent when a release changes state.string
required
releasestring
required
published or prereleasedFiltering
GitHub’s
action is published or prereleasedThe release is not a draft
created, edited, deleted, released, and unpublished actions are filtered. Draft releases never pass, so publishing a draft is processed once, when GitHub sends published.
Processed payload
Pull request
Sent when a pull request is opened, closed, or updated. Notra only keeps merges.string
required
pull_requeststring
required
mergedFiltering
GitHub’s
action is closedpull_request.merged is trueProcessed payload
Merged pull requests feed Iris signals only. They are not stored as chat context and do not fire event triggers; event triggers can only subscribe to
push and release.Ping
Sent by GitHub when you save the webhook or click Redeliver on the ping in your webhook settings.string
required
pingEvent triggers
Push and release events are matched against enabled event triggers whose targets include the repository. The trigger’ssourceConfig decides which events fire it:
eventTypesacceptspushandrelease. Triggers created through the API must list at least one.includePreReleasesdefaults totrue. Whenfalse,prereleasedevents are skipped for that trigger.- Each matching trigger starts one generation run per delivery. The run is keyed by trigger ID and delivery ID, so a redelivered event does not start a second run.
Log entries
Each delivery writes one entry to Settings, then Logs. TheintegrationType is github, direction is incoming, and referenceId is the X-GitHub-Delivery ID.
string
required
What happened, for example
Processed release event, Filtered push event, Unsupported event type: issues, Invalid webhook signature, or Webhook ping receivedstring
required
success for processed, filtered, ignored, and ping deliveries; failed for rejected onesnumber
The HTTP status Notra returned to GitHub
string
Set on failed entries, for example
Missing X-Hub-Signature-256 headerobject
For processed events:
event, action, and the processed data. For filtered events: event, action, and filtered: true. For unsupported event types: event and ignored: true.Next steps
Webhooks overview
Payload URL, secret, security checks, and polling alternatives
Configure triggers
Generate content automatically from push and release events