Interfaces
Webhooks
React to what happens in DigitalStack instead of polling for it. Time Management, Work Items, and Work Item Enhance events are available now; other event families are staged by domain.
Available for promoted capability events
A separate, narrower mechanism exists internally
When to reach for webhooks
Webhooks are the right choice when you need to react to a canonical change in near real time and would otherwise poll the REST API on an interval. Time Management, Work Items, and Work Item Enhance are available today; other capability families remain REST/MCP-first until their event contracts ship.
Fetch current state with REST
- • You need current state right now, on your own schedule
- • You're building automation that checks periodically
Ask with MCP
- • An AI client needs a grounded, on-demand answer
- • You don't need continuous, real-time notification
What's available
Event-driven, not polling
Instead of repeatedly asking the REST API "did anything change?", your endpoint is notified the moment something does.
Signed payloads
Every delivery is HMAC-signed so a receiver can verify it genuinely came from DigitalStack.
Reliable delivery
Automatic retries, delivery logs, test deliveries, and governed redelivery are available on the durable delivery path.
A typed event catalog
A versioned catalog of event names and payload shapes exists in code today — see which are real product signals, and which are still just types.
Subsystem status
Availability is tracked by subsystem because the transport is shared while event families ship one capability at a time.
Whether a real product action actually produces a webhook event.
• Available for Time Management, canonical Work Items, Work Item Enhance, Today & My Work attention-item action events, Project Health alert acknowledgement events, Projects & Engagements, Milestones & Workstreams, Sprints & Planning, Context Engine evolution, and Estimates, Effort & Scope events. Document/workflow and other capability families remain planned until their own emission points are promoted.
A defined, typed list of event names a subscription can select.
• Time Management, Work Items, Work Item Enhance, Today & My Work attention-item events, Project Health alert acknowledgement events, Projects & Engagements, Milestones & Workstreams, Sprints & Planning, Context Engine evolution, and Estimates, Effort & Scope events are available. The four document/workflow contract events remain planned.
Registering a new webhook endpoint and selecting the events it should receive.
• Both session and API-key/OAuth callers can create a subscription; an API key or delegated token must hold `webhooks:manage` and is bound to its own workspace regardless of the credential owner's other memberships. Session users can also use the in-product page at /app/developer/webhooks.
Listing, updating, disabling, or deleting an existing webhook subscription.
• Same authorization model as subscription creation: `webhooks:manage`-scoped API-key/OAuth callers and session users can both list, update, and delete, each bound to their own workspace. The in-product page covers the session path; API-key/OAuth callers use the routes directly.
Actually POSTing an event payload to a subscriber's endpoint.
• Available on the durable outbox delivery path for promoted event families. Older pre-activation events are held behind the activation watermark unless redelivered explicitly.
Automatic re-attempts with backoff when a delivery fails.
• Initial deliveries use the standard durable retry path. Synthetic test deliveries intentionally do one attempt only.
HMAC-signing a payload so a receiver can verify it genuinely came from DigitalStack.
• The v1 signing contract is frozen, unit-tested with deterministic cross-language vectors, and used by the outbox delivery path.
A record of each delivery attempt — status, response code, timing — you can inspect.
• Delivery jobs and attempts record event id, delivery kind, attempt count, status, latency, response code, and sanitized response snippets.
Manually re-triggering a failed or past delivery.
• A governed redelivery endpoint enqueues a new delivery job for the original subscription, preserves the immutable event payload, and audits the request without storing the raw idempotency key.
The webhook signing secret is encrypted at rest (AES-256-GCM, a versioned key, bound to the subscription and workspace), shown once at creation, and never retrievable afterward.
Rejecting unsafe webhook target URLs — non-HTTPS, private, loopback, or cloud-metadata addresses.
• Registration and every delivery attempt run a shared DNS-resolving guard. Connection-level IP pinning is still a future hardening item, so receivers should still treat public endpoints as internet-facing.
Regenerating a webhook's signing secret via a distinct, audited action, with a 24-hour dual-sign overlap so a receiver can migrate without downtime.
Events scoped to a specific DigitalStack capability.
• Time Management, Work Items & Board, Work Item Enhance, Today & My Work, Project Health, Projects & Engagements, Milestones & Workstreams, Sprints & Planning, Context Engine, and Estimates, Effort & Scope are available. Risk and portfolio event families remain planned.
The in-product page at /app/developer/webhooks: create and edit subscriptions with a grouped event picker, archive with confirmation, rotate signing secrets, send test deliveries, and inspect delivery history down to individual attempts.
• Session-authenticated only — API-key and OAuth integrations manage subscriptions through the routes, not this page.