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).

# Een oorspronkelijke operatie inspecteren na opnieuw verbinden

Bewaar vóór een wijziging het oorspronkelijke bedrijfsaccount, de publieke `principal_id` uit `GET /api/v1/me`, HTTP-methode, exacte API-pad, JSON-invoer, idempotentiesleutel en een eventueel teruggegeven operatie-ID. Een verlopen toegangstoken kan binnen de bestaande verbinding worden vernieuwd. Een nieuwe persoonlijke login maakt een andere API-identiteit en daarmee een andere naamruimte voor herhaling van wijzigingen. De oude wijziging via die nieuwe verbinding verzenden kan een tweede actie veroorzaken, zelfs met dezelfde sleutel.

Inspecteer na een onzekere respons de oorspronkelijke operatie. Dien de wijziging niet automatisch opnieuw in via een nieuwe verbinding en maak geen vervangende sleutel. Een mislukte of ontbrekende respons kan volgen op een geaccepteerde leveranciersaanvraag, afschrijving of e-mail. `failed` bewijst niet dat er geen effect was.

## Een lopende HTTP-aanvraag is geen afgeronde aanvraag

De API toont `operation.request_status` als de oorspronkelijke duurzame HTTP-aanvraagstatus: `running`, `succeeded` of `failed`. `operation.status` kan in plaats daarvan de levering van achtergrondtaken beschrijven. Een succesvol geaccepteerde bestelling kan `request_status: succeeded` hebben terwijl de levering `queued`, `running` of `awaiting_payment` is. Inspecteer of volg **dezelfde** operatie voor levering; maak geen vervangende bestelling alleen omdat inrichting nog loopt.

De Rust-CLI bewaart de oorspronkelijke automatische openstaande sleutel en eindigt met code `6` wanneer een wijziging HTTP `202`, een onvoltooide aanvraagstatus of een expliciete aanvraag-/facturatiebeoordelingsmarkering teruggeeft. Gedeeltelijke of gemengde HTTP-succesresponsen blijven ook vastgehouden. De CLI drukt in deze gevallen geen geslaagd resultaat af. De exacte opdracht herhalen onder dezelfde verbinding behoudt dezelfde sleutel; dit kan een nog lopende herhaling niet in een andere geaccepteerde wijziging veranderen. Alleen een later bevestigd aanvraagbewijs of de hieronder beschreven expliciete alleen-lezen bevestiging verwijdert die openstaande registratie. Een andere verbinding volgt nog steeds de onderstaande inspectieregels voor de oorspronkelijke identiteit en verstuurt de wijziging nooit automatisch opnieuw.

Wanneer `request_status` expliciet `succeeded` is, maakt een latere leveringsstatus `failed`, `requires_approval`, `requires_reconciliation`, `cancelled` of `cancelling` de geaccepteerde HTTP-aanvraag niet ongedaan. De CLI bewaart en toont de leveringsstatus; hij beweert niet dat de worker of leverancier klaar is. Inspecteer dezelfde oorspronkelijke operatie en gebruik de gedocumenteerde herstel- of annuleringsprocedure. Expliciete herstelvlaggen in het aanvraagresultaat houden de lokale openstaande sleutel nog steeds vast.

Voor oudere API-antwoorden zonder `request_status` blijft een definitief `succeeded`-bewijs of een geaccepteerd `queued`/`awaiting_payment`-bewijs op HTTP `200`/`201` ondersteund. Een dubbelzinnige oude status `running` blijft vastgehouden. Ongeldige ontvangstmetadata geeft eindcode `1` en behoudt ook de oorspronkelijke sleutel. Gecatalogiseerde alleen-lezen inspectieaanvragen mogen oorspronkelijke lopende metadata tonen; dit bevestigt of herhaalt de oorspronkelijke wijziging niet. Zulke inspecties maken geen nieuwe wijzigingssleutel of openstaande schrijfregistratie; laat `--idempotency-key` weg. Eenmalige e-mailbewijzen en beschermde levering van inloggegevens behouden hun afzonderlijke gedocumenteerde regels.

## Alleen-lezen herstel-API

