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.

Create company contacts and restore the original request

Portal, API, and Rust CLI use the portal's existing WeFact connection and the same company journal. The CLI does not connect directly to WeFact. The modern company has one original contact reservation; a lost answer may not cause a second debtor.add. This implementation does not activate a production environment or CLI download. Check the available API capabilities of your environment.

Prerequisites

Use a personal connection from a human internal administrator with recent passkey authentication. Service integrations and connections with restricted resource rules cannot perform this global management. The administration context (--account) is separate from the modern target company. Keep both numbers.

admin:read is needed for overview, review and SQL status. Create and resume require admin:write, active API write, management, and sensitive action settings, and a working, unmodified accounting connection. Read-only vendor recovery requires current admin:read and current admin:write authority of the personal connection, recent strong authentication, and the same original human/security generation. This recovery is also possible when new API writes or supplier writes are temporarily disabled. A disabled or changed vendor connection will not be bypassed.

In the portal

Open Management → WeFact → Create company contact. Enter the modern company ID and select Check company contact. Check the current company name, billing information and customer code. The review expires after ten minutes. With an existing signed direct debit authorization, the page states that the current authorization is being sent; bank and authorization values are not printed on the review page. The entire original payload, including such hidden values, is subject to approval.

Confirm the selection and choose Create or confirm contact. No invoice, payment or email is created. The existing canonical business contact can be read; a new contact requires one original add and full exact readback before the local company link becomes visible. The local bank account and authorization will not be changed.

If there is uncertainty, the page locks the creation action. Choose Check original attempt. Never restore by pressing create again, choosing another key or linking a similar contact. The status and original UUID remain retrievable with the company ID, even after reopening the page.

API contract

All paths below are under /api/v1/accounts/{administratiecontext}. company is the modern target company; resolution is the original UUID. JSON responses are in data and use Cache-Control: no-store.

Request a review with {"company_id":42}. The server returns company.id, company.name, company.version, safe contact fields, existing_mandate_included, reviewed_at, expires_at, and review_token. Save the review in a protected file, not in logs or a shared folder. The token binds the current human identity, security generation, personal connection, administration context, company version, full payload, and vendor source.

For ensure, send exactly this contract, with If-Match equal to company_version, send:

{
  "company_id": 42,
  "company_version": "<64 hextekens uit de review>",
  "reviewed_at": 1793250000,
  "review_token": "<64 hextekens uit de review>",
  "confirm_company_id": 42
}

The time and tokens above are form examples; always use the current server review. dry_run:true or X-Binadit-Dry-Run:true validates the ensure without contact journal, API operation, or vendor effect. A real ensure returns company_id, remote_identifier, debtor_code, resolution_id, linked, local_bank_details_changed:false and invoice_created:false, among others. For an existing legacy contact without this administration journal, resolution_id may be null. The new business link and the original API operation are confirmed in the same local transaction.

Status after uncertainty

contact-resolution and the exact status route read only SQL. They show the original resolution/intent/company IDs, state, provider_attempted, prepared_without_dispatch, original_add_acknowledged, verified_remote_identifier, reply_origin, and requires_reconciliation. They do not return any original payload, bank values, key or private receipt reference. Their supplier_reads:false and supplier_mutations:false describe this status request.

A new personal connection or the portal used by the same current human, security generation, and administration context may read and explicitly restore this original proof, even if the original attempt started on the other channel. The current adapter controls its own full role, scope, and passkey policies. The saved original principal, approval, and API operation are not replaced. Another human/security generation or a changed company, supplier source or evidence is rejected.

A missing reservation may still belong to an ongoing original request. Do not use absence as a reason to automatically start a new creation. An old journal without verifiable administration receipt will not automatically be adopted as a new approval.

Read-only vendor recovery

First read the original SQL status and the current company version via a new local review. Confirm the exact original UUID, company and current version. If-Match must contain the same current company version.

{
  "confirm_resolution_id": "<oorspronkelijke resolution-UUID>",
  "confirm_company_id": 42,
  "company_version": "<actuele 64 hextekens>",
  "confirm_no_supplier_mutation": true
}

If a positive original add ID is retained, the server will only read that exact contact. If the original response did not contain an ID, additional verified_remote_identifier (positive integer) and supplier_receipt_reference (private reference of up to 1000 characters) are required. Select that ID only from the verified original supplier confirmation. A name, billing address, customer code or search match is insufficient proof of ownership.

