Independent

panke.mayank@gmail.com

Applications and Real-Time webhook event delivery idempotency retry HTTP 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, and specifies a concrete binding for the Hypertext Transfer Protocol (HTTP). The profile constrains only sender-observable behavior and signaling; it does not impose receiver-side storage or processing requirements and does not redefine existing transport protocols.

Introduction 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 between independently operated producers and consumers. In practice, every producer publishes its own retry policy, its own acknowledgment convention, its own idempotency header, and its own classification of failure; every consumer must adapt to those conventions per producer. The result is fragile integrations, repeated rediscovery of the same edge cases, and operational practices that do not transfer between vendors. This document addresses that gap by defining a minimal, application-layer semantics profile focused on sender-observable behavior, and by specifying a concrete binding of that profile to HTTP (see ). The profile is intentionally narrow: it does not attempt to define new transport primitives, new cryptographic mechanisms, or new payload formats. Its goal is to give independently developed producers and consumers a shared, interoperable vocabulary for the few signals that determine whether a delivery succeeded, may be retried, or must be abandoned.

Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The following terms are used throughout this document.

Event:

A self-contained, application-level record of an occurrence or state change generated by an Event Producer and intended for delivery to one or more Event Consumers. This document places no requirement on the payload format of an Event.

Event Producer:

An entity that generates Events and is responsible for initiating Delivery Attempts toward one or more Event Consumers, directly or via an Intermediary.

Event Consumer:

An entity that exposes an endpoint to receive Delivery Attempts for Events and that returns Sender-Observed Outcomes in response to those attempts.

Intermediary:

An entity positioned between an Event Producer and an Event Consumer that relays, transforms, fans out, or buffers Events. An Intermediary takes the Producer role with respect to its downstream Consumer and the Consumer role with respect to its upstream Producer.

Delivery Attempt:

A single, discrete effort by an Event Producer or Intermediary to deliver an Event to a Consumer endpoint. Each Delivery Attempt is independent of all others.

Acknowledgment:

A signal returned by an Event Consumer indicating receipt of a Delivery Attempt. An Acknowledgment does not imply processing success, persistence, or durability beyond the scope of receipt.

Sender-Observed Outcome:

The result of a Delivery Attempt as observable by the sender. Sender-Observed Outcomes are defined in and form the sole basis for retry decisions.

Accepted:

A Sender-Observed Outcome indicating that the Consumer acknowledged receipt of the Delivery Attempt.

Transient Failure:

A Sender-Observed Outcome indicating a condition that the sender may reasonably expect to resolve such that a future Delivery Attempt could be Accepted.

Terminal Failure:

A Sender-Observed Outcome indicating a condition that the sender cannot reasonably expect to resolve through further Delivery Attempts of the same Event to the same Consumer endpoint.

Idempotency Identifier:

A producer-supplied identifier that correlates multiple Delivery Attempts representing the same logical Event, enabling optional consumer-side deduplication.

Retry:

A subsequent Delivery Attempt for the same logical Event following a non-Accepted Sender-Observed Outcome.

Problem Statement 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.

Interoperability Failures Observed in Practice The absence of a shared delivery semantics model results in recurring issues, including:

• ambiguous retry behavior and unclear signaling of retry exhaustion;
• inconsistent acknowledgment semantics, with some producers treating any 2xx HTTP response as success and others requiring specific response codes or body content;
• non-standard idempotency and deduplication signaling, with header field names and value formats varying per producer;
• unclear classification of delivery failures, in particular conflation of transport-level and application-level failures; and
• increased exposure to replay and abuse, owing to ad hoc authentication and replay-mitigation conventions.

These issues arise from missing application-layer semantics rather than deficiencies in underlying transport protocols.

Limitations of Existing Transport Semantics 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.

Non-Goals 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 requirements defined in this document apply to sender-observable behavior and signaling.

Goals 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 Identifier and deduplication signaling;
• improve security posture through consistent guidance (see ); and
• reduce ambiguity without constraining implementation choices beyond what is required for interoperability.

Architecture Overview 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.

Roles and Delivery Direction | | | Event Producer | | Event Consumer | | | <--------------------- | | +----------------+ Sender-Observed Outcome+----------------+ (or) +----------+ Delivery +--------------+ Delivery +----------+ | Producer | ---------> | Intermediary | ---------> | Consumer | +----------+ Outcome +--------------+ Outcome +----------+ <--------- <--------- ]]>

