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.

Spamfilters bestellen en de oorspronkelijke levering herstellen

Portal, API en Rust-CLI gebruiken dezelfde bestelling, factuur, terugkerende afspraak en leveringstaak. Bewaar original_purchase_id uit het antwoord. Dit is een bestaande opdracht, geen sleutel waarmee iemand zonder actuele rechten kan bestellen.

Bestellen

In het portal kies je bij Spamfilters → Bestellen het bedrijf, een eigen domein, de diensten, doelservers en eigen aliassen. Automatisch MX-records aanpassen is een expliciete keuze. De server berekent de prijs en periode. Controleer de winkelwagen en verifieer jezelf met een actuele passkey of TOTP. De goedkeuring geldt 24 uur voor precies deze bestelling. Bij iedere leveranciersstap controleert het portal opnieuw de persoon, beveiligingsinstellingen, bedrijfsrechten, betaalafspraak en oorspronkelijke leverancier.

Via de API maak je een offerte met POST /api/v1/accounts/{account}/order-quotes, kind: "spam_filter" en input:

{
  "kind": "spam_filter",
  "input": {
    "domain_id": 123,
    "products": {"incoming": true, "outgoing": false, "archiving": false},
    "destinations": [{"hostname": "mail.example.nl", "port": 25}],
    "aliases": [],
    "manage_dns": true
  }
}

Controleer de offerte en bevestig haar met het bestaande orders-endpoint en één blijvende idempotentiesleutel. Gebruik de gepubliceerde API-handleiding voor OAuth, prijscontrole en de normale orderstappen. Meerdere filters in één bedrijfsbestelling gebruiken één gezamenlijke checkout en afzonderlijke oorspronkelijke leveringstaken. Een serviceverbinding krijgt geen verzonnen menselijke identiteit.

queued betekent dat de oorspronkelijke checkout lokaal bevestigd is. Het bewijst nog geen voltooide levering. awaiting_payment betekent dat levering op de bestaande factuur wacht. Een late betaalmelding verlengt een verlopen goedkeuring niet automatisch en mag geen tweede factuur of afspraak aanmaken.

Dezelfde bestelling bekijken

Open in het portal /module_spam/purchases/ORIGINAL_UUID. Het scherm toont de oorspronkelijke keuzes en prijs. Status vernieuwen leest alleen lokale, gecontroleerde metadata. De oorspronkelijke persoon gebruikt de oorspronkelijke actieve bedrijfscontext; een andere tab kan deze context niet stilzwijgend vervangen.

De API gebruikt:

GET /api/v1/accounts/{account}/spam/purchases/{original_uuid}

Dit vraagt spam:read en orders:read. Een persoonlijke verbinding moet dezelfde oorspronkelijke persoon en identiteitgeneratie vertegenwoordigen. Een serviceverbinding kan haar eigen oorspronkelijke serviceopdracht uitlezen; die opdracht wordt niet aan een willekeurige persoon overgedragen. Het klantendpoint accepteert geen platformbevoegdheid voor een ander bedrijf.

Het antwoord bevat id, account_id, filter_id, order_id, task_id, version, filter_version, company_version, checkout_state, invoice_id, supplier_state, completion_verified, requires_reconciliation en de publieke oorspronkelijke keuzes onder review. Een native opdracht toont ook de eindtijd van haar native goedkeuring. De private leverancier- en financiële bewijzen, authenticatiegegevens en handtekeningen blijven op de server.

Alleen completion_verified: true bevestigt zowel de oorspronkelijke dienst als de lokale bestelling. Een leveranciersantwoord zonder bevestigde lokale opslag telt niet als voltooiing.

Vernieuwen, controleren en vervolgen

Het portal toont drie expliciete acties. Controleer telkens eerst het domein, diensten, doelservers, prijs en bedrijf en verifieer jezelf opnieuw wanneer gevraagd.