`POST /api/v1/accounts/{account}/operations/original-receipt` zoekt uitsluitend via SQL één bewezen oorspronkelijke persoonlijke aanvraag op. Het verstuurt geen leveranciersaanvraag, maakt geen operatie aan en geeft geen historisch resultaat, geheim, betaal-URL, mailtoken of leveranciersfout terug. Een nieuwe idempotentiesleutel is niet nodig. `{account}` is het oorspronkelijke canonieke positieve numerieke bedrijfs-ID.

Gebruik een actuele persoonlijke verbinding van dezelfde persoon, hetzelfde bedrijf en dezelfde identiteitsbeveiligingsgeneratie. Nodig zijn `operations:read`, de actuele bevoegdheid en bedrijfsrol van de oorspronkelijke actie, onbeperkte resourcetoegang en recente passkey- of authenticatorverificatie onder het actuele bedrijfsbeleid. Beheeracties vereisen ook actuele beheerdersautorisatie en de beheerders-API-vlag. Een integratie of andere beheerder kan het bewijs van iemand anders niet overnemen. Nieuwe API-schrijfacties uitschakelen blokkeert deze alleen-lezen inspectie niet, mits de API en vereiste gevoelige voorbeeldbeoordeling beschikbaar zijn.

De JSON-body heeft exact deze structuur. De UUID en sleutel hieronder zijn fictief; gebruik de bewaarde oorspronkelijke waarden. Verstuur JSON via een beschermd invoerbestand of standaardinvoer. Zet geheimen nooit in opdrachtargumenten, URLs, gedeelde logs of chat.

```json
{
  "original_principal_id": "user:11111111-1111-4111-8111-111111111111",
  "original_key": "captured-original-idempotency-key",
  "request": {
    "method": "PATCH",
    "path": "/api/v1/accounts/42/admin/companies/83",
    "body": {"company_name": "Reviewed company name"}
  }
}
```

Geef dezelfde methode (`POST`, `PUT`, `PATCH` of `DELETE`), het canonieke volledige pad en het volledige oorspronkelijke JSON-object op. Behoud oorspronkelijke types, geneste velden, lege tekenreeksen en ondoorzichtige geheime bytes. Nieuw ingediende JSON-API-wijzigingen trimmen geen waarden en veranderen lege tekenreeksen niet in null. Queryparameters, gecodeerde padaliassen, bedrijfs-IDs met voorloopnullen en afsluitende schuine strepen worden voor nieuwe wijzigingen geweigerd. De oorspronkelijke aanvraagvingerafdruk gebruikt het bestaande gesleutelde canonieke JSON-algoritme; dit beweert niet dat historische `If-Match`-headers geverifieerd waren. De opzoekactie past hetzelfde normalisatiebeleid van het raamwerk toe als het oorspronkelijke eindpunt, zonder dat eindpunt uit te voeren.

Een oorspronkelijke aanvraag die een geheim verandert vereist de oorspronkelijke geheime invoer om met de gesleutelde vingerafdruk overeen te komen. De opzoekactie retourneert of bewaart die invoer niet. Ontbreekt de oorspronkelijke invoer, stop dan voor beoordeling door een medewerker; leid haar niet af en gebruik geen nieuw wachtwoord als herstelbewijs. Gewone API-bodies behouden hun limiet van 1 MiB. Het Book-afbeeldingseindpunt behoudt de bestaande JSON-limiet van 3 MiB, en deze opzoekactie staat een envelop van 4 MiB toe om die oorspronkelijke invoer met begrensde metadata te vervoeren.

Een geslaagde respons bevat `data: null`, het oorspronkelijke operatie-ID, bedrijf, actie, status en tijdstippen, plus deze bewijsvelden:

| Veld | Betekenis |
| --- | --- |
| `read_only` / `request_matched` | Deze opzoekactie is alleen-lezen en kwam overeen met de bewaarde oorspronkelijke aanvraag. |
| `original_request_succeeded` | De lokale oorspronkelijke HTTP-aanvraag is als geslaagd geregistreerd. |
| `requires_reconciliation` | De oorspronkelijke aanvraag is onvolledig, mislukt of expliciet voor beoordeling gemarkeerd. |
| `task_completion_asserted` | Altijd `false`; dit beweert niets over afronding door worker of leverancier. |
| `supplier_reads` / `supplier_mutations` | Altijd `false`. |