An Intermediary takes the Producer role with respect to its downstream Consumer, and the Consumer role with respect to its upstream Producer. The semantics defined in this document therefore apply recursively at each hop.

Delivery Semantics Model 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.

Delivery Attempt 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.

Sender-Observed Outcomes This specification defines three Sender-Observed Outcomes for a Delivery Attempt:

Accepted:

The Consumer acknowledged receipt of the Delivery Attempt. The sender MUST NOT retry the same Delivery Attempt solely on the basis of an Accepted outcome.

Transient Failure:

A condition was observed that the sender may reasonably expect to resolve. The sender MAY retry the Delivery Attempt subject to sender policy.

Terminal Failure:

A condition was observed that the sender cannot reasonably expect to resolve through further Delivery Attempts of the same Event to the same Consumer endpoint. The sender MUST NOT retry the same Delivery Attempt solely on the basis of a Terminal Failure outcome.

Senders MUST base retry behavior solely on Sender-Observed Outcomes and MUST NOT infer receiver-side state beyond what is explicitly signaled.

Retry Signaling Retry behavior is sender-driven and policy-dependent. This specification standardizes only retry signaling, not retry guarantees. Consumers MAY provide retry guidance (for example, by indicating a minimum delay before the next attempt), and senders MAY honor such guidance. When a Consumer provides explicit retry guidance and the sender intends to retry, the sender SHOULD not retry sooner than indicated. Senders SHOULD apply backoff between retries to avoid amplifying load on Consumers experiencing Transient Failure conditions. An algorithm for the HTTP binding is specified in ; interactions with denial-of-service mitigation are discussed in .

Applicability to Other Transports This document defines bindings for HTTP only (). The model in this section is intentionally transport-independent so that bindings to other transports (for example, AMQP, MQTT, or queue-based protocols) may be specified separately without revisiting the abstract semantics. No such bindings are defined here.

Idempotency and Deduplication Signaling Idempotency and deduplication are addressed through explicit signaling mechanisms only. This specification does not require or assume receiver-side deduplication behavior.

Idempotency Identifier 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 of the same logical Event and MUST be scoped to the producer-consumer context. Producers SHOULD generate Idempotency Identifiers with sufficient entropy to make collisions across distinct logical Events negligible within the relevant deduplication window.

Deduplication Expectations 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. A Consumer that performs deduplication SHOULD maintain Idempotency Identifier state for a finite Deduplication Window. When no value is communicated out of band or by prior agreement, a minimum Deduplication Window of 24 hours is RECOMMENDED. A Producer MUST NOT reuse an Idempotency Identifier for a distinct logical Event within the Consumer's Deduplication Window. When the Window is not known to the Producer, the Producer SHOULD treat it as at least the RECOMMENDED minimum above and SHOULD generate fresh identifiers per distinct logical Event regardless.

Failure Classification Failure classification in this specification is minimal and sender-centric. Two failure classes are defined:

Transport-level failure:

A failure attributable to the transport, such as connection refusal, connection reset, timeout, or name-resolution failure. Transport-level failures SHOULD be treated as Transient Failure unless sender policy specifies otherwise.

Application-level rejection:

A failure signaled by the Consumer at the application layer indicating that the Delivery Attempt was received but not accepted. Application-level rejections MAY be either Transient Failure or Terminal Failure depending on the specific signal (see for the HTTP mapping).

Failure classifications are used solely to inform sender behavior such as retry decisions, alternate delivery paths, or operator intervention. They carry no semantic guarantees about Consumer-side processing.

HTTP Binding This section defines a binding of the delivery semantics model () to HTTP . Producers and Consumers exchanging Events over HTTP SHOULD implement this binding to enable interoperability. Other transport bindings are out of scope for this document.

Method and Request Semantics A Delivery Attempt using the HTTP binding SHOULD use the POST method. PUT MAY be used when Producer and Consumer have prior agreement that the Event payload represents the replacement state of the resource identified by the request URI. Safe methods (GET, HEAD, OPTIONS) are NOT RECOMMENDED for Delivery Attempts because they imply no state change and are subject to intermediary caching behavior that may suppress retries. The Content-Type of the request MUST accurately identify the Event payload media type. This document does not constrain payload media type; see for a discussion of common choices.

