| Internet-Draft | Event and Webhook Delivery Semantics | December 2025 |
| Panke | Expires 28 June 2026 | [Page] |
Event- and webhook-based integrations are a common application-layer mechanism for interoperability across Internet services, yet they lack a shared delivery semantics contract. Existing implementations vary widely in retry behavior, acknowledgment signaling, failure classification, idempotency identifiers, and replay handling, resulting in fragile integrations and ambiguous operational expectations.¶
This document defines a minimal, application-layer delivery semantics profile for event and webhook delivery over existing transports, most commonly HTTP.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 4 June 2026.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Event- and webhook-based delivery is widely used to notify external systems of state changes or occurrences across administrative boundaries. These integrations are typically implemented over HTTP and are expected to operate in the presence of partial failure, independent failure domains, and variable network conditions.¶
Despite their ubiquity, there is no common, interoperable delivery semantics model that defines how delivery attempts, retries, acknowledgments, or failures are signaled and interpreted. This document addresses that gap by defining a minimal, application-layer semantics profile focused on sender-observable behavior.¶
Event- and webhook-based delivery is a widely deployed application-layer integration pattern used to notify external systems of state changes or occurrences. Such delivery is commonly implemented over existing transports, most frequently HTTP, and is typically expected to operate in the presence of partial failure, network interruption, and independent administrative control of endpoints.¶
Despite widespread deployment, there is no common, interoperable delivery semantics contract governing how event producers, consumers, and intermediaries signal delivery attempts, retries, acknowledgment, or failure. As a result, independently developed implementations rely on implicit assumptions, vendor-specific conventions, or informal documentation, leading to fragile integrations and inconsistent operational behavior.¶
The absence of a shared delivery semantics model results in recurring issues including ambiguous retry behavior and retry exhaustion signaling, inconsistent acknowledgment semantics, non-standard idempotency and deduplication signaling, unclear classification of delivery failures, and increased exposure to replay and abuse attacks.¶
These issues arise from missing application-layer semantics rather than deficiencies in underlying transport protocols.¶
Transport protocols such as HTTP provide generic delivery and error signaling mechanisms but intentionally do not define application-specific semantics such as retry interpretation, acknowledgment meaning, or deduplication scope. Correct use of transport semantics alone is therefore insufficient to ensure interoperable event delivery behavior.¶
This document does not attempt to define or guarantee end-to-end delivery or processing correctness; provide exactly-once, at-most-once, or effectively-once guarantees; impose receiver-side storage or execution requirements; redefine or replace existing transport protocols; or standardize event payload formats or business semantics. All guarantees are limited to sender-observable behavior and signaling.¶
The goals of this specification are to define a common vocabulary for event delivery semantics, standardize observable signaling for delivery attempts and retries, enable interoperable idempotency and deduplication signaling, improve security posture through consistent guidance, and reduce ambiguity without constraining implementation choices.¶
The key words "MUST", "MUST NOT", "SHOULD", and "MAY" are to be interpreted as described in RFC 2119.¶
This specification considers three primary roles: Event Producer, Event Consumer, and an optional Intermediary. The delivery semantics defined in this document apply to interactions between these roles at the application layer.¶
This specification defines a sender-observable delivery semantics model for event and webhook delivery. The model applies to each delivery attempt independently and does not infer receiver-side processing behavior beyond what is explicitly signaled.¶
A Delivery Attempt represents a single, discrete effort by an Event Producer or Intermediary to deliver an event to a Consumer endpoint. Each Delivery Attempt MUST be treated as best-effort, MUST NOT imply receipt, durability, or processing, and MAY be retried according to sender policy when sender-observed outcomes indicate a non-terminal condition.¶
This specification defines sender-observed outcomes for a Delivery Attempt, including Accepted, Transient Failure, and Terminal Failure. Senders MUST base retry behavior solely on these outcomes and MUST NOT infer receiver-side state beyond what is explicitly signaled.¶
Retry behavior is sender-driven and policy-dependent. This specification standardizes only retry signaling, not retry guarantees. Consumers MAY provide retry guidance, and senders MAY honor such guidance.¶
Idempotency and deduplication are addressed through explicit signaling mechanisms only. This specification does not require or assume receiver-side deduplication behavior.¶
An Idempotency Identifier is a producer-supplied identifier intended to correlate multiple Delivery Attempts representing the same logical event. When present, the identifier MUST remain stable across retries and MUST be scoped to the producer-consumer context.¶
Consumers MAY choose to perform deduplication based on the Idempotency Identifier and local policy. Senders MUST tolerate duplicate delivery in all cases. Deduplication remains an optimization, not a correctness requirement.¶
Failure classification in this specification is minimal and sender-centric. Failures are classified as transport-level failures or application-level rejections and are used solely to inform sender behavior such as retry decisions, alternate delivery paths, or operator intervention.¶
Event delivery mechanisms are susceptible to spoofing, replay, and abuse. This document profiles existing security mechanisms and provides guidance on authentication, authorization, integrity protection, and replay mitigation. No new cryptographic mechanisms are defined.¶
This document makes no request of IANA.¶