Naar de documentatie
Binadit
Open portaal

Exchange wordt later opnieuw gebouwd en is niet beschikbaar via de API of CLI. Beschikbaarheid van deze release

Praktische werkwijzen

Markdown

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.

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:

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:

{"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:

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:

{"confirm_resource_id":"7","restore_dns":true}

Met MX-herstel is ook dns.records:write nodig. De generieke CLI gebruikt dezelfde endpoint, bijvoorbeeld:

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.

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:

{"confirm_change_id":"oorspronkelijke UUID","confirm_filter_id":7,"confirm_filter_version":"huidige filterversie","version":"huidige verzoekversie","confirm_no_supplier_mutation":true}

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:

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.

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.