Mapping Sender-Observed Outcomes to HTTP Status Codes When a Consumer returns an HTTP response to a Delivery Attempt, the sender derives the Sender-Observed Outcome from the response. The mappings in this section represent the default behavior that applies in the absence of out-of-band agreement. Producers and Consumers MAY agree on alternative interpretations for individual status codes, provided that any such agreement (a) is documented in writing, (b) is discoverable by operators of both parties, and (c) does not weaken the security properties required by . Absent such an agreement, the defaults below apply.

Accepted A 2xx (Successful) status code SHOULD be treated as Accepted. The following finer-grained guidance applies:

• 200 (OK), 201 (Created), 202 (Accepted), and 204 (No Content) MUST be treated as Accepted when received in response to a Delivery Attempt.
• 207 (Multi-Status) SHOULD NOT be treated as Accepted at the Delivery Attempt level without parsing the body, because per-element status may include failures requiring sender action. Producers and Consumers using 207 MUST have prior agreement on its interpretation.
• Other 2xx status codes SHOULD be treated as Accepted unless prior agreement specifies otherwise.

The presence or absence of a response body MUST NOT alter the Sender-Observed Outcome derived from a 2xx status code, except as stated above for 207.

Transient Failure The following status codes SHOULD be treated as Transient Failure: Status Codes Mapped to Transient Failure

Code	Name	Notes
408	Request Timeout	Ambiguous: the request may or may not have been processed. Safe retry depends on the Idempotency-Key field, which is required by .
421	Misdirected Request	Indicates routing error at the Consumer; retry MAY succeed against a re-resolved endpoint.
425	Too Early	Retry after the early-data condition clears.
429	Too Many Requests	Honor Retry-After () if present.
500	Internal Server Error	Generic server error; retry with backoff.
502	Bad Gateway	Upstream of Consumer failed; retry.
503	Service Unavailable	Honor Retry-After if present.
504	Gateway Timeout	Same ambiguity as 408; safe retry depends on the Idempotency-Key field required by .
511	Network Authentication Required	Typically injected by an on-path captive portal; resolves out of band.

Other 5xx status codes not listed above SHOULD be treated as Transient Failure unless prior agreement specifies otherwise.

Terminal Failure The following status codes SHOULD be treated as Terminal Failure: Status Codes Mapped to Terminal Failure

Code	Name	Notes
400	Bad Request	Malformed request; retry will produce the same outcome.
401	Unauthorized	Producers operating with rotating credentials MAY attempt one credential refresh and a single subsequent retry before classifying as Terminal.
403	Forbidden	Authorization decision; retry not useful absent policy change.
404	Not Found	Endpoint missing; reconfiguration required.
405	Method Not Allowed	Producer-Consumer agreement mismatch; see .
410	Gone	Endpoint permanently removed; Producer SHOULD mark the subscription inactive.
413	Content Too Large	Event payload exceeds Consumer limit; retry without payload reduction will fail.
414	URI Too Long	Typically a Producer configuration error.
415	Unsupported Media Type	Renegotiate media type out of band.
422	Unprocessable Content	Schema or semantic validation failure.
451	Unavailable for Legal Reasons	Producer SHOULD record and escalate to operator review.

Other 4xx status codes not listed above SHOULD be treated as Terminal Failure unless prior agreement specifies otherwise. When a Consumer signals deprecation via the Sunset header field , Producers SHOULD treat continued Delivery Attempts past the indicated Sunset time as candidates for Terminal classification on the next non-Accepted outcome.

Other Status Code Classes 1xx (Informational) status codes are handled per and do not in themselves constitute a Sender-Observed Outcome. 3xx (Redirection) status codes are handled per . In particular, 308 (Permanent Redirect) SHOULD cause the Producer to update its stored endpoint URI for the subscription before issuing the next Delivery Attempt. 307 (Temporary Redirect) MUST NOT cause the Producer to update stored configuration.

Problem Details in Responses Consumers MAY return problem details in the response body using the format defined in to aid operator diagnosis. The Sender-Observed Outcome MUST still be derived from the status code; problem details are advisory.

