Exchange is excluded from this API/CLI release. Any historical Exchange API or CLI example in this guide is unavailable; native portal behavior is outside this exclusion. See current release scope.

Test portal email deliberately

The mail test sends one fixed test message to the current verified login address of the internal administrator performing the action. There is no configurable recipient, subject, body or attachment. The message contains only the original test reference, without customer data or secrets. A personal connection with current internal administrator rights and recent passkey verification is required; service connections cannot run a mail test.

accepted means the mail transport call confirmed acceptance. It does not prove inbox delivery. Check your own inbox and spam folder. The test does not change SMTP settings, customer data, invoices, passwords or supplier services.

Portal

Open /test-application-email-system. Opening the page sends nothing. Choose Check recipient and current version, verify your passkey and check your own displayed address. Tick the explicit confirmation and choose Request one test message.

The browser saves the original test number before sending. After an uncertain response or a reload, Read original attempt uses only that same number. There is no automatic sending, polling or new attempt after renewed verification. If your passkey expires, read and verify again, then explicitly confirm sending yourself.

One new attempt is allowed per five minutes, across all administration companies and connections of the same administrator. Investigate an uncertain previous outcome first. For an explicit new attempt, enter the displayed original reference and choose the separate review button. The server checks the cooldown period and exact previous attempt again. Do not delete a locally saved reference to bypass an unknown outcome.

API

All paths are under /api/v1/accounts/{administratiecontext}. Use admin:read for inspection/status and admin:write for requests. The API, write, sensitive and administration flags still apply. The administration context is your own approved management company.

Read the recipient and current version first. Send the ETag as If-Match, one durable Idempotency-Key and only:

{"intent_id":"1fe95bbe-8449-4ea3-a6b2-3f013a2047bc","confirm_user_id":8}

confirm_user_id must be the actual administrator performing the action, as returned by GET. Save the UUID, body and idempotency key before the POST. dry_run:true performs the current checks without an attempt, operation or send. A missing version returns 428; a changed version 412; a new attempt too soon 429. Custom recipient or message fields return 422.

A durable attempt exists before SMTP can begin. The same UUID cannot start a second SMTP call, even with a different HTTP idempotency key. After a lost response, first read the original UUID and existing operation. A 404 does not prove that a concurrent original request will never commit: retain the reference and investigate that same attempt later.

requires_reconciliation:true requires investigation of the original attempt. After review, a separate new UUID can be requested, with replace_attempt_id equal to the exact last unresolved reference. The CLI uses --replace-attempt OORSPRONKELIJKE_UUID for the deliberate new send request. This is a deliberate new mail request; the cooldown period and all current checks still apply.

CLI and AI agents

binadit admin mail-test get --account 1
binadit admin mail-test send --account 1 \
  --intent-id 1fe95bbe-8449-4ea3-a6b2-3f013a2047bc \
  --confirm-user 8 --version '<data.version uit get>' --dry-run
binadit admin mail-test send --account 1 \
  --intent-id 1fe95bbe-8449-4ea3-a6b2-3f013a2047bc \
  --confirm-user 8 --version '<dezelfde actuele data.version>' --yes
binadit admin mail-test status 1fe95bbe-8449-4ea3-a6b2-3f013a2047bc --account 1

An agent never chooses another recipient address and does not create a replacement UUID after an uncertain outcome. Check the explicit administration company, your own recipient and the current version. Retain the original reference after closing the CLI too. The CLI records a private metadata marker before an actual POST; later executions with the same UUID can only investigate the original status. The CLI displays only the fixed safe status contract, not SMTP error text or transport configuration.

The mail test uses one separate SMTP or sendmail transport. SMTP requires TLS and certificate verification; global debug recipients are not inherited. Log, failover and round-robin transports are unsuitable for this explicit test and return a controlled 503. This is a configuration requirement, not proof that an existing external mail server is live and reachable.