SaaS interface
Consumers depend on @antelopejs/interface-dms-saas, not the runtime's private services or page controllers. Load @antelopejs/dms-saas in the same AntelopeJS project for functions that need an implementation. Compile with moduleResolution: "bundler", "node16" or "nodenext" so subpaths resolve through the package's exports map.
Entry points
Import after @antelopejs/interface-dms-saas | Contract |
|---|---|
| Root | Billing, data API, pages, plans, provisioning and registration exports; invoiceLineItems and tenantLifecycle namespaces |
/billing | Balances, previews and billing-state recomputation |
/invoice-line-items | Usage providers, line types and key helpers |
/tenant-lifecycle | Durable lifecycle consumers and provisioning gate |
/provisioning, /registration | Provisioning payload and registration limits |
/pages, /page-definitions | Page descriptors and extension registration |
/plans | Plan projections, localization and pricing helpers |
/data-api, /hidden-filter | HiddenStringFilter |
/db, /db/models, /db/tables | Canonical SaaS models and table classes; see the data boundary below |
invoiceLineItems and tenantLifecycle are namespaces at the root, not flat exports. Use their direct subpaths for individual functions. Their internal proxy namespaces are implementation plumbing, not consumer APIs.
import { invoiceLineItems, tenantLifecycle } from "@antelopejs/interface-dms-saas";
export const usageKey = invoiceLineItems.buildInvoiceLineKey("example.compute", "minutes");
export async function mayProvision(tenantId: string): Promise<boolean> {
// Errors propagate: unavailable storage must not grant eligibility.
return tenantLifecycle.IsTenantProvisioningCommitted(tenantId);
}
Database imports have side effects
The root does not re-export db. Importing /db registers the canonical SaaS tables; do not create duplicate table definitions or load the runtime's registration graph to reach them. Prefer import type when only a type is needed. The root also exports plan helpers that import database values, so do not assume that a root value import avoids all transitive table registration. Narrow subpaths express which contract the consumer needs.
Database exports are persistence primitives, not an authorization or billing-service API. Use tenant-scoped models with the correct tenant, and keep direct writes in trusted import/seed code. Direct writes do not automatically perform all Stripe, lifecycle, cache and directory work of the runtime's normal operations.
After seeding or importing subscription records, call RecomputeTenantBillingState for each affected tenant once writes finish. This republishes derived billing and directory state; it does not make an arbitrary direct write equivalent to a normal billing operation. When seeding plans, leave Plan.paymentProviderRefs empty and never overwrite the runtime's Stripe linkage. See the plan and Stripe guide.
workspaceSettingsCategory belongs to @antelopejs/interface-dms/page, not this package. There is no SaaS GetWorkspaceSettingsCategory export. Use /pages for SaaS billing and platform-workspace extension anchors.
The runtime guide covers installation, public screens, UI integration and examples. These pages define the backend consumer contracts.