De overeenkomstige klant-API-paden zijn POST .../spam/purchases/{original_uuid}/actions/renew, /actions/reconcile en /actions/continue. Gebruik een actuele persoonlijke verbinding van dezelfde persoon, recente sterke verificatie en de oorspronkelijke actuele bestel-/modulebevoegdheden. Vernieuwen en vervolgen vereisen ingeschakelde schrijfacties. Als nieuwe schrijfacties zijn uitgeschakeld, kan alleen reconciliatie met een nieuwe sterk geverifieerde leesverbinding verder: actuele native bestel-/schrijfrechten én de bewaarde oorspronkelijke scopegrens blijven vereist, maar er wordt uitsluitend uitgelezen en bewezen lokaal afgerond. Vernieuwen met de API bindt de echte actuele persoonlijke verbinding aan hetzelfde oorspronkelijke verzoek en dezelfde scopegrens. De eerste HTTP-aanvraag, oorspronkelijke principal en offerte worden niet vervangen. Een ingetrokken oude verbinding krijgt hierdoor geen nieuwe rechten.

Verstuur exact de actuele versies uit GET en de passende bevestiging:

{
  "confirm_original_id": "11111111-1111-4111-8111-111111111111",
  "confirm_filter_id": 456,
  "version": "64-hex-characters-from-GET",
  "filter_version": "64-hex-characters-from-GET",
  "company_version": "64-hex-characters-from-GET",
  "confirm_no_supplier_mutation": true
}

Voor /renew vervang je uitsluitend de laatste veldnaam door confirm_renew_original; voor /continue door confirm_continue_original. 412 betekent opnieuw uitlezen en controleren. Deze herstelacties nemen geen nieuwe Idempotency-Key, dry-run of automatische retry. Het bestaande UUID blijft behouden, ook na een netwerkfout.

Een bekende financiële ontvangstbevestiging kan de oorspronkelijke lokale checkout herstellen zonder opnieuw afrekenen. Als een betaald origineel nog geen afspraak heeft en nooit een afspraak heeft verstuurd, kan expliciet vervolgen de eerste oorspronkelijke afspraak maken. Een eerder onzekere subscription.add wordt niet opnieuw verstuurd. Een onzeker factuur- of filteraanmaakantwoord zonder vertrouwd oorspronkelijk bewijs blijft geblokkeerd: geef support het oorspronkelijke kenmerk en maak geen nieuwe bestelling. Een ontbrekende of onvolledige eerste API-ontvangstbevestiging kan herstel eveneens blokkeren; een actuele verbinding is geen bewijs dat die oorspronkelijke aanvraag slaagde.

Rust-CLI

binadit spam purchases get ORIGINAL_UUID
binadit spam purchases renew ORIGINAL_UUID --confirm-original ORIGINAL_UUID --input review.json --yes
binadit spam purchases reconcile ORIGINAL_UUID --confirm-original ORIGINAL_UUID --input review.json --yes
binadit spam purchases continue ORIGINAL_UUID --confirm-original ORIGINAL_UUID --input review.json --yes

review.json bevat het hierboven getoonde bevestigingsobject met echte actuele versies. De CLI controleert UUID, filter en antwoordvorm en toont alleen de publieke velden. Vernieuwen en vervolgen controleren eerst de actuele capability. Deze commando's maken geen nieuwe lokale mutatie-intent of verzoekssleutel. --wait, --all, --dry-run, --idempotency-key en algemene versie-/bodyoverschrijvingen worden voor deze commando's geweigerd.

Contract voor AI-agents

