# Webhook／Event protocol

CURRENT_STATUS: UNKNOWN
OBSERVATION: SPEC_ONLY
FRESHNESS: UNKNOWN
PAGE_TYPE: reference
CANONICAL_URL: /tools/ea-161-webhook-event-protocol
CLAIM_IDS: none
EVIDENCE_IDS: EVD-EA-161-URL-87DD5C76B00E, EVD-EA-161-URL-7BE6C5F37167, EVD-EA-161-URL-8C862D06E383, EA-161-R11-RESEARCH, EA-161-R11-WEB-READBACK
UNKNOWN_IDS: EA-161-UNKNOWN-01, EA-161-UNKNOWN-CURRENTNESS
OPS_IDS: none

## Summary
「WebhookはHTTP等による通知・受信の配置であり、全実装に共通する配送保証ではない。CloudEvents v1.0.2はevent context/data、specversion、source/id、format、protocol bindingを定義するが、exactly-once、順序、retry、署名、認証、業務処理の原子性は個別契約として設計・検証する。」

## Current judgment
1. ESTABLISHED [S1 support]: CloudEvents separates event context metadata from domain-specific data, defines event formats, messages, protocols, and protocol bindings. The core spec names HTTP, AMQP, MQTT, SMTP, Kafka, NATS, and vendor-specific transports as possible delivery protocols.
2. ESTABLISHED [S1 support]: In v1.0, specversion identifies the CloudEvents specification version; source and id are required, and producers must make source+id unique for each distinct event. A resent duplicate may retain the same id, and consumers may treat identical source+id as duplicates.
3. INFERENCE [S1+S2]: CloudEvents source+id can support consumer idempotency/deduplication design, but it does not by itself provide exactly-once delivery, ordering, retry, authentication, signature verification, dead-letter handling, or business transaction atomicity.
4. ESTABLISHED [S1 limit]: A protocol binding describes how events are sent/received over a transport; it may use structured or binary mode. The existence of a binding does not establish a universal webhook delivery behavior.

## Scope
interoperability / non-LLM component / implementation / operability / security / governance

## Confirmed
- ESTABLISHED [S1 support]: CloudEvents separates event context metadata from domain-specific data, defines event formats, messages, protocols, and protocol bindings. The core spec names HTTP, AMQP, MQTT, SMTP, Kafka, NATS, and vendor-specific transports as possible delivery protocols.
- ESTABLISHED [S1 support]: In v1.0, specversion identifies the CloudEvents specification version; source and id are required, and producers must make source+id unique for each distinct event. A resent duplicate may retain the same id, and consumers may treat identical source+id as duplicates.
- INFERENCE [S1+S2]: CloudEvents source+id can support consumer idempotency/deduplication design, but it does not by itself provide exactly-once delivery, ordering, retry, authentication, signature verification, dead-letter handling, or business transaction atomicity.
- ESTABLISHED [S1 limit]: A protocol binding describes how events are sent/received over a transport; it may use structured or binary mode. The existence of a binding does not establish a universal webhook delivery behavior.

## UNKNOWN
- EA-161-UNKNOWN-01: current tag/binding parity; signature/auth profile; producer truthfulness; delivery/retry/order guarantees; dedupe durability; schema registry; DLQ/replay policy; tenant isolation/data residency; event-to-agent cost/SLO; public incidents.
- EA-161-UNKNOWN-CURRENTNESS: 外部根拠の再確認日がcanonical body/control-planeで確定していないため、currentnessはUNKNOWNとして保持する。日付を推測補完しない。

## Evidence
- EVD-EA-161-URL-87DD5C76B00E (RESEARCH): [S1] SOURCE_CLASS: official_spec | EXACT_TITLE: CloudEvents Specification | AUTHOR_ORG: Cloud Native Computing Foundation CloudEvents project | CANONICAL_URL: — https://github.com/cloudevents/spec/blob/v1.0.2/cloudevents/spec.md
- EVD-EA-161-URL-7BE6C5F37167 (RESEARCH): [S2] SOURCE_CLASS: official_spec | EXACT_TITLE: CloudEvents HTTP Protocol Binding | AUTHOR_ORG: Cloud Native Computing Foundation CloudEvents project | CANONICAL_URL: — https://github.com/cloudevents/spec/blob/v1.0.2/cloudevents/bindings/http-protocol-binding.md
- EVD-EA-161-URL-8C862D06E383 (RESEARCH): [S3] SOURCE_CLASS: official_project_docs | EXACT_TITLE: CloudEvents | AUTHOR_ORG: Cloud Native Computing Foundation CloudEvents project | CANONICAL_URL: — https://cloudevents.io/
- EA-161-R11-RESEARCH (RESEARCH): EA-161 監査済みresearch / canonical revision binding
- EA-161-R11-WEB-READBACK (IMPL): EA-161 Web body identity / canonical readback

