Use the inspection helper to see email history and recorded message content. It needs both people:read and emails:read on BARUA_MANAGEMENT_KEY. Start with the installed skill.
Find an email
For an email generated from a custom service event, start with the event's delivery status below. Its returned draft ID can then locate the same message in email history.
node "$BARUA_SKILL/scripts/inspect.mjs" emails --limit 20
Success returns one page of email records and next. When next is non-null, pass its value to --cursor and keep the same filters. Optional filters include --person-id, --play-id and --status; the inspection reference lists the complete contract.
Use a returned UUID to inspect the record:
node "$BARUA_SKILL/scripts/inspect.mjs" email --id "$EMAIL_ID"
Read the recorded state and content availability. Provider acceptance is not proof of inbox delivery. Legacy draft records may lack the send-time recipient snapshot; report that limitation instead of reconstructing an exact recipient from today's profile.
Save a preview
node "$BARUA_SKILL/scripts/inspect.mjs" email-preview \
--id "$EMAIL_ID" --output-file "$PRIVATE_PREVIEW_FILE"
Choose a new output path in a private directory. The helper writes a restricted file and refuses to overwrite an existing one. Inside a Git repository, the output path must be ignored. Keep customer content out of shared logs.
The preview returns inert HTML or text with a restrictive policy. email-raw saves the original payload; treat that content as untrusted and do not open it as a safe preview. Neither command sends email.
Preview before sending
For a Play draft, use play-preview with its revision and step inputs. For profile-based rendering, use profile-preview with a private JSON file. Follow the preview contract for the required body and permissions.
If an expected message is missing, inspect workspace diagnostics and the Play run. Do not send another email merely to check whether the first succeeded.
Custom service emails
A product supplies the complete message in its original language, with required plain text and no model call. Each event and recipient gets its own delivery. Optional HTML supports tables, inline styles, HTTPS links and a static logo or light/dark pair. The service contract defines bounded theme rules; arbitrary CSS is refused. Deploy API and delivery support before using them. Client support varies. Link fragments stay unchanged. Barua never fetches these URLs; clients may fetch logos. Producers own asset privacy, availability and link access.
Approve the custom event in the tracking plan, then configure its service
purpose with the management action service-event.configure. Inspect saved
policies with:
node "$BARUA_SKILL/scripts/manage.mjs" service-events
This read requires play:write. Follow its next cursor with --after.
The policy action needs an exact version and follows the connection's Play
review setting. The backend key needs explicit events:write and
service:write; existing keys do not acquire the new permission automatically.
Send the full message in the event's service_email field. Read the
service email contract for the exact request,
content limits and permissions. A successful event receipt means Barua accepted
the event for processing. Follow that receipt, then read
GET /api/integrations/v1/service-events/{URL-encoded-event_id} with the same key.
queued, held and drafted mean the message is waiting. accepted confirms
provider acceptance; delivered requires a provider delivery report. A failed
or cancelled message needs investigation. unconfirmed means a send may have
happened, so creating a replacement risks a duplicate. The status response
contains no recipient address or message content.
Test events create no emails. Workspace pause also disables service policies; explicitly configure the policy again to restart it. The regular sender checks still apply, including suppression and the current recipient identity.