Network-Level Failures A Delivery Attempt that fails before a complete HTTP response status line is received (for example, due to connection refusal, connection reset, TLS handshake failure, request timeout, or name-resolution failure) MUST be treated as a transport-level failure as defined in and, by default, as Transient Failure. A Delivery Attempt for which the request was transmitted but the response was not received in full MUST be treated as Transient Failure with unknown outcome. Safe retry in this case depends on the Idempotency-Key header field, which is required by for all Delivery Attempts in the HTTP binding.

Idempotency-Key Header Field In the HTTP binding defined by this document, every Delivery Attempt MUST include an Idempotency-Key header field carrying the Idempotency Identifier defined in . The header field's syntax and processing rules MUST be those defined by . The value of the Idempotency-Key header field MUST be identical across all Delivery Attempts for the same logical Event from the same Producer-Consumer Context (defined below). The value MUST be a string of sufficient entropy to make collisions negligible across the Deduplication Window (); a UUID or a base64url-encoded random value of at least 128 bits satisfies this requirement. For the purposes of this document, a Producer-Consumer Context is the tuple (Producer identity, Consumer endpoint URI), where:

• Producer identity is the authenticated principal presenting the Delivery Attempt. Authentication is REQUIRED in the HTTP binding; see .
• Consumer endpoint URI is the effective request URI as defined in , after any 308 (Permanent Redirect) updates per .

Two Delivery Attempts share an Idempotency-Key scope if and only if they share a Producer-Consumer Context.

Retry-After Header Field When a Consumer returns a response classified as Transient Failure, the Consumer MAY include a Retry-After header field as defined in to indicate a minimum delay before the next Delivery Attempt. When a Retry-After header field is present in a response classified as Transient Failure and the sender intends to retry, the sender SHOULD NOT initiate the next Delivery Attempt for the same logical Event sooner than indicated by the Retry-After value. Senders MAY apply additional backoff beyond the Retry-After value at their discretion. A Retry-After value of 0 indicates that the Consumer has no preferred delay; the Producer's local retry policy applies (see ).

Recommended Retry Algorithm Producers retrying after Transient Failure outcomes SHOULD apply an algorithm with the following properties:

• monotonically non-decreasing expected delay between successive retries (backoff);
• independent randomization across Producer instances (jitter), to prevent synchronized retry storms; and
• a finite maximum number of retries, a finite total retry duration, or both.

A widely deployed default that satisfies these requirements is full-jitter exponential backoff. For retry attempt n (with n = 0 denoting the first retry), the sender selects a delay uniformly at random from the interval [0, min(cap, base * 2^n)], where base is a baseline delay (a value of 1 second is commonly used) and cap is an upper bound on a single delay (commonly between 60 and 600 seconds). Producers MAY use other algorithms that satisfy the properties above. When a Retry-After value is supplied () and exceeds the delay selected by the algorithm above, the Retry-After value MUST be honored as the lower bound for the next Delivery Attempt.

Intermediary Behavior When an Intermediary () relays an Event over the HTTP binding:

• The Idempotency-Key header field value MUST be preserved unchanged on the relayed Delivery Attempt sent to the downstream Consumer. Intermediaries MUST NOT rewrite the value, even when they buffer or fan out Events.
• The Retry-After header field MUST NOT be propagated upstream. It applies only between the immediate sender and receiver of a given hop.
• The Sender-Observed Outcome at each hop is independent. An Intermediary MAY return any outcome to its upstream Producer that accurately reflects its own state.
• Authentication and integrity protection (, ) apply per hop unless an end-to-end mechanism such as HTTP Message Signatures is used to bind origin metadata across hops.

An Intermediary that buffers Events MAY return Accepted upstream prior to successful downstream delivery (store-and-forward operation) only when both of the following conditions hold:

1. The Intermediary's store-and-forward behavior, including its durability guarantees and its retry policy toward the downstream Consumer, is documented in a service description that is accessible to operators of the upstream Producer; and
2. The upstream Producer has acknowledged that service description out of band (for example, by accepting terms of service, by configuring the Intermediary as a delivery target, or by equivalent administrative action).