## Failure / limits
The core v1.0.2 page has no universal idempotency, retry, ordering, or exactly-once guarantee; the packet therefore preserves those as deployment unknowns. HTTP success can be lost before consumer processing is durable; retries can duplicate side effects; events can arrive late/out of order; signatures/auth, payload schema, replay window, and poison-event handling may differ. CloudEvents envelope conformance does not prove that a producer sends truthful context or that an agent action is safe.
## Failure / limits
Do not infer exactly-once or at-least-once from CloudEvents envelope fields alone. Do not call CloudEvents a universal webhook delivery guarantee or treat source+id as proof that a side effect is idempotent.
UNIT_CLOSE_STATUS: INDIVIDUAL_BOUNDED_CLOSE / EVIDENCE_RECORDED / UNKNOWN_PRESERVED
## Practice
CloudEvents version and binding; HTTP endpoint/TLS; authentication/signature/replay protection; source/id generation; event type/schema/content type; producer/consumer compatibility; retry/backoff/timeout; deduplication/idempotency store; ordering/partition key; DLQ/quarantine; payload size/redaction; tenancy/region; observability and retention; downstream agent approval and side-effect policy.
## Practice
Evidence-only desk research. No webhook endpoint was created, called, replayed, or connected to an agent.
## Practice
No delivery, duplicate, out-of-order, retry, signature, throughput, or recovery test was run. CloudEvents specification is not a delivery benchmark.
## Practice
Treat event payload/context as potentially sensitive. Verify issuer/signature, freshness, audience, source, type, schema, and replay status before enqueueing. Persist event ID and processing outcome for deduplication; log receipt, validation, queue, agent decision, tool execution, retry, and final disposition. Cost includes ingress, queue, storage, retries, agent tokens, downstream action, and human approval; not measured.
## Practice
Future update Work should pin CloudEvents core and binding tags, then create a non-destructive TEST_PROFILE for malformed event, duplicate source+id, replay, delayed/out-of-order delivery, lost acknowledgment, signature failure, schema evolution, DLQ, dedupe store outage, and agent approval. Keep webhook transport, event envelope, queue semantics, and agent execution as separate claims.
## WHY_THIS_MATTERS_TO_UPDATE
Event-driven agent triggers are often described as if webhook delivery were exactly-once or as if every webhook had one standard. CloudEvents provides a precise envelope/binding reference, but delivery, retry, ordering, identity, and replay remain deployment contracts.

## SCOPE_ROUTING
interoperability / non-LLM component / implementation / operability / security / governance

## CLAIM_OR_RESEARCH_QUESTION
What does CloudEvents v1.0.2 standardize about event context, data, formats, and protocol bindings, and what must an enterprise webhook/event implementation specify separately?

## EVIDENCE_TABLE
[S1] SOURCE_CLASS: official_spec | EXACT_TITLE: CloudEvents Specification | AUTHOR_ORG: Cloud Native Computing Foundation CloudEvents project | CANONICAL_URL: https://github.com/cloudevents/spec/blob/v1.0.2/cloudevents/spec.md | PUBLICATION_UPDATE_ACCESS: fixed tag v1.0.2; accessed 2026-09-14 00:10 JST | VERSION_RELEASE_TAG: v1.0.2 | SUPPORTING_LOCATOR: context/data/event-format/message/protocol/binding lines 251-275; specversion lines 351-355; source/id uniqueness and duplicate guidance lines 316-334 in the recorded web capture | EVIDENCE_LABEL: VERIFIED_SPEC | RELATION: support for event-envelope and binding facts; limit for delivery guarantees.
[S2] SOURCE_CLASS: official_spec | EXACT_TITLE: CloudEvents HTTP Protocol Binding | AUTHOR_ORG: Cloud Native Computing Foundation CloudEvents project | CANONICAL_URL: https://github.com/cloudevents/spec/blob/v1.0.2/cloudevents/bindings/http-protocol-binding.md | PUBLICATION_UPDATE_ACCESS: fixed tag v1.0.2; accessed 2026-09-14 00:10 JST | VERSION_RELEASE_TAG: v1.0.2 | SUPPORTING_LOCATOR: HTTP binding document: structured and binary mode mapping of CloudEvents to HTTP; binding is transport-specific and must be read with the core spec | EVIDENCE_LABEL: VERIFIED_SPEC | RELATION: support for HTTP webhook mapping; limit because a binding is not a delivery/SLO contract.
[S3] SOURCE_CLASS: official_project_docs | EXACT_TITLE: CloudEvents | AUTHOR_ORG: Cloud Native Computing Foundation CloudEvents project | CANONICAL_URL: https://cloudevents.io/ | PUBLICATION_UPDATE_ACCESS: project page accessed 2026-09-14 00:10 JST | VERSION_RELEASE_TAG: project page current; no extra version promoted | SUPPORTING_LOCATOR: canonical project page and CloudEvent v1 context-attribute reference | EVIDENCE_LABEL: VERIFIED_SPEC + PRODUCT_VOLATILE | RELATION: context only; fixed tag S1 remains normative boundary.