1. Lees de echte offerte en actuele beschikbare functie. Verzin nooit een prijs, bedrijfskoppeling, persoon, machtiging of leveranciersidentificatie.
2. Bewaar de eerste aanvraagbody, sleutel, principal en original_purchase_id. Een nieuwe sleutel is geen herstel.
3. Onderscheid checkoutacceptatie, bevestiging van de terugkerende overeenkomst, leveranciersaanmaak, afronding van de DNS-child en definitieve lokale publicatie. Een wachtrijstatus bewijst geen voltooide dienstlevering.
4. Lees de oorspronkelijke metadata vóór een expliciete actie. Lever de exacte oorspronkelijke/filter-/bedrijfsversies en de ene bijpassende bevestiging aan. Stuur nooit een vervangende checkout of factuur-ID.
5. Verlenging wijzigt uitsluitend de afzonderlijk bewaarde actuele bevoegdheid. Zij behoudt de onveranderlijke eerste goedkeuring, financiële/bronplafonds en oorspronkelijke taak. Platformbeheer voor een ander bedrijf vereist een eigen expliciet servercontract.
6. Reconciliatie mag bekende oorspronkelijke effecten inspecteren en lokale publicatie afronden. Zij kan geen onzekere aanmaak op naam ontdekken, POST herhalen, een onbekende overeenkomst vervangen, een nooit geprobeerde DNS-notificatie versturen of de dienst van iemand anders overnemen.
7. Lees bij een bewaarde, geaccepteerde PATCH met verloren antwoord het oorspronkelijke resultaat. Alleen afzonderlijk bevestigde voortzetting mag een resterende, nooit geprobeerde notificatie versturen; voer niet opnieuw PATCH uit.
8. Bewaar bij 409 het origineel en leg de vastgehouden fase uit. Lees bij 412 opnieuw en laat de exacte actuele beoordeling bevestigen. Stop automatische wijzigingen bij ontbrekend vertrouwd ACK-bewijs en gebruik de oorspronkelijke supportreferentie.

Nooit gestarte bestelling laten vervallen

POST /api/v1/accounts/{account}/spam/purchases/{original}/actions/abandon gebruikt dezelfde drie versies en bevestigingen als herstel, met confirm_never_attempted_abandon: true. Rust: binadit spam purchases abandon ORIGINAL_UUID --confirm-original ORIGINAL_UUID --input abandon.json --yes. Het portal toont dezelfde actie bij een voorbereide bestelling.

De server vergrendelt hetzelfde oorspronkelijke verzoek als checkout. Alleen zonder checkout-witness, factuur, overeenkomst, leverancierspoging of child kan de bestelling vervallen. De oorspronkelijke rij blijft als getekend bewijs bestaan, de lokale taak wordt geannuleerd en de ongebruikte filteridentiteit komt vrij. Een onzeker antwoord van accounting, betaling of leverancier blijft geblokkeerd; deze actie herhaalt niets en trekt geen betaling terug. Controleer na netwerkverlies de oorspronkelijke status; maak geen vervangend verzoek op basis van een ontbrekend antwoord.

Lokale bedrijfstoewijzing door beheerders

Gebruik vanuit uw eigen echte beheercontext POST .../accounts/{operator}/admin/spam/assignments/review met filter_id, source_account_id, target_account_id. De reactie geeft filter_version, source_version, target_version. Dien deze waarden met dezelfde drie IDs en confirm_assignment: true in op POST .../accounts/{operator}/admin/spam/assignments, met de gewone idempotentiesleutel. Rust: binadit spam assignments review --input selection.json en binadit spam assignments commit --input reviewed-assignment.json --yes. Het portal gebruikt dezelfde service na passkeycontrole en controleert ook de oorspronkelijk getoonde versies.

Dit is lokale metadata-adoptie voor ongebonden filters. Een bestaande periodieke overeenkomst, oorspronkelijke bestelling of lopende wijziging vereist een eigen beoordeelde contractoverdracht en wordt met 409 geweigerd. Primaire domeinen en aliassen moeten al aantoonbaar bij het doelbedrijf horen; opgeslagen oude MX-records moeten eerst worden hersteld of gereconcilieerd. De handeling wijzigt geen leverancier, factuur, overeenkomst of DNS-record en draagt geen betaalverantwoordelijkheid stilzwijgend over.