Absent both conditions, an Intermediary MUST NOT return Accepted upstream before the downstream Delivery Attempt has itself yielded an Accepted Sender-Observed Outcome.

Examples The examples in this section are illustrative and non-normative. Line breaks within header fields are inserted for readability only. All hostnames use example.com per . For clarity, the Content-Length header field and other framing headers are omitted from the examples; the message-body length is determined per .

Example: Accepted A Producer delivers an Event; the Consumer acknowledges with 200 OK. Sender-Observed Outcome: Accepted. No retry is performed.

Example: Transient Failure with Retry-After The Consumer is under load and asks the Producer to retry after 30 seconds. Sender-Observed Outcome: Transient Failure. The Producer waits at least 30 seconds, then retries the same Delivery Attempt with the same Idempotency-Key. The retry is Accepted. Because the Idempotency-Key is preserved, a Consumer that performs deduplication (see ) processes the Event exactly once across the two Delivery Attempts.

Example: Terminal Failure with Problem Details The Consumer rejects the Event as semantically invalid. Sender-Observed Outcome: Terminal Failure. The Producer MUST NOT retry the Delivery Attempt; the problem details are recorded for operator diagnosis.

Example: Network-Level Failure The Producer establishes a TCP connection to consumer.example.com on port 443. TLS negotiation completes. The Producer transmits the request in full and waits for a response. After 60 seconds with no response bytes received, the Producer's local timeout fires and the connection is closed. Sender-Observed Outcome: Transient Failure, with unknown receiver state per . The Producer retries using the same Idempotency-Key to permit Consumer-side deduplication. The next retry delay is governed by .

HTTP Version Considerations The Delivery Attempt semantics defined in this section are version-independent at the application layer. The following version-specific behaviors apply:

• Producers using HTTP/2 or HTTP/3 MAY multiplex multiple Delivery Attempts on a single connection. Stream reset (RST_STREAM in HTTP/2; STOP_SENDING or RESET_STREAM in HTTP/3) after the request has been transmitted but before a complete response is received MUST be treated as a network-level failure per .
• Producers MUST NOT send Delivery Attempts in TLS 1.3 0-RTT (early) data unless the Producer-Consumer Context explicitly permits it through out-of-band agreement satisfying the conditions in . TLS 1.3 0-RTT data is replay-vulnerable at the transport layer regardless of application-layer signing or Idempotency-Key-based deduplication; see .
• HTTP/2 server push and HTTP/3 server push MUST NOT be used to deliver Events. The Sender-Observed Outcome model presumes sender-initiated Delivery Attempts.

Relationship to Existing Work Several existing specifications and operational conventions overlap with the scope of this document. This section positions this profile relative to that work.

CloudEvents :

CloudEvents defines a payload format for event data and bindings of that format to several transports including HTTP. CloudEvents does not normatively define retry, acknowledgment, or deduplication semantics. This document is complementary: a CloudEvents-formatted payload may be delivered using this profile.
The CloudEvents "id" attribute is defined to be unique per (source, id) pair within the producer, not necessarily globally unique, and CloudEvents does not require "id" to be stable across delivery retries. Accordingly, a Producer MAY reuse the CloudEvents "id" value as the Idempotency Identifier () only when (a) the Producer guarantees the value is stable across all retries of the same logical Event, and (b) the (source, id) scope falls within a single Producer-Consumer Context (). When either condition does not hold, the Producer MUST generate a separate Idempotency Identifier and carry it in the Idempotency-Key header field independently of the CloudEvents "id".

The Idempotency-Key header field :

This profile reuses the Idempotency-Key header field as defined by that work in progress () rather than defining a new header. The two documents are intended to remain aligned.

HTTP Semantics :

This profile builds on but does not modify HTTP semantics. The status-code interpretations in are application-layer conventions specific to event delivery; they do not override the meaning of any status code defined by .

WebSub :

WebSub is a W3C Recommendation defining a publish-subscribe protocol over HTTP, including subscription management. WebSub does not standardize the delivery semantics this document addresses; a WebSub publisher and subscriber could in principle adopt this profile for the notification leg of the protocol.

Vendor webhook conventions:

Major commercial event and webhook platforms publish internally consistent but mutually divergent conventions for retry, acknowledgment, idempotency, and signing. A non-exhaustive survey of publicly documented behavior across such systems is provided in ; the mappings in and the default values in this document fall within the central range observed in that survey.