Een oorspronkelijke bestelling in de wachtrij kan een geslaagde HTTP-aanvraag hebben terwijl inrichting of facturatie nog beoordeling vereist. Blijf de oorspronkelijke taak-/bestellingsspecifieke status- en herstelprocedure gebruiken. Dit eindpunt keurt nooit taken opnieuw goed, herhaalt geen facturatie, verstuurt geen mail en wist geen leveranciersblokkade.

`404 original_receipt_unavailable` omvat ontbrekende historische herkomst, andere identiteit of generatie, afwijkende oorspronkelijke invoer en onleesbaar of gewijzigd bewijs. Bewaar de oorspronkelijke metadata voor onderzoek door een medewerker. Behandel 404 niet als toestemming om een actie te herhalen. Een `401`/`403` vereist herstel van de huidige authenticatie of autorisatie; het verandert de historische uitkomst niet. `503 operation_receipts_unavailable` betekent dat het ontvangstschema op de server moet worden geïnstalleerd. Een nieuwe wijziging wordt vóór uitvoering geweigerd als dit schema ontbreekt; bestaande herhaling met exact dezelfde sleutel en voorbeeldbeoordelingen blijven beschikbaar.

## Bewijs en releasegrens

Voor nieuw aangemaakte operaties legt de server versleutelde gegevens over de oorspronkelijke actor, identiteitsgeneratie, het bevoegdhedenplafond en de catalogusroute atomisch vast met de duurzame operatie, vóór uitvoering van de actie. Een gesleutelde binding omvat bedrijf, identiteit, operatie, oorspronkelijke sleutelhash, aanvraagvingerafdruk en daadwerkelijke bedrijfsactie. Oude operaties worden nooit stilzwijgend aangevuld met de identiteit van de huidige aanvrager. Het bewijs maakt willekeurige databaseterugdraaiing of volledige serverovername niet veilig.

De native Rust-CLI bewaart vóór verzending een permanente private binding voor elke wijzigingssleutel, ook een sleutel via `--idempotency-key`. Deze bindt het ingestelde eindpunt, exacte bedrijf, methode, pad en de geauthenticeerde publieke identiteit die met hetzelfde verzendtoken is opgehaald. Een vernieuwd token wordt tegen die oorspronkelijke identiteit gecontroleerd; een nieuwe login kan een oude sleutel niet stil overnemen. Een geslaagde aanvraag wist deze permanente sleutelbinding niet. Een serviceverbinding kan de persoonlijke herstel-API niet gebruiken.

Automatische openstaande aanvragen gebruiken een afzonderlijke private registratie met versienummer. Per profiel, eindpunt, methode en pad wordt slechts één onopgeloste automatische aanvraag gemaakt. Bestandsnaam noch inhoud bevat een samenvattingshash van wachtwoorden, DNS-waarden, private notities of andere aanvraagwaarden. Invoer wijzigen terwijl een oorspronkelijke aanvraag onopgelost is maakt geen vervangende sleutel: de server vereist nog steeds de exacte oorspronkelijke aanvraagvingerafdruk. Oude ongebonden openstaande registraties, ongeldige/verlopen registraties en gewijzigde private bestanden blijven vastgehouden voor beoordeling. Verwijder ze nooit alleen om een opdracht te laten doorgaan.

Gewone CLI-wijzigingen met een nieuwe persoonlijke verbinding inspecteren het oorspronkelijke bewijs en stoppen met eindcode `6`. Alleen gevalideerde oorspronkelijke metadata wordt op stderr beschreven; historische resultaten en leveranciersdetails worden niet afgedrukt. De automatische openstaande aanvraag blijft bestaan. Procedures met eigen beschermde beoordelingen, zoals registrarstappen en service-imports, behouden hun gedocumenteerde expliciete hersteleisen en verplaatsen hun oorspronkelijke wijziging nooit naar de nieuwe verbinding. Eenmalige exports van inloggegevens behouden ook hun oorspronkelijke leverings-/verbruiksjournaal; opnieuw verbinden verstrekt of verbruikt een geheim niet opnieuw.

### Een geslaagde automatische aanvraag expliciet bevestigen

Gebruik na beoordeling van de oorspronkelijke geslaagde HTTP-aanvraag de algemene opdracht `api` met de oorspronkelijke methode, het pad en beschermde JSON-invoer, plus de exacte oorspronkelijke operatie-UUID. Bijvoorbeeld:

```sh
binadit api /admin/companies/83 --method PATCH --account 42 \
  --from-file /private/original-request.json \
  --confirm-original-operation 33333333-3333-4333-8333-333333333333
```

