Notifications

Owners and admins configure workspace security email under Settings → Notifications, which has Recipients, Event delivery, Expected locations, and Data retention pages, plus Log destinations on Business. Notifications report activity; they do not allow or block a tool call. Every event, its default delivery mode, and the modes it accepts are listed below.

Send audit activity to a SIEM

On Business, direct workspace owners and admins can configure Settings → Notifications → Log destinations. Set up each workspace separately, including managed customer workspaces. A parent workspace's settings do not send its customers' audit activity automatically.

For Huntress, create an HTTP Event Collector source in Huntress, then:

Enter https://hec.huntress.io/services/collector as the destination.
Choose Huntress HEC and enter the source token.
Save the destination, enable delivery, and choose Send test event.
Find the test event in Huntress, then confirm that new workspace activity arrives.

Push delivery accepts approved HTTPS receivers. Huntress is the currently approved receiver; contact support before configuring another push receiver. A successful test means the receiver accepted the event. Check your SIEM separately to confirm that it indexed the event and that your detection rules work.

Other collectors can pull JSON events with a dedicated collector token created on the same page. Save the token when it appears; it is shown once. Use it as a bearer token with GET https://app.stackyapper.dev/api/audit-export/feed?after=CURSOR. For the first request, omit after. Process every event before saving next_cursor; follow has_more to retrieve additional pages. Poll once per minute normally, and never faster than once every five seconds. Rotating or revoking the token invalidates the previous credential.

Delivery starts with new audit activity after setup; it does not copy earlier history. Events contain workspace and actor IDs, action, outcome, and timing, without tool arguments, returned data, names, email addresses, or client IPs. Repeated delivery is possible, so deduplicate by event_id.

Check the saved destination's status if activity stops arriving. After repeated failures, repair the receiver or token and resume delivery. If audit retention removed events before they could be delivered, review and acknowledge the missing interval before resuming. A collector receiving HTTP 410 should stop and request that review; retained events can then be read using the response's expired_through value as the acknowledge_expired_through query parameter, keeping the existing after cursor. Expired events cannot be recovered through log delivery.

Recipients

Workspace owners and admins are always included. You can also add other email addresses that should receive security alerts.

Adding an address sends a confirmation email. The address receives no alerts and cannot receive a test until the recipient confirms it. Do not rely on an unconfirmed recipient.

Delivery modes

Immediate: send shortly after the event.
Daily: group matching events into the daily roll-up email.
Weekly: used only by the Monday security digest.
Off: do not send that event by email.

Not every mode applies to every event. Immediate and Daily apply to individual security events; Weekly applies only to the digest.

Security events

Event names match Settings → Notifications → Event delivery.

Event	Default mode	Allowed modes
Identity & access changed	Immediate	Immediate, Daily, Off
Admin role granted	Immediate	Immediate, Daily, Off
Destructive tool executed	Daily	Immediate, Daily, Off
Tool calls denied	Immediate	Immediate, Daily, Off
Access from a new country	Immediate	Immediate, Daily, Off
New network during a destructive call	Immediate	Immediate, Daily, Off
New network, known country	Daily	Immediate, Daily, Off
New AI client connected	Daily	Immediate, Daily, Off
Weekly security digest	Weekly	Weekly, Off

Events set to Daily are grouped into a daily roll-up email.

Destructive tool activity defaults to Daily to avoid alert fatigue in a busy write-enabled workspace; raise it to Immediate if your workspace runs few destructive operations.

Two events are listed under Events not available yet and do not send email:

Connector credential failure: credential-health changes are not yet connected to security email.
Failed sign-in burst: a rejected sign-in does not always identify a workspace safely, so Stackyapper does not guess which company to notify.

New-country and new-network alerts begin only after a member's AI clients have used at least one recorded network on ten separate days. This avoids treating a new workspace as an incident.

Weekly digest sections

The weekly security digest is sent on Mondays. Turning it Off stops the whole digest. The portal does not offer separate controls for individual sections. By default, the digest includes:

Section	Default
Needs you now	Included
Access changes	Included
Alert delivery	Included
New access	Included
Notable tool activity	Included
Denied and failed calls	Included
Dormant authorizations	Not included
Evidence	Included

Sections with nothing to report may be left out of a given week's email. The dormant-authorizations section is off by default because in a workspace's first weeks everything looks dormant.

Expected locations

Add the two-letter country codes where workspace members and AI clients are expected to connect. Access from a country that is not listed, and has not been seen before, can trigger an Access from a new country alert.

Expected locations affect alerts and summary context only. They do not restrict access, and they do not replace identity, workspace, or tool policy.

Client-address retention

