Integrations — Slack, Teams, CRM and your own endpoints
Send alerts and outcomes where your team already works. Every delivery is signed, and the signing key is shown once and never stored anywhere it can be read back.
- Alerts and digests land in the channel your team already reads
- Credential and readiness outcomes can flow into your CRM automatically
- Every delivery is signed, so your endpoint can prove the call came from us
- There is no stored credential to leak — the signing key is derived, not kept
Where monitoring sends what it finds
- Slack / Microsoft Teams — register the incoming-webhook URL as a delivery endpoint and point rules at it.
- HubSpot / Salesforce — subscribe an endpoint to credential events so contact records and partner tiers recalculate themselves.
- Your own systems — a data warehouse, an LMS mirror, anything that can receive an HTTPS POST.
The signing key is derived, not stored
When you register an endpoint we mint a random reference and derive the signing key from it using a master key held only in the server environment. The record keeps the reference; the key itself is never written down anywhere.
You see the key once, at creation. If you lose it, rotate — a new reference means a new key, shown once again. Your URL and event subscriptions are untouched.
That is why nothing on this page ever renders a secret back: there is genuinely nothing to render.
Settings fields are not for credentials
A provider card holds a channel name, a portal id, an instance URL — things anyone who can see the connection may see. A credential-shaped key or value anywhere in those settings is rejected before it is written, so a mis-paste fails at save time instead of becoming a readable column.
Delivery safety
| Guard | What it does |
|---|---|
| HTTPS only | Plaintext delivery of tenant telemetry is refused |
| Address check | Private, loopback and internal targets are refused — at registration and again at delivery, because DNS can change in between |
| No redirects | A 3xx is a failure, not a hop: your data is never forwarded to a URL nobody registered |
| Signed payloads | The timestamp is inside the signed material, so a captured delivery cannot be replayed later |
Connected has to be earned
Saving settings never claims a live connection. A provider shows as delivering only after a delivery succeeds, and flips to needs attention with the real error if one fails — so a silently broken integration cannot stay silent.
Frequently asked
How do I connect Slack or Teams?
Create an incoming webhook in Slack or Teams, then register that URL as a delivery endpoint here. The provider card holds only labels and the channel name; the URL is the credential, and it lives in the endpoint record where the platform is built to protect it.
Where is the signing key kept?
Nowhere. We store a random reference and derive the key from it with a master key that exists only in the server environment. The key is shown to you exactly once, when you create or rotate an endpoint. A database dump contains no signing key at all.
I lost the signing key. Can you send it again?
No — that is the point. Rotate the key on that endpoint and you get a new one, shown once. Rotation is instant and does not change the URL or the events you subscribed to.
Why can I not paste a token into a settings field?
Because a settings field is readable by everyone who can see the connection, so a credential does not belong in one. Credential-shaped keys and values are rejected before anything is written — the save fails loudly instead of leaving a token sitting in a column.
Why does a provider say 'Not delivering yet'?
Because a connection has to earn that status. Saving settings never claims a working connection; the card turns green only after a delivery actually succeeds. The card also tells you how many registered endpoints belong to that provider, so you can see whether anything is wired up at all.
How safe is an outbound call to my endpoint?
HTTPS only, never to a private, loopback or internal address, and the check runs both when you register the endpoint and again at delivery time — because your DNS can change between the two. Redirects are treated as a failure rather than followed, so tenant data is never posted to a URL nobody registered.
Which events can an endpoint subscribe to?
Any platform event — enrollments, lesson completions, quiz failures, exam results, integrity flags, journey completions, credentials issued/expiring/revoked, documentation drift, assistant answer gaps and seat thresholds. Subscribe to none and you receive all of them.
Who can manage this?
Owners and org admins only, because this screen decides where your telemetry is sent. Enablement managers can build rules that use an endpoint but cannot change the endpoints themselves. That restriction is enforced in the database, not just the interface.
Related guides
Rules notice inactivity, slipping due dates, expiring credentials and repeated quiz failures, then act. Every rule is configuration you can read and change.
ReadOne score per person, rolled up per team and per cohort, from learning done, proof earned and practice applied — with a one-click nudge for whoever is behind.
ReadRun your organization's people, teams, invitations and domains from one control plane.
Read