Bedrijf, eindpunt en profiel moeten de bestaande automatische openstaande aanvraag selecteren. Dit voert uitsluitend de geauthenticeerde SQL-opzoekactie voor het bewijs uit. Alleen die ene automatische openstaande registratie wordt verwijderd wanneer de exacte oorspronkelijke UUID overeenkomt, de HTTP-aanvraag geslaagd is en geen herstel nodig is. De opdracht toont veilige oorspronkelijke metadata met `receipt.local_pending_resolved: true`, eindigt succesvol en stopt. Zij voert geen `--wait` uit, POST de oorspronkelijke actie niet, maakt geen nieuwe sleutel en beweert geen workerafronding. Voor deze alleen-lezen bevestiging is geen extra `--yes` nodig.

De bevestiging controleert de ingeschakelde **alleen-lezen mogelijkheid voor oorspronkelijke bewijzen**, zodat een onderhoudsvlag die nieuwe wijzigingen uitschakelt dit niet verhindert. Zonder de bevestigingsvlag houdt een uitgeschakelde oorspronkelijke wijzigingsmogelijkheid de gewone opdracht vast; gebruik de gedocumenteerde alleen-lezen inspectie of bevestiging in plaats van schrijven voor herstel aan te zetten.

De vlag wordt vóór netwerktoegang geweigerd bij getypeerde opdrachten, leesacties, login, voorbeeldbeoordelingen, aanvragen met expliciete sleutel, ongeldige UUIDs of een route zonder bestaande automatische openstaande aanvraag. Een mislukt, lopend, ontbrekend, vreemd of herstelvereisend bewijs wist de openstaande registratie nooit. Opnieuw bevestigen nadat de openstaande registratie is verwijderd wordt zonder verzoek geweigerd. De permanente oorspronkelijke sleutelbinding blijft bestaan.

Alleen voor deze bevestiging mag beschermde JSON-invoer tot 3 MiB groot zijn zodat de oorspronkelijke Book-afbeeldingsaanvraag in de serveropzoekenvelop van 4 MiB past. Normale algemene JSON-invoer blijft beperkt tot 1 MiB. Behoud oorspronkelijke ondoorzichtige bytes en types. Ontbreekt de oorspronkelijke invoer, gebruik dan beoordeling door een medewerker in plaats van vervangende invoer te verzinnen.

**Stop na bevestiging.** Een latere gewone aanroep kan een bewuste nieuwe wijziging uitdrukken en een nieuwe automatische sleutel maken; voer haar niet als herstelherhaling uit. Bij een expliciete idempotentiesleutel verhindert de permanente oorspronkelijke identiteitsbinding dat de sleutel via een nieuwe verbinding wordt ingediend, zelfs na eerder succes. Publieke verspreiding van uitvoerbare bestanden vereist nog steeds de volledige Rust-pariteits-/beveiligingsreleasecontrole en productie-uitrolcontroles.

## Afspraken voor gebruikers en AI-agents

1. Bewaar de oorspronkelijke identiteit en intentie vóór de eerste wijziging; houd geheime invoer privé.
2. Inspecteer de oorspronkelijke operatie na onzekerheid. Vernieuw zo mogelijk dezelfde verbinding.
3. Gebruik na een nieuwe login uitsluitend het geverifieerde oorspronkelijke bewijs of de gedocumenteerde servicespecifieke alleen-lezen herstelprocedure. POST de oorspronkelijke wijziging niet als proef.
4. Behandel mislukte, lopende, ontbrekende of herstelvereisende uitkomsten als onopgelost. Maak nooit een vervangende bestelling en leid niet af dat er geen afschrijving, mail of leverancierswijziging was.
5. Behandel een geslaagd bewijs als aanvraagmetadata. Bevestig daadwerkelijke taak-, facturatie- of serviceafronding via de oorspronkelijke procedure voordat je voltooiing meldt.

Volg voor bevoegdheidsmail de [regels voor teamuitnodigingen](/developers/guides/team-invitations?lang=nl). Registrarstappen hebben een afzonderlijk [oorspronkelijk stapbewijs](/developers/guides/registrar-administration?lang=nl); de uitvoerings-UUID en het beoordelingscontract blijven vereist.

## Expliciete toepassing van Workspace-DNS

