Skip to content
Engage

Documentation

Build with Engage

Connect customer data, business events, and communication channels to build automated journeys with workflows and AI.

Workspace alerts

Operational issues that need attention, separate from the customer events in Activity.

What appears here

Alerts include customers the AI assistant handed to a person, workflow messages that were refused, disconnected accounts, credentials expiring within seven days, and unprocessed inbound messages. Handoffs and workflow refusals are recorded when they happen. Other checks run approximately every five minutes.

A customer needs a person

When the assistant reads a message where somebody asks for a person, complains, is unhappy, or asks something it cannot answer from your catalog, facts and knowledge, it raises an alert that opens that conversation. The draft still waits in the inbox as before; the alert is so somebody knows to look. One alert per conversation per day: a second handoff in the same thread that day adds to its count instead of notifying again. The alert says which of those reasons it was, never what the customer wrote. Only while the assistant is on.

Conversation alerts show the customer's current name and phone number when available. Select the customer to open their profile, or Open conversation to reply in the inbox. Older alerts with a conversation link also show these details. Erased customers are labelled as erased; unavailable details do not prevent opening the conversation. Customer identity is loaded inside the dashboard and is not added to external alert notifications.

Read, unread and dismissed states are shared across the workspace. Dismissing an alert does not fix its cause. Use Review to open the relevant screen. Dismissed alerts remain available in the Dismissed or All view.

Estimated message rates

This warning means message cost records used an estimated provider rate rather than an imported rate card. It does not mean the message failed. View affected messages shows the linked message text, current customer number, send time, recorded delivery status and pricing region, with a link to the conversation when available.

The list covers cost records created from 24 hours before the alert first appeared through its latest occurrence. Numbers are current customer details, not historical delivery-address snapshots. Deleted or unlinked messages may have no available text or number; erased customer details and redacted content are not shown. Team notification status describes the operational alert sent to your team, not these customer messages.

Repeated issues

The Alerts badge in desktop navigation and the mobile header counts unread, undismissed alert groups, not individual occurrences. It refreshes approximately every 30 seconds while the tab is visible and after marking or dismissing an alert. Opening Alerts does not mark everything read. Counts above 99 display as 99+. Reading an alert affects the whole workspace; another occurrence in the same daily group does not make it unread again.

Workflow refusals are grouped by workflow and reason for each UTC calendar day. Each distinct run and step counts once, even if an event is redelivered. Repeated refusals update the occurrence count without sending another notification for that group. Account checks produce at most one alert per issue and resource each day. A continuing issue can appear again the next day.

Notification preferences

Only a workspace owner can change delivery preferences. The default is in-app only. Owners can opt into email or WhatsApp to a team recipient they are authorised to notify. In-app history remains available with either choice.

WhatsApp delivery uses the default WhatsApp account and an approved en_US template with exactly two body variables: {{1}} is the title and {{2}} is the detail. No media or additional variables are supplied.

Operational information leaves the workspace when you opt in

Notifications contain operational titles and details, including refusal reasons and connection warnings. They do not include access tokens or customer message bodies. Choose a trusted team recipient.

Delivery is queued for new alert groups after opting in; old in-app-only alerts are not sent retrospectively. Switching back to in-app only skips pending notifications. Delivery status means provider acceptance, not proof that a person read it.

Failed or interrupted delivery remains visible on the alert. Engage does not automatically retry an uncertain attempt, because the provider may already have accepted it. Changing preferences does not resend an existing alert.

API

These endpoints require a signed-in workspace member, not an API key. Preference endpoints require the owner role.

GET /v1/alerts?filter=active&page=0
GET /v1/alerts?filter=unread&page=0
GET /v1/alerts/unread-count
GET /v1/alerts/{id}/messages?page=0
PATCH /v1/alerts/{id}
{ "action": "read" }

GET /v1/alerts/preferences
PUT /v1/alerts/preferences
{ "delivery": "in_app", "recipient": "", "template": "" }

Filters are active, unread, dismissed and all. Pages contain 25 records; the response includes items, total, unread and page. State actions are read, unread, dismiss and restore. Email and WhatsApp delivery additionally require recipient; WhatsApp also requires template.

The messages endpoint is read-only and supports estimated-rate alerts only. Its response includes items, total, page, windowStart and windowEnd, with 25 cost records per page.

Current limits

Inbound-processing failures require support investigation and replay; the dashboard does not expose a replay control.

API keys currently have no expiration date, so key-expiry alerts are not generated. Historical alerts are not automatically resolved when their cause disappears. The latest occurrence time helps distinguish an old issue from a recurring one.

See Workflows for account routing and Instagram reply-window behaviour.