Skip to documentation
Binadit
Open portal

Exchange will be rebuilt separately and is unavailable through the API or CLI. Availability in this release

Workflow guides

Markdown

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.

Company resources and safe counts

The company detail page, administration API and typed CLI use the same bounded, read-only source for Workspaces, domains, orders, registrar contacts and safe log metadata. These reads make no supplier requests, change no ownership or billing, and do not read credentials, private DNS records, raw log details, IP addresses or encrypted snapshots.

Use a current human internal administrator with admin:read and recent passkey approval. --account is the administration context; the separate company ID is the modern target company, never a legacy user/customer number. Current grant, administrator, context and passkey are checked before and after SQL. Restricted resource grants cannot enumerate another company's global resources.

Portal

Open the company's detail page. Without recent passkey approval the page is a verification shell: it does not preload resources or counts. Verify and open the details, then explicitly select a resource tab or Read current resource counts. An expired proof can be renewed without losing the selected company or search. Cancelling verification sends no resource request.

Each tab has a maximum page size of 100 and forward cursor navigation. Search is available for resource names/descriptions; the log tab accepts an exact event action such as logMsg87. Use the log API/CLI's date filters for a dated selection. The older free-text log-details search is unavailable. The existing member list is capped at its first 100 records; user administration can inspect further memberships per user independently.

Typed CLI

binadit admin companies resources 42 workspaces --account 1 --limit 25 --output json
binadit admin companies resources 42 domains --account 1 --search example --limit 25
binadit admin companies resources 42 orders --account 1 --limit 25
binadit admin companies resources 42 holders --account 1 --limit 25
binadit admin companies resources 42 logs --account 1 \
  --action logMsg87 --from 2026-10-01 --until 2026-10-29
binadit admin companies resource-counts 42 --account 1 --output json

Copy meta.next_cursor exactly to --cursor with the same company, kind and filters. Records are ordered by descending ID; no page-number/offset scan or automatic walk over all company resources occurs. IDs and cursors retain exact signed 64-bit values in the CLI. The client binds the returned company, kind, filters, order and cursor before printing its fixed safe projection. Unknown response fields are dropped. These GETs need no mutation intent or idempotency key.

API

  • GET /api/v1/accounts/{context}/admin/companies/{company}/resources/{kind} where kind is workspaces, domains, orders, holders or logs;
  • GET /api/v1/accounts/{context}/admin/companies/{company}/resource-counts.

Resource queries accept limit (1–100, default 25), a positive descending cursor, and optional search (maximum 200 characters). Logs instead accept only limit, cursor, an exact action (logMsg1–logMsg94), from and until (inclusive UTC calendar dates). The target company is pinned by the path; caller-supplied company overrides, arbitrary fields and raw log search are rejected.

Pages return data and meta with scope: company_resources, company_id, kind, limit, next_cursor, fixed reviewed filters and ownership: verified_bindings_only. Counts return data.company_id, all five integer data.counts values and the same ownership label. The endpoints use Cache-Control: no-store. Unknown/archived companies and invalid selections are refused; lost or expired authority cannot publish selected metadata.

Ownership and history boundaries

Workspaces use their modern company binding and exclude soft-deleted rows. Domains, orders and contacts accept an exact consistent modern owner. A legacy fallback is permitted only when the modern binding is absent and the positive legacy customer number identifies exactly one company, including archived companies in the uniqueness check. A conflicting modern owner, zero/unassigned legacy number or duplicate historical mapping never grants fallback access. Conflicting or ambiguous rows are omitted rather than assigned to a guessed owner.

Logs reuse the safe portal log source and match only the explicit modern company_id. Their legacy_subject_id is a historical diagnostic reference with an unverified namespace; it is not a modern person or company identity. It never selects records or resolves private contact details.

Counts use the same ownership predicates as pages. They describe verified visible records, not readiness to archive a company or evidence that financial liability is absent. Cancellation, permanent deletion, adoption and company ownership transfer retain their own reviewed business guards. Existing invoices and historical responsibility are not rewritten by this inventory.

Order prices are stored descriptive amounts. processed describes order processing, never proof of payment; this inventory does not establish historical currency, paid coverage or a new billing authorization.

Domains that still require an ownership review

The company page's Attach domains search and GET /api/v1/accounts/{context}/admin/companies/{company}/attachable-domains use the same local candidate selection. Unlike the owned-resource inventory, this includes unbound local domains and domains currently assigned elsewhere, even when no registrar inventory object exists. A candidate is never proof of ownership, paid coverage, permission to transfer, or an available registrar operation. Every item and page explicitly reports review_required: true; meta.ownership_verified is false.

Use the Rust CLI's authenticated generic GET, with no new mutation key:

binadit api '/admin/companies/42/attachable-domains?search=example' \
  --account 1 --method GET --limit 25 --output json

The API accepts only limit (1–100, default 25), a positive descending-ID cursor, and optional search (maximum 200 characters). Search is a literal substring; % and _ do not expand to SQL wildcards. Copy meta.next_cursor exactly with the same company and search. Invalid or oversized stored names are omitted; an empty page can still have a forward scan cursor. Domain IDs and cursors retain signed 64-bit precision. The native selector preserves its alphabetical first-50 search and existing reviewed browser links.

Each item contains only id, domainname, review_url, and review_required. No DNS record, provider credential, transfer token or owner contact data is loaded. review_url is a portal review link, not a mutation endpoint. API/CLI agents use the existing ownership-plan and exact transfer contract for the chosen explicit domain ID. The candidate GET changes no ownership, billing or supplier state, sends no mail and allocates no operation. It checks current strong internal-admin authority and the target binding again after the local query commits; lost access cannot publish the selected names.