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.
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_confirmedis altijdfalse; 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
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.