Security Considerations Event delivery mechanisms are commonly used to convey security-sensitive notifications across administrative boundaries. This section profiles existing security mechanisms and provides guidance on their application to the delivery semantics defined in this document. No new cryptographic mechanisms are defined. The guidance below follows the structure recommended by .

Threat Model The principal threats to event and webhook delivery considered by this document are:

• spoofing of an Event Producer by a third party in order to inject fabricated Events into a Consumer;
• replay of previously delivered Events by an on-path or off-path attacker;
• modification of Event payloads or metadata in transit;
• disclosure of Event contents to unauthorized parties; and
• abuse of retry behavior to amplify load against either a Consumer or an unrelated third party.

Transport Security Producers and Consumers SHOULD use TLS for all Delivery Attempts. Producers SHOULD validate Consumer endpoint certificates and SHOULD NOT deliver Events to endpoints that fail certificate validation.

Authentication of Producers In the HTTP binding (), Consumers MUST authenticate the Producer of each Delivery Attempt. This requirement supports the Producer-Consumer Context definition in and is the basis of the replay-mitigation requirement in . Suitable authentication mechanisms include, but are not limited to, HTTP Message Signatures , mutual TLS, and bearer tokens carried in the Authorization header field as defined in . Selection of a specific mechanism is a deployment decision and is out of scope for this document. Whatever mechanism is chosen, Consumers MUST NOT treat a Delivery Attempt as Accepted on the basis of its payload alone when authentication has not been verified.

Integrity Protection Producers SHOULD protect the integrity of Event payloads and security-relevant metadata in transit. Use of TLS () provides integrity for the transport channel. Use of HTTP Message Signatures additionally provides integrity over selected message components that survives intermediary processing.

Replay Mitigation Consumers that act on Events MUST mitigate replay attacks. At least one of the following mechanisms MUST be in effect for any Consumer for which replay would have security consequences:

1. Deduplication based on the Idempotency Identifier () within an active Deduplication Window. This mechanism is sufficient against replay only for the duration of the Window and only when the Window is enforced.
2. Verification of a Producer-supplied freshness indicator (such as a signed timestamp or nonce) carried in authenticated metadata, where Delivery Attempts with timestamps outside an acceptance window or with previously seen nonces are rejected.

The Idempotency Identifier alone is NOT RECOMMENDED as a sole replay countermeasure outside the bounded Deduplication Window, because Producers may legitimately reuse identifiers beyond that window per local policy. Consumers that do not perform deduplication MUST implement mechanism (2) above to satisfy the requirement in this section. When Delivery Attempts traverse TLS 1.3 , neither mechanism above mitigates replay of TLS 1.3 0-RTT (early) data, which is replayable at the transport layer. Producers MUST NOT transmit Delivery Attempts as 0-RTT data except under the conditions stated in . When Delivery Attempts are transmitted as 0-RTT data under those conditions, Consumers MUST rely on mechanism (2) above for replay protection; the Deduplication Window alone is insufficient because a 0-RTT replay may deliver an Event with an Idempotency Identifier that the Consumer has not yet seen.

Confidentiality Event payloads may contain confidential data. Producers and Consumers SHOULD use TLS to provide confidentiality on the transport channel and SHOULD avoid logging full Event payloads at intermediary points where such logs are not subject to equivalent protection.

Endpoint Authorization Producers SHOULD deliver Events only to Consumer endpoints that have been explicitly registered or otherwise authorized to receive them. Producers that accept user-supplied delivery URLs (for example, customer-configurable webhook endpoints) SHOULD validate those URLs and SHOULD NOT permit delivery to addresses inside their own trust boundary unless explicitly intended, to mitigate server-side request forgery.

Retry Amplification and Denial-of-Service Considerations Retry behavior interacts directly with availability. The bounding and jitter requirements in are motivated in part by the need to prevent senders from amplifying load against a Consumer recovering from a Transient Failure condition. Senders MUST NOT retry without bound; the finite-retry requirement in is normative for that reason. When a Consumer returns a Retry-After value (), honoring that value contributes directly to mitigating retry amplification. Producers SHOULD additionally treat repeated Terminal Failure outcomes from a single Consumer endpoint as a signal to disable further Delivery Attempts to that endpoint until operator intervention, so as not to amplify load against endpoints that have been removed, misconfigured, or unsubscribed.

