//#region src/hooks/useAccountApiDomain.d.ts
/**
 * Resolves the absolute origin of the account API
 * (`https://account.<portal-domain>`) from the canonical portal config
 * rather than the browser host.
 *
 * Canonical chain (mirrors `resolveDashboardApiUrl` in portal-plugin-dashboard
 * and the SDK/dataProvider base-URL wiring in portal-framework-core):
 *
 *   Config({ portalServer }) → portalConfig.domain → `/api/meta` served by
 *   the vite middleware → framework.portalUrl (PortalMeta.domain) →
 *   getApiBaseUrl({ currentUrl: portalUrl }) → API root host, with the
 *   service subdomain from the dashboard plugin meta.
 *
 * One root host is resolved and the `account.` subdomain is prepended in both
 * the canonical (config-loaded) and fallback (browser-derived) paths, so the
 * two can never diverge:
 *
 * - When config is loaded, `getApiBaseUrl` resolves the canonical root from
 *   `portalUrl` (no subdomain stripping needed — it is already the root).
 * - Before config loads, `getApiBaseUrl` derives the API base from the
 *   browser location and strips the dashboard subdomain down to the root
 *   (matching `getAccountSubdomain`'s root-domain logic), then the same
 *   `account.` prefix applies.
 *
 * Passing `preserveSubdomain` is deliberately omitted: `getApiBaseUrl`
 * already merges its value with `env.VITE_PORTAL_DOMAIN_IS_ROOT` via `||`, so
 * the hook riding that flag would be a no-op that can never influence the
 * result. Root-mode and non-root mode behavior flows from the env/default
 * inside `getApiBaseUrl`. The protocol and port of the resolved base are
 * preserved (dev localhost keeps `http` and its port for the
 * `account.localhost:<port>` vhost).
 */
declare function useAccountApiDomain(): string;
//#endregion
export { useAccountApiDomain };
//# sourceMappingURL=useAccountApiDomain.d.ts.map