Exchange valt buiten deze API/CLI-release. Eventuele historische Exchange-voorbeelden in deze gids zijn niet beschikbaar; dit zegt niets over bestaande portaalfuncties. Zie het [actuele releasebereik](/developers/guides/release-scope?lang=nl).

# Beheermededelingen: portaal, API en Rust-CLI

Een interne beheerder kan een mededeling als platte tekst beoordelen en versturen naar actuele bedrijfscontacten of geverifieerde, niet-geblokkeerde menselijke gebruikers. Gebruik je eigen beheerbedrijfscontext en actuele passkey-authenticatie. Dit logt niet in als klant, wijzigt geen e-mailadres en onthult geen herstellink.

## Eerst beoordelen

`POST /api/v1/accounts/{operator}/admin/announcements/companies/review` of `/users/review` accepteert `subject`, `body` en optioneel `ids` (moderne bedrijfs-/gebruikers-ID's). Zonder ID's wordt de huidige toegestane doelgroep geselecteerd, met maximaal 1000 identiteiten per mededeling. Grotere doelgroepen moeten expliciet in groepen worden geselecteerd. Het antwoord bevat een nieuwe `intent_id`, `reviewed_at`, `review_version`, de exacte ontdubbelde e-mailontvangers en `recipient_count`.

Bedrijfscontacten moeten bij actieve, niet-geblokkeerde bedrijven horen. Gebruikersberichten gaan naar geverifieerde, niet-geblokkeerde identiteiten. Adressen worden gevalideerd en ontdubbeld, ook bij verschillen in hoofdletters. Alle identiteiten/versies achter een gedeeld adres blijven in de privébeoordeling bewaard. Het onderwerp weigert regeleinden voor e-mailheaders; de berichttekst is platte tekst, geen HTML. De beoordeling verloopt na tien minuten.

Het bestaande e-mailvenster voor bedrijven/gebruikers in het portaal gebruikt dezelfde beoordeling. Controleer de exacte adressen, het onderwerp en de berichttekst, verifieer met je passkey en bevestig een tweede keer. Het geselecteerde browserbedrijf moet gelijk blijven aan het bedrijf dat bij het tonen was vastgelegd.

## Eenmaal inplannen en het origineel controleren

`POST /api/v1/accounts/{operator}/admin/announcements/companies` (of `/users`) accepteert hetzelfde onderwerp, dezelfde berichttekst en ID's, plus `intent_id`, `reviewed_at`, `review_version` en `confirm_recipient_count`. Gebruik de gewone API-idempotentiesleutel. Een gewijzigde ontvanger, bedrijfsregel of berichttekst maakt de beoordeling vóór verzending ongeldig. Een exacte oorspronkelijke UUID kan niet opnieuw voor andere inhoud worden gebruikt.

Het antwoord betekent **ingepland**, niet afgeleverd. De begrensde verzender draait na het antwoord en controleert vóór iedere verzendpoging opnieuw de werkelijke oorspronkelijke beheerder, identiteitsgeneratie, actuele rechten, sterke authenticatie en exacte ontvangerversie. Hij gebruikt hetzelfde enkele beveiligde e-mailtransport als identiteitsmail van beheerders; logtransport en uitwijktransport worden geweigerd. Er wordt geen mogelijkheid voor wachtwoordherstel of accountinstelling aangemaakt of opgehaald.

`GET /api/v1/accounts/{operator}/admin/announcements/{companies|users}/{intent_id}` geeft veilige aantallen terug:

- `accepted_count`: het beveiligde transport heeft de indiening geaccepteerd; dit bewijst niet dat het bericht in de mailbox is afgeleverd.
- `unconfirmed_count`: er bestaat een blijvende verzendmarkering zonder bevestigde acceptatie. Bewaar dit origineel; het wordt nooit automatisch opnieuw verzonden.
- `not_started_count`: de verzender heeft deze ontvangers nog niet geprobeerd.
- `delivery_confirmed` is altijd `false`; SMTP-acceptatie kan aflevering niet aantonen.

Het eerste schrijfantwoord is een onveranderlijk bewijs van inplanning. Lees het origineel altijd met GET voor de actuele acceptatieaantallen. Hetzelfde verzoek opnieuw uitvoeren plant nooit nog een mededeling in en probeert een onzekere ontvanger niet opnieuw. Stopt de verzender of wordt het proces onderbroken, bewaar dan de oorspronkelijke UUID en onderzoek het bestaande transportbewijs. Deze release heeft geen automatische herhaling, vervanging of herverzending van onopgeloste mededelingen. Een actuele werkelijke oorspronkelijke beheerder met sterke authenticatie kan de status bekijken, ook wanneer API-schrijfacties uitstaan.

Het portaal bewaart de oorspronkelijke UUID vóór verzending in browseropslag per tabblad. Na een verloren antwoord of herladen leest het alleen de oorspronkelijke status. Een opslagfout stopt het indienen. Een afzonderlijke actie voor een nieuwe mededeling wordt pas aangeboden wanneer voor alle eerdere ontvangers transportacceptatie is bevestigd; daarvoor is een nieuwe expliciete beoordeling nodig.

## Rust-CLI

```sh
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
```

Vervang `companies` door `users` voor menselijke ontvangers. `message.json` bevat het onderwerp en de berichttekst als platte tekst en optioneel de geselecteerde ID's. Voeg de exacte beoordelingsvelden van de server en `confirm_recipient_count` toe om `reviewed-message.json` te maken. Bewaar de UUID en het oorspronkelijke lokale openstaande verzoek na iedere onbekende uitkomst. De verzendopdracht gebruikt één gebonden verzoeksleutel; beoordeling en status maken geen wijzigingsintentie of sleutel aan. Antwoorden worden strikt beperkt: de status toont aantallen en identificaties, nooit privésnapshots van ontvangers, berichtteksten of autorisatiebewijs.

Beoordeling/status vereisen actuele `admin:read`; versturen vereist `admin:write`, ingeschakelde API-beheer-/beveiligingsfuncties en ingeschakelde schrijfacties. Alle routes vereisen een werkelijke actuele interne beheerder met sterke authenticatie. Automatiseringsservicetoekenningen en browserondersteuningsdelegatie worden niet geaccepteerd. AI-agents mogen uit een geslaagd HTTP-antwoord geen aflevering afleiden, na een time-out niet opnieuw versturen en geen nieuw origineel verzinnen om een onopgelost bewijs te omzeilen.