`POST /api/v1/accounts/{account}/workspaces/{workspace}/domains/{domain}/actions/apply-dns` vereist de huidige `If-Match` van het domein, `workspace:write` en de normale oorspronkelijke aanvraagsleutel. Het plaatst nu een oorspronkelijke DNS-only taak in de wachtrij: de respons bevat `delivery_status: queued` en `task_ids`. Een geslaagd HTTP-bewijs bevestigt dat de taak is opgeslagen; het betekent niet dat de leverancier al is gewijzigd.

De goedkeuring bevriest de volledige huidige portalzoneprojectie, het werkelijke bedrijf, domein en de Workspace-/mail-/Drive-/Conserio-serverversies, leveranciersbron en oorspronkelijk HTTP-bewijs. Niet-gerelateerde DNS-records, letterlijke TXT-bytes, SPF-mechanismen van de klant en TTL-beleid blijven behouden. De worker gebruikt het canonieke DNS-journaal en de historie van het portaal, buiten SQL-transacties. Vóór elke leveranciersaanvraag controleert hij opnieuw de actuele rechten van de oorspronkelijke verbinding. Een zone of serviceconfiguratie wijzigen vervangt deze beoordeling niet stilzwijgend.

De bestaande getypeerde CLI-opdracht gebruikt hetzelfde API-contract:

```sh
binadit workspace domains actions run 8 apply-dns --workspace 4 --account 123 --version DOMAIN_ETAG --dry-run
```

Vervang na beoordeling van het huidige domein en de beoogde records `--dry-run` door `--yes` om de daadwerkelijke oorspronkelijke taak te plannen. Een voorbeeldbeoordeling maakt geen taak of wijzigingssleutel.

Bewaar de oorspronkelijke operatie- en taak-IDs. Inspecteer de bestaande operatie-/taakstatus; een onopgeloste of mislukte domeintaak blokkeert een vervangend verzoek, ook met een nieuwe sleutel. Een verloren leveranciersantwoord behoudt het oorspronkelijke journaal en wordt tegen die oorspronkelijke intentie hersteld; het rechtvaardigt nooit een tweede PATCH. Intrekking, gewijzigd eigendom, onleesbaar oorspronkelijk bewijs of een onbekende uitkomst vereist de gedocumenteerde oorspronkelijke taakbeoordeling/hergoedkeuring. Verwijder geen taak en maak geen andere intentie om de blokkade te omzeilen.

Het bovenstaande API-contract omvat de expliciete DNS-only actie. Automatische native domeininrichting en doorlopend onderhoud vereisen hun eigen beoordeelde servicedoelautorisatie; oudere niet-toegeschreven taken worden niet stilzwijgend door deze actie overgenomen.

### DNS-knoppen in het portaal

De Workspace-DNS-instellingen tonen huidige en vereiste waarden met een status per vereist record, ook bij een lege oude DNS-cache. Met actuele DNS-rechten kun je **Record herstellen** of **Alle records herstellen** kiezen. De laatste actie herstelt ontbrekende en conflicterende vereiste records en behoudt overige records. De getoonde vergelijking is de beoordeling; normaal opslaan voegt geen aparte bevestigingspagina of herhaalde passkeycontrole toe binnen een geldige browsersessie die al met een passkey met gebruikersverificatie of een authenticator is aangemeld. Recordwaarden worden door de server bepaald; formulieren kunnen geen willekeurige DNS-namen, waarden of zone van een ander bedrijf indienen. Demoklanten kunnen het door Binadit beheerde domein bekijken, maar niet wijzigen; alleen een momenteel bevoegde platformbeheerder kan het herstellen. `GET .../domains/{domain}/dns-status` en `binadit workspace domains dns status` tonen ook de alleen-lezen `records`-lijst (`name`, `type`, `current`, `expected`, `status`). De status is `ok`, `missing` of `mismatch`; het opvragen verleent geen schrijfrechten.