Under Data retention, choose how much client-address detail is stored with audited calls:

Full address: the whole address, with the greatest forensic detail. This is the default.
Truncated address: an IPv4 /24 or IPv6 /48 prefix.
Do not store: no client address.

Country and network-operator alerts use the incoming connection, not the stored address, so they work with every setting. The New network during a destructive call alert compares the connection's /24 or /48 prefix with prefixes seen in recent audit history, so Do not store turns that one alert off. Choose a setting consistent with your organization's privacy and investigation requirements.

What an email contains

No Stackyapper email contains tool arguments, data returned by a connected app, provider credentials, API keys, or session tokens. Security email reports identifiers and counts, not the contents of a call.

An immediate alert contains the event title and its fixed summary line, the actor's name (or email address when no name is recorded), the event time, the country, the client address at your chosen retention level, the network operator, and a short set of event-specific facts — the change and what it applies to, a member's previous and new role, or the tool name, its risk level (such as destructive), and the self-reported AI client name. Denied-call alerts also include the reason, a suggested next step, and the account email. Each alert closes with links to Audit and to notification settings, both of which require sign-in.

Times are shown in the time zone set for each recipient under Recipients, or in UTC when none is set.

The daily roll-up lists up to 25 events per workspace with their time, user, AI client, activity, tool, risk level, country and network, and occurrence count, plus a link to Audit; any further events are summarized as counts. The weekly digest adds tool names with call, denial, and prior-week counts, new countries and network operators, and active-user and retention figures. Neither includes the contents of a call.

Other Stackyapper email

Email	Sent when
Workspace invitation	An owner or admin invites someone
Recipient confirmation	An address is added as a notification recipient
Test notification	An admin sends a test
Access request received	You request an approval-gated app
Access approved	A reviewer approves that request
AI client access request needs review	A member requests access to an AI client (sent to the routed reviewers)
Your AI client access request	An admin approves or blocks that request (sent to the requester)
Billing access notice	A paid subscription's payment is overdue: grace available, grace ending, paid access suspended, or access recovered (sent to workspace owners and the billing email)
Issue resolved	Actionable feedback you submitted through `stackyapper_feedback` has a verified resolution

Only the recipient-confirmation email carries a link that grants anything: a single-use link, valid for seven days, that confirms one address for one workspace. An invitation carries no token at all — the recipient signs in with their own Microsoft 365 or Google account, and their verified address must match the invited address and the workspace domain, so a forwarded invitation grants nothing.

Mail arrives from noreply@stackyapper.dev or support@stackyapper.dev. Allow both if your filtering quarantines unfamiliar senders. If a partner has set up its own email delivery for your workspace, such as its own SMTP server, some email can come from the partner's address instead. Invoices, receipts, and payment reminders come from Stripe, not from Stackyapper.

Verify a change

After changing notification settings:

Confirm the selected workspace.
Reopen the section and verify the saved delivery modes.
Send a test only to a confirmed recipient.
Review expected countries and retention separately; neither is an event delivery mode.

AI client approval requests

Under AI clients → Access rules → Request notifications, owners and admins can route requests to all workspace owners and admins or up to 10 selected ones, up to 10 verified custom emails, a webhook, or a combination. Add and verify a custom email under Settings → Notifications → Recipients before selecting it here.

Members submit their reason from the client connection screen. Notifications include that reason, the requester, the client name, and a link to review in the portal. Members cannot choose notification recipients. Admins choose whether their decision applies to the requester, a group, or the workspace. Existing deny rules still apply, and approval does not change app or tool access. After approval, the member reconnects from their AI client.

Webhook setup

Use a public HTTPS endpoint and a signing secret of 32–256 characters. Stackyapper stores the endpoint and secret encrypted and sends a JSON POST without following redirects. The payload includes version: 1, event: "ai_client.access_requested", requestId, revision, eventId, client, requester, justification, and reviewUrl.

Verify X-Stackyapper-Signature against the hex-encoded HMAC-SHA256 of X-Stackyapper-Timestamp + "." + rawRequestBody, using your signing secret. Reject stale timestamps and deduplicate eventId in your receiver. Each event ID combines the request ID and revision, so a reopened request has a new ID. The webhook contains no approval credential; decisions require an authenticated admin in the portal.

Delivery starts after submission. Throttled email stays queued for a bounded background sweep every 15 minutes; busy queues can take longer. Large admin lists are delivered in batches of up to 25. Webhook rate limits (HTTP 429) are retried no sooner than 15 minutes later, or later when the receiver provides a Retry-After value. A send whose outcome is uncertain is not automatically repeated. The portal request remains available even if a notification cannot be delivered.