VariaOS is headless and API-first — it connects to the systems you already run instead of replacing them. Below is what connects, and an honest split of what's live today versus in development.
REST endpoints for single and bulk orders. Idempotent by order id, so retries never double-count. Any commerce system can post orders to it.
API reference →Per-tenant JSONPath templates normalise any source payload to the canonical order schema — with a validated transform allow-list and a dry-run validator. No code required.
Per-tenant single sign-on for the admin portal via OpenID Connect: Microsoft Entra ID, Okta, Google Workspace, Auth0, and Ping. JIT user provisioning; live-validated end-to-end against Microsoft Entra ID. SAML on request.
Drop-in Web Components for balance, tier, credit, redemption, and history — MIT-licensed, zero build step. The hosted Widget Token backend is in development, so live data is coming; the components work in mock mode today.
Widgets →A Model Context Protocol endpoint for AI agents: per-tenant machine credentials, read-scoped tools over balances and activity, tenant-bound and fail-closed. Provision, rotate, and revoke from the portal — every access audited.
Change-data-capture feeds to Snowflake, BigQuery, Azure Synapse/Fabric, and Redshift — DPA-gated, PII-excluded, envelope-encrypted. On the enterprise roadmap.
Platform features →The platform-side SFCC connector (order ingestion + accrual guard) is built and in private beta. The purpose-built B2C Commerce (SFRA) cartridge that exports the order lifecycle from the storefront is in development (certification in progress). Enterprise-primary.
Fulfilment, cancellation, and return/refund events reflected in the ledger, with batch support and an accrual-timing policy that avoids double-counting alongside the storefront. Built and tested; enabled per tenant, with payload contracts confirmed at onboarding.
An OAuth app with HMAC-verified webhooks (orders/create, orders/cancelled, refunds/create) mapping to accrual, void, and proportional reversal. Built and tested; enabled per tenant, with live-store validation during onboarding.
However an order arrives — a cartridge, a webhook, a batch, or a direct API call — it follows the same path: normalise, evaluate, record.
Send a source order to the ingestion API; your tenant's mapping template does the rest. (Requires a tenant and an API key — available to private-beta participants.)
curl -X POST https://api.yourtenant.example.com/api/v1/orders \
-H "Authorization: ApiKey <your-api-key>" \
-H "Content-Type: application/json" \
-d '{
"order_no": "1001",
"creation_date": "2026-06-30T14:22:05Z",
"currency": "USD",
"order_total": 129.95,
"customer": { "email": "jane@example.com", "customer_no": "CUST-778" },
"product_items": [ { "sku": "SKU-1", "quantity": 2, "price": 49.99 } ]
}'
Re-sending the same order_no is a safe no-op — the ledger dedupes by order id, so webhook redelivery and reconciliation never double-count.
Each tenant configures one identity provider; admins sign in with "Continue with [IDP]" over a standard OpenID Connect authorization-code + PKCE flow, with just-in-time user provisioning. Supported today: Microsoft Entra ID, Okta, Google Workspace, Auth0, and Ping (OIDC). SAML is available on request.
Join the private beta for API access and to get a connector prioritised, or explore the developer docs and the open-source widgets.