## FINDINGS
1. ESTABLISHED [S1 support]: CloudEvents separates event context metadata from domain-specific data, defines event formats, messages, protocols, and protocol bindings. The core spec names HTTP, AMQP, MQTT, SMTP, Kafka, NATS, and vendor-specific transports as possible delivery protocols.
2. ESTABLISHED [S1 support]: In v1.0, specversion identifies the CloudEvents specification version; source and id are required, and producers must make source+id unique for each distinct event. A resent duplicate may retain the same id, and consumers may treat identical source+id as duplicates.
3. INFERENCE [S1+S2]: CloudEvents source+id can support consumer idempotency/deduplication design, but it does not by itself provide exactly-once delivery, ordering, retry, authentication, signature verification, dead-letter handling, or business transaction atomicity.
4. ESTABLISHED [S1 limit]: A protocol binding describes how events are sent/received over a transport; it may use structured or binary mode. The existence of a binding does not establish a universal webhook delivery behavior.

## LIMITS / COUNTEREVIDENCE / FAILURE ENVELOPE
The core v1.0.2 page has no universal idempotency, retry, ordering, or exactly-once guarantee; the packet therefore preserves those as deployment unknowns. HTTP success can be lost before consumer processing is durable; retries can duplicate side effects; events can arrive late/out of order; signatures/auth, payload schema, replay window, and poison-event handling may differ. CloudEvents envelope conformance does not prove that a producer sends truthful context or that an agent action is safe.

## AVAILABILITY_GATES
CloudEvents version and binding; HTTP endpoint/TLS; authentication/signature/replay protection; source/id generation; event type/schema/content type; producer/consumer compatibility; retry/backoff/timeout; deduplication/idempotency store; ordering/partition key; DLQ/quarantine; payload size/redaction; tenancy/region; observability and retention; downstream agent approval and side-effect policy.

## IMPLEMENTATION_STATE
Evidence-only desk research. No webhook endpoint was created, called, replayed, or connected to an agent.

## BENCHMARK_OR_EVAL
No delivery, duplicate, out-of-order, retry, signature, throughput, or recovery test was run. CloudEvents specification is not a delivery benchmark.

## SECURITY / PRIVACY / AUDIT / COST / OPERABILITY
Treat event payload/context as potentially sensitive. Verify issuer/signature, freshness, audience, source, type, schema, and replay status before enqueueing. Persist event ID and processing outcome for deduplication; log receipt, validation, queue, agent decision, tool execution, retry, and final disposition. Cost includes ingress, queue, storage, retries, agent tokens, downstream action, and human approval; not measured.

## SAFE_WORDING_FOR_FUTURE_BOOK
「WebhookはHTTP等による通知・受信の配置であり、全実装に共通する配送保証ではない。CloudEvents v1.0.2はevent context/data、specversion、source/id、format、protocol bindingを定義するが、exactly-once、順序、retry、署名、認証、業務処理の原子性は個別契約として設計・検証する。」

## UPDATE_WORK_HANDOFF
Future update Work should pin CloudEvents core and binding tags, then create a non-destructive TEST_PROFILE for malformed event, duplicate source+id, replay, delayed/out-of-order delivery, lost acknowledgment, signature failure, schema evolution, DLQ, dedupe store outage, and agent approval. Keep webhook transport, event envelope, queue semantics, and agent execution as separate claims.

## OPEN_UNKNOWN
current tag/binding parity; signature/auth profile; producer truthfulness; delivery/retry/order guarantees; dedupe durability; schema registry; DLQ/replay policy; tenant isolation/data residency; event-to-agent cost/SLO; public incidents.

## STOP_CONDITION
Do not infer exactly-once or at-least-once from CloudEvents envelope fields alone. Do not call CloudEvents a universal webhook delivery guarantee or treat source+id as proof that a side effect is idempotent.
UNIT_CLOSE_STATUS: INDIVIDUAL_BOUNDED_CLOSE / EVIDENCE_RECORDED / UNKNOWN_PRESERVED

## EVIDENCE PACKET
---

NEXT: /agent/start.json
STOP: This is a knowledge projection, not an execution order.