Do webhooks and DCP compete?

No. Webhooks are a delivery pattern for pushing an HTTP callback when something happens. DCP is a payload vocabulary for what a project-coordination event contains. One is transport, the other is semantics, and they are designed to stack rather than substitute for each other.

Can I send DCP over a webhook?

Yes. Because DCP is transport-neutral, a DcpMessage envelope can be placed directly in a webhook POST body, the same way it could be a queue message or a mesh frame. Standard Webhooks conventions such as signing and retry apply to the delivery around it without DCP needing any changes.

Does DCP replace Standard Webhooks signing and retry?

No. DCP defines no delivery, retry, or signing mechanics at all; it is silent on transport by design. Signing headers, HMAC verification, and retry schedules stay entirely the job of the webhook layer, whether that is plain webhooks or the Standard Webhooks convention.

DCP vs. Webhooks

A webhook is an HTTP callback delivery pattern; DCP is a payload vocabulary for project-coordination events. Webhooks say how an event reaches you and, under conventions like Standard Webhooks, how delivery gets signed and retried. Webhooks never define what is inside the body. DCP is exactly that missing content — the structure of the message a webhook could carry.

Different questions entirely

“I already have webhooks with signing and retry — why would I also need DCP?”

Because webhooks answer a transport question, not a content question. A webhook (and the community Standard Webhooks convention built on top of plain webhooks) is explicit about this: it standardizes headers (webhook-id, webhook-timestamp, webhook-signature), HMAC-SHA256 or ed25519 signing, and retry/timeout handling — but the spec itself says it “does not dictate the structure, or impose any requirements, on the shape, format, and content of the payload.” That is a deliberate, stated non-goal, not an oversight.

So when a webhook fires because a task was blocked or a decision got recorded, something still has to define what “blocked” or “decision” means as structured data — entity type, verb, correlation to a project, whether it is a delta or a full snapshot. That is what DCP defines: a closed set of 8 project-coordination entities (Project, Task, Dependency, ArchitectureImpact, Decision, ReviewRequest, Finding, Milestone) carried inside a thin DcpMessage envelope. Webhooks get you a reliable knock on the door; DCP is what makes sense of what is on the other side of it.

A webhook is how an event is delivered; DCP is what the event means.

Side-by-side

	DCP	Webhooks
Layer	Semantics — defines the meaning and structure of a coordination event	Delivery — defines how an HTTP callback reaches a receiver
What it defines	8 closed entity types, an `Event` (entity_type + verb + entity_id), and the `DcpMessage` envelope	An HTTP POST callback pattern; Standard Webhooks adds signing headers and retry conventions on top
Payload structure	Fully defined — 14 JSON Schemas describe every field	Deliberately undefined — the spec states it imposes no requirements on payload shape or content
Delivery, retry, signing	Not addressed — DCP has no transport of its own	Core concern — HMAC or ed25519 signing, timestamp-based replay protection, retry/backoff, 2xx/410/429 handling under Standard Webhooks
Trust and identity	None by design — a DCP message carries no trust and is treated as untrusted data by the receiver	Signature verification and timestamp checks establish that a given delivery came from the claimed sender
Transport coupling	None — a DCP message can be the body of an HTTP POST, a queue message, or a mesh frame	Coupled to HTTP — the pattern is defined as an outbound HTTP callback
Relationship	Complementary — a natural payload for a webhook body	Complementary — a natural delivery mechanism for a DCP message

Webhooks, plain or Standard, are a community-driven convention rather than a body-governed standard in the CNCF or W3C sense — there is no formal steering body ratifying “webhooks” the way there is for some adjacent specs. That is fine for what it does: it never claimed payload authority, so there is nothing to blur here. DCP does not compete for the delivery layer either; it has no retry logic, no signature scheme, and no opinion on HTTP at all.

Should my webhook payload be a DCP message?

Yes, if the event you are pushing is a project-coordination fact — a task completed, a decision was recorded, a review was requested, a dependency got blocked. Putting a DcpMessage in the webhook body gets you a payload that is validatable against a public schema, vendor-neutral, and parseable by any receiver that already understands DCP, instead of yet another bespoke JSON shape invented per integration. The webhook layer still does its job underneath: signing the request, retrying on failure, and proving the delivery came from who it claims. Neither layer needs to know the other exists.

If the event is not project coordination — a payment succeeded, a file finished uploading — DCP is the wrong vocabulary; its 8 entities are closed and coordination-specific on purpose. Read more on how DCP stays agnostic about the pipe it travels through in transport neutrality, and on why DCP never authenticates a sender in DCP carries no trust. The full envelope fields referenced above are documented in the envelope reference; a minimal worked example is in the quickstart. For how this same transport-vs-semantics split plays out against a formal envelope standard instead of a community delivery pattern, see the rest of the comparison hub.

By InterIP Networks · Last updated 2026-07-01.