The reference is the statement of the current authorized administrator. The server does not cryptographically authenticate an external receipt document. It does check the explicit ID via debtor.show, the exact original server client code, full original payload, and unique current/archived corporate ownership. Incorrect, missing or contradictory evidence retains the original hold. No search is performed and no contact is added again.

Recovery returns the same original status with supplier_reads:true and supplier_mutations:false. reply_origin:operator_readback is distinguished from original_add; a manual readback is not represented as receipt of the original add ACK. A successful recovery confirms the original local link and original parent operation. It does not create a new API operation, invoice, email, or vendor effect.

Explicitly resume a reservation that was never sent

Resume is a write and can perform the original first add. It is not a reconcile. Only use it with prepared_without_dispatch:true, with a new current review, If-Match, confirm_resolution_id and confirm_no_previous_dispatch:true, in addition to the normal ensure review fields. New writes must be available. Do not send a new Idempotency-Key or a dry run; the exact original UUID is the durable reservation.

Within the canonical locked preparation, the original reservation should still not have a dispatch witness, ACK ID, or recovery candidate. A race, modified source/payload, uncertain/executed add, or existing link is rejected. The original context, principal, and parent operation are preserved. Success reports supplier_reads:true and supplier_mutations:true; Resuming again is refused. An uncertain resume result then only proceeds via original status/reconcile.

Rust CLI

The seven Rust commands below are additions to the frozen 355 reference commands. Use a currently available Rust build and personal admin connection. Protect files with umask 077; the CLI rejects unsafe input files. --input - reads protected JSON supplied from stdin. Private references never belong as a shell argument in the process list.

binadit admin wefact overview --account 1
umask 077
binadit admin wefact review-contact 42 --account 1 --output json > contact-review.json
binadit admin wefact ensure-contact --account 1 --confirm-company 42 --input contact-review.json --yes
binadit admin wefact contact-status 42 --account 1
binadit admin wefact contact-resolution 42 ORIGINAL_RESOLUTION_UUID --account 1

To reconcile, create a protected contact-recovery.json with the JSON from the recovery section; add the verified original ID and private reference only if necessary:

binadit admin wefact reconcile-contact 42 ORIGINAL_RESOLUTION_UUID --account 1 \
  --confirm-company 42 --confirm-resolution ORIGINAL_RESOLUTION_UUID \
  --input contact-recovery.json --yes

For the individual never-sent case, first retrieve a fresh review:

binadit admin wefact review-contact 42 --account 1 --output json > contact-review.json
binadit admin wefact resume-contact 42 ORIGINAL_RESOLUTION_UUID --account 1 \
  --confirm-company 42 --confirm-resolution ORIGINAL_RESOLUTION_UUID \
  --input contact-review.json --yes

Reconcile and resume require their own explicit original UUID. They do not use a new automatic HTTP intent or automatically retry a failed POST. Resume also checks the current write capability. The normal ensure remains bound to its original local key and personal connection.

After successful supplier recovery, an old automatic ensure intent may still be pending locally. To do this, use only the original operations manual , with the exact old principal, key, method, path and original protected body and explicitly api --confirm-original-operation ORIGINAL_OPERATION_UUID. That assertion reads SQL, clears only the appropriate successful local pending request, and stops; it does not send the ensure again. The operation-UUID and resolution-UUID are different references.

Security and agent rules

Each local completion checks the actual saved business link, journal fields, original operation and audit entry; a save canceled or modified by modelhooks is not a success. Unsolicited business fields must remain unchanged. Positive original vendor ACK evidence is logged separately under row lock, even if business model hooks or subsequent authorization deny local publication. The original API envelope and provenance are verified with the existing original operation MAC before recovery and publishing; old or modified missing evidence fields remain blocked.

The existing source-related company reservation remains canonical. Encryption protects private context and recovery references; separate keyed bindings protect original context, dispatch witness, ACK/recovery ID, and completion. A status reset does not erase that independent witness. Each phase checks current identity, role, company, source and the final pure time boundary; supplier traffic runs outside local transactions. The SDK checks the actual method, HTTPS URL, Host, TLS/redirect settings, and full JSON against the intended request immediately before sending. Keys are not printed. Adds are not automatically repeated.

As a user or agent, save the original company, context, review, request key, principal, operation UUID, and resolution UUID. Don't create a new key or vendor ID to circumvent an uncertain outcome. Do not delete or modify any journals to continue. Report contact link, original ACK, manual readback and payment separately. A confirmed contact link is not proof of payment and does not allow modification of an external agreement or authorization.