IANA Considerations This document makes no request of IANA. The HTTP header field name "Idempotency-Key" referenced in is registered by ; this document defers to that registration.

References Normative References Informative References Work in Progress Cloud Native Computing Foundation W3C Recommendation

Changes from -00 This section will be removed prior to publication. Structural and editorial changes:

• Renamed the combined "Terminology" section to "Conventions and Terminology" and incorporated the full BCP 14 boilerplate citing both and .
• Expanded the terminology list to include Event, Event Producer, Event Consumer, Intermediary, Sender-Observed Outcome, Accepted, Transient Failure, Terminal Failure, and Retry, in addition to the three terms defined in -00.
• Added a figure illustrating the Producer/Consumer/Intermediary roles and recursive application of the model at each hop.
• Reworded Non-Goals and Goals as bulleted lists for clarity.
• Split References into Normative and Informative subsections per structure.
• Corrected the expiry date inconsistency present in -00 ("Expires: 28 June 2026" in the header versus "4 June 2026" in the Status of This Memo section).
• Editorial: tightened the Introduction and Problem Statement for consistency of terminology and cross-references; aligned capitalization of defined terms throughout.

Model and normative content:

• Promoted "Accepted", "Transient Failure", and "Terminal Failure" from informal names to normatively defined Sender-Observed Outcomes with explicit retry semantics ().
• Defined a Deduplication Window with a recommended minimum of 24 hours, and constrained Producer reuse of Idempotency Identifiers accordingly ().
• Added a normative HTTP Binding section () covering method semantics, status-code mapping to Sender-Observed Outcomes, treatment of network-level failures, use of the Idempotency-Key header field aligned with , use of the Retry-After header field per , a recommended retry algorithm with full-jitter exponential backoff, and explicit Intermediary behavior across hops.
• Replaced the single status-code mapping list with three tables (, , and the prose handling of 2xx, 3xx, and 1xx) covering 408, 421, 425, 429, 500, 502, 503, 504, 511 as Transient and 400, 401, 403, 404, 405, 410, 413, 414, 415, 422, 451 as Terminal, with per-code rationale. MUST/SHOULD distribution adjusted to reflect operational reality (for example, 401 demoted from MUST Terminal to SHOULD Terminal with explicit rotating-credential allowance; 408 and 504 demoted from MUST Transient to SHOULD Transient with explicit ambiguity warning).
• Defined the Producer-Consumer Context as the tuple (Producer identity, Consumer endpoint URI) to make the scope of Idempotency-Key precise ().
• Added handling guidance for the Sunset header field and for 308 vs 307 redirects.
• Added four worked HTTP examples (): Accepted, Transient Failure with Retry-After followed by retry, Terminal Failure with Problem Details, and a network-level failure.
• Added a Relationship to Existing Work section () positioning the profile against CloudEvents, , , WebSub, and vendor webhook conventions.

Security:

• Expanded the Security Considerations section per to include a threat model and guidance on transport security, producer authentication, integrity protection, replay mitigation, confidentiality, endpoint authorization, and denial-of-service considerations.
• Reconciled the optional-deduplication position in with the replay-mitigation requirement in : Consumers that do not perform deduplication MUST implement an alternative freshness mechanism (signed timestamp or nonce).

References added:

• Normative: , .
• Informative: , , , , , , , , , , , CloudEvents, WebSub.

Internal-consistency and second-pass review changes:

