What you can and cannot do
Part 1 — Announce decisions
Register a webhook subscribing to the decision events, then post each one to chat.Resolving names costs a lookup. The payload gives you
recipientId, not a name. Cache the directory from GET /api/public/v1/employees and refresh it daily rather than fetching per event.Part 2 — Surface pending work
For “what is waiting on me”, use the MCP server. An MCP key is bound to a specific employee and acts with exactly that person’s permissions and scope — so a manager’s bot sees their direct reports’ pending requests, and nobody else’s. Relevant tools:
And to act:
Setup and the full catalog are in the AI & MCP tab.
A reasonable architecture
Push for decisions — they are time-sensitive and low-volume. Pull for pending work — a morning digest beats a notification per request.Operating it
1
Monitor your own endpoint
The webhook flips to
Failing on the first failure, but the OnTime alert only fires after all eight retries — roughly 22 hours later.2
Deduplicate durably
The in-memory
Set above is illustrative. Restart it and you re-post events.3
Check notification preferences
Webhook delivery is gated by the organization’s notification preferences. If a category is switched off in Settings → Notifications, that webhook never fires — check there before the delivery log.
4
Replay from the delivery log
Failed deliveries are not lost. Fix the endpoint, then replay.