The docs are curated from the implemented platform contract and publish public-safe summaries, API route families, and supported customer guidance.

A tenant is an isolated identity domain on the platform. Each tenant has its own organizations, members, clients, applications, governance rules, and audit trail.

OpenID Connect and OAuth 2.0, including authorization code with PKCE, client credentials for current machine-client scenarios, discovery metadata, and logout handling.

Developer starts at 3 organizations, 3 applications, 1,000 active identities, 10 OAuth clients, 1 environment, and 25 trusted devices. Launch increases to 10 organizations, 5 applications, 2,500 active identities, 25 OAuth clients, 2 environments, and 100 devices. Growth increases to 25 organizations, 15 applications, 10,000 active identities, 100 OAuth clients, 1 enterprise OIDC connection, 3 environments, and 500 devices. Business increases to 100 organizations, 50 applications, 50,000 active identities, 500 OAuth clients, 5 OIDC + SCIM connections, 6 environments, SIEM export, and 5,000 devices. Enterprise uses custom negotiated quotas.

Developer blocks overage and prompts an upgrade. Launch, Growth, and Business include PAYG meters for active identities, organizations, trusted devices, enterprise connections, environments, OAuth client packs, audit storage, and SIEM destinations. Paid self-serve plans start with a default 20% monthly spend cap and notifications at 50%, 80%, and 100%.

Roles, security groups, direct grants, and entitlement-backed seat assignments are part of the current tenant operating model. Commercial packaging is anchored to identity, application, environment, and support scale rather than charging per permission object or policy rule.

The public production posture is one deployable host and one relational database per deployed instance, with logical tenant isolation inside that instance. Per-tenant deployment isolation, region-pinning guarantees, and multi-region active-active commitments remain guided commercial review unless contracted.

The current platform targets PostgreSQL and SQL Server for deployed environments, with SQLite reserved for development and isolated testing scenarios.

Control-heavy buyers should treat dedicated deployment modes, customer-managed key commitments, documented region pinning, and public evidence-inventory workflows as guided commercial review or roadmap scope unless they are explicitly part of a written engagement.

Current positioning is limited to organization-scoped aggregate analytics for authentication activity, audit categories, and device-fleet posture. Counts below the published minimum cohort are intentionally suppressed, and raw telemetry exports or user-level risk scores are not exposed.

Device trust provides a seat-bound activation lifecycle and posture policy engine integrated into the identity layer. Organizations can issue certificate-bound credentials, evaluate explicit posture snapshots, require approval before activation goes live, and issue signed offline leases with renewal and grace policies.

It is supported when the environment enables the device authorization endpoint and a device-flow client has been provisioned. The public docs do not publish a self-service device-client registration route.

Not as a public GA claim. NexinID supports device activation, offline leases, lifecycle audit, certificate credentials, OAuth device authorization when enabled, and mTLS gateway contracts. Zero-touch IoT bootstrap and hardware-backed attestation remain preview or roadmap scope.

NexinID provides a tenant-admin setup path for enterprise OIDC connections, SCIM token rotation, and setup diagnostics today. Growth includes one enterprise OIDC connection, while SCIM lifecycle support starts with Business. Public setup guidance is centralized in the enterprise setup docs.

Current public guide entry points cover Okta, Microsoft Entra ID, Google Workspace, and generic OIDC or SAML providers. OIDC sign-in and SCIM lifecycle paths are the current supportable story.

Not yet. NexinID stores canonical SAML setup data and validates it through diagnostics, but host-side SAML assertion processing is still treated as a current limitation rather than a finished browser runtime.

Current tenant-admin flows include webhook subscription management, one-time secret rotation, delivery status history, and failed-delivery replay. Audit exports support CSV and NDJSON, with NDJSON documented for SIEM-friendly ingestion workflows.

No. The current sandbox panel builds request examples. Keep production tokens, private keys, raw hardware identifiers, voucher bodies, and attestation secrets out of browser-based tools.

Use the contact page for rollout, diligence, commercial onboarding, deployment, or provider-specific support questions.