Exchange is excluded from this API/CLI release. Any historical Exchange API or CLI example in this guide is unavailable; native portal behavior is outside this exclusion. See current release scope.
Administrative announcements: portal, API and Rust CLI
An internal administrator can review and send a plain-text announcement to current company contacts or verified, unblocked human users. Use your own administrative company context and current passkey authentication. This does not sign in as a customer, change an email address or reveal a recovery link.
Review first
POST /api/v1/accounts/{operator}/admin/announcements/companies/review or /users/review accepts subject, body, and optional ids (modern company/user IDs). Without IDs it selects the current eligible audience, with a maximum of 1000 identities per announcement. Larger audiences must be explicitly selected in batches. The response includes a new intent_id, reviewed_at, review_version, exact deduplicated email recipients and recipient_count.
Company contacts must belong to active, unblocked companies. User messages go to verified, unblocked identities. Addresses are validated and deduplicated, including case variants. Every identity/version behind a shared address is retained in the private review. The subject rejects header line breaks; the body is plain text, not HTML. The review expires after ten minutes.
The portal's existing company/user mail dialog uses this same review. Inspect the exact addresses, subject and body, verify with your passkey and confirm a second time. The selected browser company must remain the rendered company.
Queue once and inspect the original
POST /api/v1/accounts/{operator}/admin/announcements/companies (or /users) takes the same subject, body and IDs, plus intent_id, reviewed_at, review_version and confirm_recipient_count. Use the ordinary API idempotency key. A changed recipient, company policy or message invalidates the review before sending. An exact original UUID cannot be reused for different content.
The response means queued, not delivered. The bounded sender runs after the response and rechecks the actual original administrator, identity generation, current permissions, strong authentication and exact recipient version before every transport attempt. It uses the same single secure mail transport as administrative identity mail; log/failover transports are refused. No password-reset/setup capability is created or retrieved.
GET /api/v1/accounts/{operator}/admin/announcements/{companies|users}/{intent_id} returns safe counts:
accepted_count: the secure transport accepted the submission; this is not proof of delivery to the mailbox.unconfirmed_count: a durable dispatch marker exists without a confirmed acceptance. Preserve this original; it is never automatically resent.not_started_count: the sender has not attempted these recipients.delivery_confirmedis alwaysfalse; SMTP acceptance cannot establish delivery.
The first write response is an immutable queue receipt. Always GET the original for current acceptance counts. Repeating the same request never queues another announcement or retries an uncertain recipient. If the sender stops or the process is interrupted, keep the original UUID and investigate the existing transport receipt. This release has no automatic retry, replacement or resend of unresolved announcements. A current real strongly authenticated original administrator can inspect the status even with API writes disabled.
The portal keeps the original UUID in per-tab browser storage before sending. After a lost reply or reload, it reads only the original status. Storage failures stop submission. A separate new-announcement action is offered only after all prior recipients have confirmed transport acceptance; it requires another explicit review.
Rust CLI
binadit admin announcements companies review --input message.json
binadit admin announcements companies send --input reviewed-message.json --yes
binadit admin announcements companies get ORIGINAL_UUID
Replace companies with users for human recipients. message.json contains the plain-text subject/body and optional selected IDs. Add the server's exact review fields and confirm_recipient_count to create reviewed-message.json. Keep the UUID and original local pending request after any unknown result. The send command uses one bound request key; review and status allocate no mutation intent or key. Responses are strictly projected: status exposes counts and identifiers, never private recipient snapshots, message bodies or authority evidence.
Review/status need current admin:read; send requires admin:write, API administration/sensitive controls and writes enabled. All routes require a real current strongly authenticated internal administrator. Automation service grants and browser support delegation are not accepted. AI agents must not infer delivery from a successful HTTP response, resend after a timeout or fabricate a new original to bypass an unresolved receipt.