API and CLI availability

The API and Rust CLI support the released Binadit services within the permissions of your current connection and company. Check binadit capabilities and the current OpenAPI specification before automating a workflow.

Exchange will be rebuilt later

The entire Exchange integration is excluded from this release. There are no active Exchange features for mailboxes, addresses, passwords, imports, supplier settings, products, pricing policy, quotes, orders or renewals through the API or CLI. An existing token or previously saved quote does not grant access either. A mixed new order containing Exchange is refused in its entirety before supplier work or billing begins.

Exchange commands are not offered in normal CLI help. An explicitly supplied old Exchange command stops locally. Reconnecting or broadening general API permissions does not activate Exchange. Original receipts and local recovery files are retained; do not delete them to bypass a block.

The existing Exchange features in the portal are outside this API/CLI change. Historical invoices may continue to contain Exchange items: these are existing financial records, not an active Exchange API.

Old balance and top-up feature

The old balance and top-up feature has been removed from the portal. Customers pay immediately or through a recurring payment; the API and CLI offer no balance or top-up workflow. Existing invoice and subscription features have their own documentation and permissions.

Customer impersonation remains in the portal

“Log in as customer” remains a portal feature with a browser session. Administrators use the API and CLI under their own administrator identity with the current permissions granted for that purpose. This release does not introduce API support connections that impersonate a customer. A company number in a request does not itself grant access.

Current verification for personal connections

A personal API or CLI connection follows the current login security policy of your portal identity. The requirement applies across all your active memberships at available companies, even when you have selected a different company. For example, if a company requires a passkey, a connection previously established with TOTP no longer grants access. First set up the required factor and then reconnect using binadit login. Adding a factor does not automatically strengthen an old connection.

This check applies to API requests, token refreshes and again immediately before supplier work. It does not undo already confirmed supplier results. Retain the original receipt for an interrupted change and use the documented recovery route; do not create a replacement request to bypass the verification requirement.

A standalone service connection remains a separate machine identity with its own company binding, permissions, expiry and revocation. It does not silently become a personal connection or gain authority for actions that require human verification.

For AI agents

For AI agents: personal grants must satisfy the current global identity factor policy, including active memberships in other available companies. Reconnect through actual portal verification when step_up_required or OAuth access_denied indicates changed policy. Refreshing or enrolling a factor cannot upgrade the authentication method of an existing grant. Preserve original operation receipts and recovery requirements. Never replace the grant with customer impersonation or a machine identity to bypass human verification.

Treat Exchange as unavailable in this release, including existing credentials, imports, provider administration, product and pricing changes, single quotes, mixed baskets, pending API work and service renewal. Do not suggest Exchange commands, alternative grants, manual raw API calls or new idempotency keys to bypass this exclusion. The current capability catalogue and OpenAPI specification are authoritative; older Exchange implementation files are future integration reference material.

The removed legacy balance and top-up feature does not exist in the API or CLI. Customer impersonation is portal-only: administrators must use their own genuine administrator identity and current permissions for API/CLI access. Never synthesize customer sessions or suggest browser impersonation as an API token workflow.

Use the API guide, CLI guide and agent guide for available workflows. Company membership, current permissions, strong verification and original-operation recovery requirements continue to apply.