• Promoted the Idempotency-Key header field requirement in the HTTP binding from SHOULD to MUST (); this removes the MUST-on-SHOULD construction in the 408, 504, and network-level-failure handling and makes the Producer-Consumer Context definition well-formed in all cases.
• Promoted Producer authentication in the HTTP binding from SHOULD to MUST () so the Producer-Consumer Context is always defined and the replay-mitigation requirement is satisfiable.
• Constrained the buffered-Intermediary store-and-forward acceptance rule (): an Intermediary may return Accepted upstream prior to downstream delivery only when its store-and-forward behavior is documented in an operator-accessible service description and the upstream Producer has acknowledged that description out of band.
• Tightened the "prior agreement" escape hatch in : alternative interpretations must be documented in writing, operator-discoverable, and must not weaken the security properties in .
• Corrected the CloudEvents alignment claim (): the CloudEvents "id" attribute may be reused as the Idempotency Identifier only when stability across retries and Producer-Consumer Context containment are both guaranteed; otherwise a separate Idempotency-Key value is required.
• Added covering HTTP/2 and HTTP/3 stream-reset handling, TLS 1.3 0-RTT replay considerations, and the prohibition on using HTTP/2 or HTTP/3 server push for Delivery Attempts.
• Added a TLS 1.3 0-RTT paragraph to requiring the alternative freshness mechanism when Delivery Attempts traverse 0-RTT data.
• Consolidated retry-bound and backoff guidance in to cross-reference rather than duplicate it, and added a normative SHOULD for disabling endpoints after repeated Terminal Failure outcomes.
• Removed Content-Length values from the worked HTTP examples () so the examples are textually self-consistent without maintaining a redundant length field.
• Added a non-normative noting that bindings to transports other than HTTP are out of scope but intended to be supported by the abstract model.
• Added documenting the empirical basis for the recommended default values (deduplication window, backoff parameters) and for the status-code mappings.

Implementation Survey This appendix is non-normative. It documents the empirical basis for the default values recommended in and and for the status-code mappings in . Values reported here are taken from publicly available vendor documentation as of the date of this revision and are intended to illustrate the design space rather than to assert the current state of any individual system. Implementers SHOULD consult current vendor documentation for the specific systems they integrate with.

Surveyed Systems The following event and webhook platforms publish delivery-semantics documentation and were considered in framing this document:

• Stripe Webhooks
• GitHub Webhooks
• Amazon Web Services EventBridge and Amazon SNS HTTP/HTTPS subscriptions
• Microsoft Azure Event Grid
• Google Cloud Eventarc
• Twilio Event Streams and Webhooks
• Shopify Webhooks
• Slack Events API
• PayPal Webhooks
• The Svix open-source webhook service

Retry Strategies Surveyed systems report total retry windows ranging from approximately ten minutes (for low-tolerance notification systems) to several days (for billing- and account-state systems), with the central tendency falling between four and seventy-two hours. Retry counts within those windows range from a single-digit fixed-count strategy (e.g., a small number of attempts at fixed offsets) to exponential strategies extending to one or two hundred attempts. The dominant backoff shape is exponential with random jitter. Base delays in the range of a few seconds and per-attempt caps in the range of several minutes to ten minutes are common. The default algorithm and parameters in (base of 1 second, cap between 60 and 600 seconds) fall within this central range.

Idempotency and Deduplication Surveyed systems are uniform in providing a producer-supplied identifier intended to support consumer-side deduplication, though they vary in naming (Idempotency-Key, delivery GUID, event id, and others) and in whether the identifier is carried in an HTTP header field or in the payload body. Reported deduplication windows, where stated, range from approximately one hour to seven days. Twenty-four hours is the most commonly reported value among systems that publish a specific window. The RECOMMENDED minimum of 24 hours in reflects this observation.

Status Code Treatment Surveyed systems are broadly consistent in treating 2xx responses as Accepted, 5xx responses as retriable, and 4xx responses as non-retriable, with the exceptions and special cases captured in . Specific divergences observed include:

• Treatment of 408 Request Timeout and 504 Gateway Timeout varies; some systems retry, others do not. This document treats them as Transient but flags the ambiguity.
• Treatment of 429 Too Many Requests is consistently retriable, with most systems honoring the Retry-After header field when present.
• Treatment of 410 Gone varies, with some systems automatically disabling the affected subscription and others requiring operator action. This document classifies 410 as Terminal and recommends marking the subscription inactive.

Synthesis The default values and mappings recommended in this document are positioned to interoperate with the central range of observed practice rather than with any single system's specific behavior. Where this document adopts a tighter or stronger position than current practice (for example, requiring authentication and Idempotency-Key in the HTTP binding), that position is motivated by the security and interoperability goals stated in .

Acknowledgements The author thanks early reviewers of -00 for their feedback and discussion. Specific acknowledgements will be added in future revisions as the document attracts community review.