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.

Teamuitnodigingen: bevoegdheid, bezorging en herstel

Inloggen in het portaal werkt voortaan uitsluitend met passkeys. Bestaande wachtwoordgebruikers en nieuwe klanten starten met een e-maillink en maken hun eerste passkey aan voordat ze toegang krijgen. Zie instellen, overstappen en herstel. Browser-OAuth gebruikt dezelfde login; rechten en scopes blijven gelden.

Bedrijfs- en teaminstellingen kunnen wachtwoordlogin niet opnieuw inschakelen. Passkeys zijn voor iedereen verplicht; een geverifieerde passkey voldoet aan de eerdere eis voor het instellen van MFA.

Het portaal en POST /api/v1/accounts/{account}/team/invitations maken ledenuitnodigingen via hetzelfde bedrijfsrechtenbeleid. API-aanvragers hebben team:write nodig en actuele menselijke toestemming met recente sterke verificatie. Het portaal gebruikt het actuele bedrijf, de browseridentiteit en bestaande passkey- of authenticatorverificatie. Een serviceverbinding kan deze bevoegdheid niet verstrekken.

POST /api/v1/accounts/{account}/team/invitations/{id}/resend vervangt het acceptatietoken van een bestaande openstaande uitnodiging. De knop voor opnieuw versturen in het portaal gebruikt hetzelfde beleid. Bij aanmaak kan geen eigenaarsrol worden aangevraagd. Een eerder opgeslagen eigenaarsuitnodiging, inclusief een oude registratie met permissions: null, kan alleen door een actuele eigenaar van dat bedrijf opnieuw worden verstuurd of ingetrokken. role: owner zien in een leesrespons geeft geen bevoegdheid om erop te handelen. Een gedelegeerde teambeheerder kan een normaal lid alleen binnen de eigen actuele modulerechten uitnodigen of opnieuw uitnodigen; leesrecht kan geen schrijfrecht worden.

Het uitnodigingstoken is een private bevoegdheid. API-antwoorden voor lijsten, aanmaken en opnieuw versturen en auditmetadata geven dit nooit terug. Acceptatie gebeurt via de expliciete browserprocedure in de e-mail van de ontvanger. Links gebruiken de ingestelde canonieke portaaloorsprong, onafhankelijk van de binnenkomende Host van het verzoek.

Voordat een token wordt aangemaakt of vervangen, vereist bezorging één ingesteld SMTP- of sendmailtransport dat veilig met inloggegevens omgaat. SMTP vereist TLS en certificaatcontrole. Log-, terugval- en roulerende transporten worden geweigerd. Een globale ontvanger voor maildiagnostiek kan de uitnodiging niet omleiden. Alleen de exacte uitnodigingsontvanger krijgt het bericht; CC- en BCC-ontvangers worden geweigerd.

De server houdt de oorspronkelijke actor, authenticatiegeneratie, het bedrijf, de uitnodigingsinhoud en transportbron tijdens bezorging gebonden. Na het weergeven van het bericht controleert hij opnieuw de actuele bedrijfsstatus, het lidmaatschap, het delegatieplafond, de uitnodigingsstatus, de oorspronkelijke API-toestemming of browsersessie en het sterke-authenticatiebeleid. De laatste tijdscontrole loopt na die beleidslezingen en direct voordat het bericht aan het onderhouden mailtransport wordt overgedragen. Verlopen verificatie geeft de bestaande verificatiehulp van het portaal. Gewijzigde of ingetrokken bevoegdheid voorkomt bezorging.

De uitnodiging en de oorspronkelijke API-operatie worden vóór SMTP-verzending vastgelegd. Een succesvolle synchrone respons bevestigt transportacceptatie, geen bezorging in de inbox. De API bewaart het uitnodigings-ID en een markering voor onbevestigde mail als verzending niet bevestigd is. Een SMTP-time-out of verloren bevestiging kan betekenen dat de ontvanger de e-mail al heeft ontvangen. De server probeert niet automatisch opnieuw en valt niet terug op een ander transport; de respons gebruikt invitation_delivery_unconfirmed zonder ruwe SMTP- of diagnostische details.

Voor gebruikers en AI-agents na een onzekere uitkomst:

1. Bewaar het oorspronkelijke bedrijf, numerieke uitnodigings-ID en API-operatie-ID of idempotentiesleutel. Lees de oorspronkelijke operatie en uitnodigingslijst; verzin geen vervangende operatie en beweer geen inboxbezorging.
2. Een API-aanvraag herhalen met de oorspronkelijke mislukte sleutel verstuurt geen tweede e-mail. Een openstaande uitnodiging hoort nog bij het oorspronkelijke bedrijf en de ontvanger.
3. Is na beoordeling een nieuwe bezorging nodig, gebruik dan de expliciete actie voor opnieuw versturen met actuele bevoegdheid en recente verificatie. Die vervangt de oude acceptatielink. Een gedelegeerd lid kan nog steeds geen oude eigenaarsuitnodiging opnieuw versturen.

TeamInvitationDeliverySecurityTest controleert portaal- en API-paden met opgevangen mail, daadwerkelijk weergegeven berichten en een private lokale TLS-SMTP-ontvanger. De tests behandelen grenzen voor delegatie en oude eigenaars, intrekking tijdens weergave, wijzigingen van generatie/sessie/toestemming/bevoegdheden, verval, wijzigingen van ontvanger/token/bron, verboden transporten, exacte ontvangers ondanks diagnostische instellingen en verloren SMTP-bevestigingen zonder automatische tweede bezorging. Deze tests versturen geen klantmail en veranderen geen systeemvertrouwen in certificaten.