Skip to main content
Alforse plans are enforced server-side against a shared feature catalog — not a UI-only toggle. A plan’s features are normalized into a boolean map, and backend entitlement checks (QuotaService.assertFeatureEnabled) gate the corresponding endpoints. If an endpoint in the API Reference mentions a feature flag, that’s what it’s checking.

​
Plans

If you’re integrating directly with the API Reference rather than through the Deals/Console UI, you need at least a business plan.

​
The enterprise_hybrid edition

enterprise_hybrid is a tenant edition, not a plan tier: users still sign in through the Alforse-hosted application, but business data is routed to the customer’s own data plane rather than Alforse’s. The system metadata layer may store tenant metadata, subscription state, license state, feature entitlements, and endpoint health for a hybrid tenant — it must not store contract originals, OCR text, payment records, dynamic field values, or customer-managed secrets.

​
Redemption codes and onboarding

There are two ways a tenant comes into existence:
  1. Assisted onboarding — Alforse prepares the tenant on the chosen plan, typically for sales-assisted onboarding.
  2. Redemption code — a code issued for a specific plan that a prospective customer redeems themselves (POST /auth/redeem), which creates the tenant, the admin account, and an active subscription for the code’s plan in one step.
Public self-service registration without a code (POST /auth/register) exists in the API but is disabled in production (PUBLIC_REGISTRATION_ENABLED=false) and is hard-limited to the free plan when it is enabled.

​
Deployment modes

Private cloud and offline-capable packages require an enterprise self-hosted agreement and an implementation plan with Alforse. Talk to your Alforse contact if you need one of these deployment models.