Skip to documentation

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.

Renewal forecast

The API and portal share a readable overview of active service periods for domain registrations, Hosting, Exchange and spam filters. The displayed price is an estimate based on the current product catalog. Existing payment agreements, subscriptions, invoices and actual invoice lines remain authoritative. This overview creates no order, invoice, payment or supplier request.

Viewing your own company

Use GET /api/v1/accounts/{account}/billing/renewal-forecast with billing:read. The connection sees only the selected authorized company and its explicitly permitted resources. An invoice restriction does not grant access to a domain or mailbox forecast with the same numeric ID.

Parameters are limit from 1–100 (default 20), horizon_days from 1–366 (default 31) and the cursor from the previous response. The period starts on the current calendar day. Cancelled services, DNS-only zones without a registration and private or deleted Exchange mailboxes are not shown as customer products due for renewal. Spam filters use the same ownership check and count only enabled products.

binadit billing renewal-forecast list --account 123 --horizon-days 31 --output json

An example row:

{
  "id": "renewal:domain:42",
  "source": "service_period_forecast",
  "resource_type": "domain",
  "resource_id": "42",
  "account_id": 123,
  "name": "example.test",
  "period_ends_on": "2026-11-01",
  "binding_status": "verified_company",
  "pricing_source": "current_catalog_estimate",
  "invoice_id": null,
  "payment_available": false,
  "pricing_available": true,
  "currency": "EUR",
  "estimated_price_excl": "12.50",
  "estimated_price_incl": "15.13",
  "period_months": 12,
  "estimated_next_period_ends_on": "2027-11-01",
  "catalog_products_active": true
}

This is an illustration, not an actual quote. A missing or invalid product price, currency or period produces pricing_available: false; no amount is invented. A product no longer active for new sales may still belong to an existing service; catalog_products_active exposes that distinction. The estimate does not change the existing contract price.

IDs and actual payments

Treat the renewal:… ID as an opaque identity in a separate namespace. It is not an invoice ID, historical transaction number, payment code or new order. Never use it as an invoice payment argument. The metadata states source: service_period_forecast and not_an_invoice: true.

Actual invoices are under billing/invoices. An existing invoice owned by the company can be paid through the existing secure billing/invoices/{invoice}/pay flow. New orders and explicit product changes still require reviewed quotes and their corresponding confirmation. The historical billing/upcoming-transactions collection is separate legacy administration; those rows are not replaced by this forecast or mapped as invoices.

In the portal, the dashboard and Renewal forecast use the same new read overview. The old button pointing to an unimplemented payment page has been replaced by a link to actual invoices. The calculation performs no legacy balance processing or direct debit.

Internal platform overview

GET /api/v1/accounts/{account}/admin/billing/renewal-forecast requires admin:read, enabled administration features and an actual internal administrator with recent passkey verification. An owner or service connection gains no platform rights through this endpoint.

binadit admin billing renewal-forecast list --account 123 --horizon-days 90 --output json

A missing, archived, blocked or ambiguous company binding is shown as requires_reconciliation, without a price or guessed new account ID. This gives support a concrete source resource to investigate; it grants no permission to create an invoice for another company. The portal administrator retains the existing browser policy; the public administrator API separately requires recent passkey verification.