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). # Filterinstellingen, MX-records en herstel Deze handleiding beschrijft bestaande filters: SMTP-bestemmingen en eigen aliassen wijzigen, opgeslagen MX-records terugzetten en betaalde producten op de bestaande abonnementsovereenkomst wijzigen en filters verwijderen. Controleer de actuele capabilities van het gekozen bedrijf. Beschikbaarheid volgt de rechten en instellingen van de omgeving. ## Vanuit het portaal Het bestaande formulier **Filter bewerken** gebruikt dezelfde oorspronkelijke leveranciers-, MX- en prijsstappen. Verifieer je identiteit met de aangeboden passkey of verificatiecode, controleer de instellingen en sla één keer op. MX-wijzigingen vereisen altijd recente verificatie. De actuele aanmeldvereisten uit al je actieve bedrijven blijven bij iedere leveranciersstap gelden; een nieuw vereiste MFA-controle tijdens de wijziging stopt verdere verzending. Bij productwijzigingen toont het formulier de eenheidsprijs, het bestaande aantal, het volledige bedrag exclusief btw per factuurperiode en de ingangsdatum. Een wijziging van die overeenkomst sinds het openen van het formulier vereist een nieuwe beoordeling. Technische beheerders zonder bestelrechten kunnen de SMTP-instellingen aanpassen; de financiële productvelden blijven afgeschermd. Automatiseringslimieten beoordelen het volledige terugkerende bedrag, inclusief het bestaande aantal, niet alleen de eenheidsprijs. De browser bewaart vóór verzending één oorspronkelijke referentie. Bij een verbindingsfout blijft die staan. Open de oorspronkelijke status, controleer de getoonde stappen en bevestig afzonderlijk **reconciliëren** of **doorgaan**. Reconciliëren leest uitsluitend leveranciers- en boekhoudstatus en kan bewezen lokale afronding herstellen. Doorgaan kan een aantoonbaar nooit verstuurde stap uitvoeren. Klikken of herladen maakt geen vervangend verzoek aan. Als nog geen verzoek voorbereid is, kan gecorrigeerde invoer dezelfde referentie gebruiken. Een ander bedrijf in een tweede tabblad vervangt de oorspronkelijke context niet. Een nieuw sterk geverifieerde persoonlijke API-verbinding van dezelfde onveranderde menselijke identiteit kan zo'n browserverzoek ook expliciet herstellen met de CLI-opdrachten hieronder. Portaalmetadata heeft `origin: "portal"`, `operation_id: null` en geen API-offertebewijs; er wordt geen API-operatie of OAuth-herkomst verzonnen. De actuele portaalrechten, bedrijfscontext en oorspronkelijke scopegrens blijven verplicht. Een machine, andere persoon of opnieuw ingestelde identiteit kan dit verzoek niet overnemen. Dit werkt ook als nieuwe API-schrijfacties uitstaan, via GET-only reconcile. Een oorspronkelijke interne beheerder gebruikt zijn eigen beheercontext: ```sh binadit --account "$ORIGINAL_ADMIN_CONTEXT" spam configuration-changes get "$CHANGE_ID" --administrator binadit --account "$ORIGINAL_ADMIN_CONTEXT" spam configuration-changes reconcile "$CHANGE_ID" \ --administrator --confirm-change "$CHANGE_ID" --input recovery.json --yes ``` De REST-prefix is dan `/accounts/{original_admin_context}/admin/spam/configuration-changes`. Dit verleent geen lidmaatschap van het doelbedrijf. Dezelfde echte beheerder moet nog steeds bevoegd zijn. Gebruik voor browserreferenties geen `locate` met een verzonnen API-sleutel; de referentie staat al in het formulier en de herstelmelding. ## Instellingen wijzigen Lees eerst `GET /api/v1/accounts/{account}/spam/filters/{filter}` en bewaar de ETag. Stuur daarna één `PUT /api/v1/accounts/{account}/spam/filters/{filter}/configuration` met `If-Match`, een unieke `Idempotency-Key` en bijvoorbeeld: ```json {"destinations":[{"hostname":"mail.example.nl","port":25}],"aliases":[],"manage_dns":false} ``` Gebruik `spam:write`; met `manage_dns: true` is ook `dns.records:write` nodig. Aliassen moeten actuele eigen DNS-zones zijn. Met inkomende filtering is minimaal één publieke SMTP-bestemming nodig. Zonder automatisch DNS-beheer wijzig je MX zelf bij de DNS-provider. Met automatisch beheer blijven andere recordtypen behouden; het portaal bewaart de oorspronkelijke MX-records en DNS-geschiedenis. Een expliciete tegenstrijdige bedrijfskoppeling wordt geweigerd. In de Rust-CLI: ```sh binadit --account "$ACCOUNT" spam filters get "$FILTER" binadit --account "$ACCOUNT" api "/spam/filters/$FILTER/configuration" \ --method PUT --from-file settings.json --version "$FILTER_ETAG" --yes ``` Een invoerbestand is een gewoon privébestand; gebruik op Unix `chmod 600`. `--dry-run` valideert zonder leverancierswijziging. Verander voor een herhaling van hetzelfde verzoek de oorspronkelijke sleutel, invoer en verbinding niet. ## Betaalde producten en MX-herstel Betaalde productwijzigingen horen niet in de bovenstaande PUT. Vraag een offerte met `POST /order-quotes`, `kind: "spam_configuration"` en `input` met `filter_id`, `products`, `destinations`, `aliases` en `manage_dns`. Bevestig die offerte één keer via `POST /orders` met `quote_id`. De bestaande overeenkomst behoudt haar ID, hoeveelheid en factuurperiode; de nieuwe prijs geldt voor de volgende periode. Deze wijziging maakt geen extra factuur of tweede abonnement. Een wijziging van de factuurperiode vereist afzonderlijk beoordeelde migratie. De wijziging bewaart één oorspronkelijk verzoek. De leverancier wordt eerst bevestigd, vervolgens de beoordeelde DNS-wijzigingen en daarna de prijs op de bestaande overeenkomst. Pas met de bevestigde deelresultaten worden de lokale filterinstellingen, offerte en operatie afgerond. Een later probleem herhaalt geen eerdere leveranciersactie en wist geen bevestigde DNS-geschiedenis. `POST /spam/filters/{filter}/actions/restore-dns` met de actuele filter-ETag en één nieuwe verzoekssleutel herstelt opgeslagen MX-records via dezelfde DNS-route. Het verzoek heeft een lege JSON-body. Historische back-ups geven geen rechten over zones die inmiddels van een ander bedrijf zijn. Ook herstel heeft een eigen onveranderlijk oorspronkelijk verzoek. ## Filter verwijderen Interne beheerders openen vanuit het overzicht **Verwijderen**, controleren het bedrijf, het filter en de bestaande einddatum en bevestigen met een recente passkey. Het formulier bewaart één oorspronkelijke referentie. Standaard worden de eerder opgeslagen MX-records teruggezet voor zones die aantoonbaar nog bij het bedrijf horen; schakel dit alleen bewust uit. Andere recordtypen blijven staan. Een gewijzigd filter of abonnement sinds het openen vereist een nieuwe beoordeling. Via de API vereist `DELETE /api/v1/accounts/{account}/spam/filters/{filter}` actuele `admin:write` en `spam:write`, een echte interne beheerder met recente sterke verificatie, de filter-ETag en één oorspronkelijke verzoekssleutel. Stuur: ```json {"confirm_resource_id":"7","restore_dns":true} ``` Met MX-herstel is ook `dns.records:write` nodig. De generieke CLI gebruikt dezelfde endpoint, bijvoorbeeld: ```sh binadit --account "$ACCOUNT" api "/spam/filters/$FILTER" --method DELETE \ --from-file deletion.json --version "$FILTER_ETAG" --yes ``` De leverancier wordt één keer verwijderd. Vervolgens worden de beoordeelde MX-wijzigingen uitgevoerd en wordt hetzelfde bestaande abonnement aan het einde van de huidige periode beëindigd. Dit maakt geen factuur of nieuw abonnement. Een al beëindigd abonnement krijgt een uitsluitend lezende controle van exact zijn bekende leveranciers-ID, debiteur en einddatum, voordat de filterleverancier wordt benaderd. De oorspronkelijke financiële reservering blijft staan tot de lokale afronding; een gelijktijdige hervatting wordt geweigerd. Er wordt geen tweede beëindiging verstuurd. Zonder gekoppeld abonnement is er geen financiële stap. Onduidelijke of dubbele overeenkomsten blijven geblokkeerd. Een bewezen verwijdering blijft als lokale tombstone met zijn oorspronkelijke bewijzen bewaard. Alleen die geverifieerde tombstone geeft een domeinnaam of alias weer vrij. Alleen een handmatig gewijzigd lokaal statusveld doet dat niet. Een onzeker DELETE-resultaat blijft vastgehouden: afwezigheid of een later gelijknamig filter bewijst niet dat het oorspronkelijke DELETE geaccepteerd is. Gebruik de bestaande status- en herstelopdrachten; stuur geen nieuwe DELETE of sleutel. Metadata toont `action: "delete"` en zo nodig `termination_review` met de datum en `already_terminated`. `completion_verified: true` vereist ook gezonde oorspronkelijke DNS- en financiële deelbewijzen en de lokale tombstone. Een browserverzoek blijft een browserverzoek. Dezelfde oorspronkelijke interne beheerder kan via zijn echte persoonlijke API-verbinding de bekende referentie uitlezen en GET-only reconciliëren met `--administrator`, ook wanneer nieuwe API-schrijfacties uitstaan. Een beschadigd afgerond bewijs blijft geblokkeerd; het portaal meldt geen gezonde afronding op basis van alleen een lokale status. ## Onzeker resultaat herstellen Bij `spam_configuration_requires_reconciliation` staat de oorspronkelijke UUID in `errors.original_change_id`. Bewaar deze UUID. Maak geen nieuwe sleutel, offerte of filter aan om een onzekere wijziging te omzeilen. ```sh binadit --account "$ACCOUNT" spam configuration-changes get "$CHANGE_ID" ``` De metadata bevat de leveranciersfase, kindstatussen, huidige versies en `completion_verified`. Bij een betaalde wijziging zie je ook de beoordeelde EUR-eenheidsprijs, het behouden aantal, het volledige periodebedrag, de beoordeelde ingangsdatum en factuurperiode. `business_completion_verified` alleen bevestigt nog niet dat ook de oorspronkelijke HTTP- en offerteregistratie gezond zijn. Inloggegevens, leveranciersbewijzen en oorspronkelijke privé-invoer worden niet teruggegeven. Een actueel sterk geverifieerde bedrijfseigenaar kan het bestaande verzoek reconciliëren. Daarvoor zijn `spam:read` en beschikbare `spam:write` nodig, plus DNS-lees/schrijfrechten bij DNS en bestelrechten bij een betaalde wijziging. Nieuwe schrijfacties mogen voor **reconcile** uitstaan. Een nieuw leestoegangstoken hoeft in die onderhoudsstand geen schrijfscope te krijgen: de server controleert de actuele eigenaar, de beschikbare oorspronkelijke schrijfrechten en de bewaarde originele scopegrens. Met ingeschakelde schrijfacties blijft de normale token-schrijfscopetoegang vereist. Doorgaan vereist altijd de actuele schrijftoegang. Maak `recovery.json` met de echte waarden uit de metadata: ```json {"confirm_change_id":"oorspronkelijke UUID","confirm_filter_id":7,"confirm_filter_version":"huidige filterversie","version":"huidige verzoekversie","confirm_no_supplier_mutation":true} ``` ```sh binadit --account "$ACCOUNT" spam configuration-changes reconcile "$CHANGE_ID" \ --confirm-change "$CHANGE_ID" --input recovery.json --yes ``` De REST-route is `POST /spam/configuration-changes/{change}/actions/reconcile`. Dit pad leest leveranciers- en boekhoudstatus en kan bewezen lokale afronding herstellen. Het herhaalt geen PUT, PATCH, DELETE of boekhoudkundige EDIT. Het oude principaal, de oorspronkelijke operatie, offerte en kind-ID's blijven behouden. Een andere leveranciers-ID met dezelfde domeinnaam is geen eigendomsbewijs. Een nooit uitgevoerde resterende stap vraagt expliciet **continue**. Lees de metadata opnieuw, beoordeel de oorspronkelijke wijziging en gebruik dezelfde velden met `confirm_continue_original: true` in plaats van `confirm_no_supplier_mutation`. Daarna: ```sh binadit --account "$ACCOUNT" spam configuration-changes continue "$CHANGE_ID" \ --confirm-change "$CHANGE_ID" --input continuation.json --yes ``` Doorgaan vereist ingeschakelde schrijfacties en actuele rechten. Het controleert eerst al gestarte stappen en voert alleen aantoonbaar nooit verstuurde resterende stappen uit. Een onzekere leveranciersactie blijft geblokkeerd totdat uitleesbewijs het oorspronkelijke resultaat bevestigt. Herstel gebruikt geen nieuwe `Idempotency-Key`, proefuitvoering of automatische herhaling. ## De UUID ontbreekt Gebruik `spam configuration-changes locate --input original.json` wanneer een verloren HTTP-antwoord de UUID verborgen hield. Het bestand bevat `original_principal_id`, `original_key` en `original_request` met de exacte `method`, volledige account-`path` en oorspronkelijke JSON-`body`. Dit is een uitleesactie; er wordt geen nieuwe operatie aangemaakt. Dezelfde actuele verbinding kan haar eigen exacte verzoek vinden. Een andere verbinding vereist de actuele sterk geverifieerde bedrijfseigenaar. De REST-route is `POST /spam/configuration-changes/actions/locate`. ## Contract voor AI-agents Bewaar bedrijf, principaal, oorspronkelijke sleutel, methode, pad, volledige JSON, filter-ETag en de teruggegeven oorspronkelijke UUID vóór vervolgacties. Gebruik exacte versies en expliciete oorspronkelijke UUID-bevestiging. Onderscheid configuratie, offertebevestiging, verwijdering, MX-herstel, GET-only reconcile en nooit-verstuurde voortzetting. Geef geen nieuwe sleutel uit bij een fout, time-out of nieuwe grant. Een afgeronde API-requestregistratie is bovendien iets anders dan een geplande achtergrondtaak; zie het [oorspronkelijke operatiecontract](/developers/guides/original-operations?lang=nl). Bestaande instellingen wijzigen, MX-herstel en verwijderen zijn niet hetzelfde als een nieuw filter bestellen of een historische achtergrondtaak overnemen. De algemene release houdt die resterende aanroepende koppelingen afzonderlijk bij; deze handleiding claimt geen volledige publieke release of reeds uitgevoerde productieactivering.