De browser bewaart één oorspronkelijke UUID voor de huidige persoon, identiteitsgeneratie, het bedrijf, Workspace en domein. Een verloren respons behoudt deze UUID en oorspronkelijke beoordelingsversies. Achtergrondcontroles inspecteren alleen SQL-taak-/journaalstatus; ze versturen nooit een vervangende POST of leveranciersaanvraag. Een andere recordkeuze blijft geblokkeerd zolang het origineel onopgelost is. Een verouderde beoordeling kan `preparation_rejected: true` teruggeven met een ondertekende, geannuleerde oorspronkelijke taak die niet kan worden uitgevoerd; alleen dit exacte definitieve bewijs of een geverifieerd afgerond DNS-journaal verwijdert de browsermarkering. Een ontbrekende taak of mislukte statusaanvraag bewijst nooit dat geen wijziging plaatsvond. Herlaad de pagina na een geweigerde beoordeling.

Verlopen menselijke goedkeuring houdt de oorspronkelijke taak vast. Vernieuw haar expliciet via de oorspronkelijke taakgoedkeuringskaart in het portaal of de bestaande CLI-koppeling:

De volledige DNS-vergelijking en de getypeerde doeleinden `workspace-create` en `conserio-set` vereisen CLI `0.1.0-preview.20261104.1` of nieuwer. Werk een oudere CLI bij via de [downloadpagina](/developers/cli?lang=nl).

De getypeerde opdrachten accepteren ook de doeleinden `workspace-create` en `conserio-set` uit de huidige Workspace-/domeinbrug. Ze behouden de exacte oorspronkelijke Workspace, het doelbedrijf, onderwerp en de intentie. Dit voegt geen onderwerpen voor gedeelde mailboxen of samenwerking aan die brug toe; gebruik daarvoor hun eigen procedures. Onbekende doeleinden blijven geweigerd.

```sh
binadit workspace portal-approvals get WORKSPACE ORIGINAL_UUID --account ACCOUNT
binadit workspace portal-approvals reapprove WORKSPACE ORIGINAL_UUID --account ACCOUNT --version WORKSPACE_ETAG --confirm-workspace WORKSPACE --target-account ACCOUNT --yes
```

De actie is `domain-dns`. Hergoedkeuring behoudt de oorspronkelijke taak, goedgekeurde records, bron, journaal en actor. API-vernieuwing voegt een echte intrekbare persoonlijke verbinding toe; intrekken daarvan stopt volgende leveranciersaanvragen. Onafhankelijke ondertekende DNS-only taken voor andere domeinen kunnen vastgehouden blijven: één origineel vernieuwen onthult, vernieuwt of verstuurt die taken niet. Andere beperkingen voor Workspace-onderhoud en facturatiegroepering blijven gelden. Wisselen van bedrijfscontext vereist herladen van de beoordeling; een formulier weergegeven voor een ander bedrijf wordt vóór aanmaak geweigerd.

DNS-taakafronding bevestigt publicatie van de goedgekeurde records. Domeinaanmelding, certificaatuitgifte, mailoverschakeling en automatisch doorlopend onderhoud blijven afzonderlijke procedures; deze actie keurt ze niet stil goed. Agents moeten het definitieve bewijs van de oorspronkelijke taak inspecteren en alle onopgeloste originelen behouden in plaats van browseropslag te wissen of een andere UUID te maken.

SQL-only inspectie van een oorspronkelijke browsergoedkeuring blijft beschikbaar voor dezelfde sterk geverifieerde persoon via een nieuw verbonden persoonlijk alleen-lezen token wanneer nieuwe API-schrijfacties uitstaan, mits die persoon nog de oorspronkelijke schrijfbevoegdheid heeft. Dit vernieuwt geen taak en verleent geen leveranciersbevoegdheid. De gevoelige API-functie moet voor inspectie ingeschakeld blijven; expliciet uitschakelen blokkeert inspectie én vernieuwing. Vernieuwing vereist altijd een actuele verbinding waarop schrijven is ingeschakeld.

Wanneer API-schrijven uitstaat, laat OAuth uitgeschakelde schrijfbevoegdheden bewust weg uit een nieuw uitgegeven verbinding. SQL-only inspectie van het oorspronkelijke bewijs werkt nog met `operations:read`, actuele sterke verificatie, dezelfde oorspronkelijke persoon/bedrijf/identiteitsgeneratie, het geverifieerde oorspronkelijke bevoegdhedenplafond en de huidige native schrijfbevoegdheden van die persoon. Deze onderhoudsuitzondering voegt geen bevoegdheid aan het nieuwe token toe en autoriseert geen actie. Met schrijven ingeschakeld moet de actuele verbinding nog steeds de bevoegdheid van de oorspronkelijke actie bevatten.