Services

A service is one of the first-party Forjio products — huudis, plugipay, storlaunch, fulkruma, ripllo, linksnap, pawpado, catentio. Each workspace carries an enabledServices array; entries on that list cause:

The product's first-party OIDC client (e.g. plugipay-portal) to appear in the workspace's OIDC clients list.
The product's system policies (e.g. PlugipayAdmin) to appear in the workspace's policies list and become attachable.
The product's audit-log events to be visible in the workspace's audit feed.
The product's billing to be activated (per-product subscription, separate from Huudis's own).

Removing a service from the list reverses all four — the products stop appearing in the dashboard, their policies become unattachable, and billing for that product is canceled at period end.

The baseline service huudis is always enabled and cannot be disabled — you're always a Huudis tenant.

All endpoints require a bearer admin JWT — see Authentication.

Endpoints

Method	Path	Purpose
`GET`	`/v1/account/services`	List enabled services for the active workspace
`POST`	`/v1/account/services/enable`	Add services
`POST`	`/v1/account/services/disable`	Remove services (`huudis` ignored)

Only owner and admin can mutate.

List enabled services

GET /v1/account/services

Response

{
  "data": {
    "services": ["huudis", "plugipay", "fulkruma"]
  }
}

huudis is always first in the list.

Enable services

POST /v1/account/services/enable

Request body

Field	Type	Required	Description
`services`	string[]	yes	One or more service slugs to add. Must match `/^[a-z][a-z0-9-]*$/`.

The operation is idempotent — services already on the list are kept; the response always returns the merged set.

Response — 200 OK. The updated list.

Errors

Status	`error.code`	When
`400`	`VALIDATION_ERROR`	A slug doesn't match the allowed pattern.
`403`	`FORBIDDEN`	Caller isn't `owner`/`admin`.
`400`	`NO_ACTIVE_WORKSPACE`	Bearer token has no active workspace.

Disable services

POST /v1/account/services/disable

Request body

Field	Type	Required	Description
`services`	string[]	yes	Services to remove. `huudis` is silently ignored.

Services not on the list are no-ops.

Response

{ "data": { "services": ["huudis", "fulkruma"] } }

Disable does not cancel an active paid subscription to that product — it merely removes the visibility flag. Cancel the product subscription separately from the product's own dashboard, or the next billing cycle will still charge. We're considering a "danger zone" cascade for a future release; the current cautious split prevents accidental cancellations.

Recognised services

Slug	Product
`huudis`	Always on. The IdP itself.
`plugipay`	Payment infrastructure (xenPlatform-primary, BYO Xendit/Midtrans/PayPal).
`storlaunch`	Storefront platform.
`fulkruma`	Order/inventory backend.
`ripllo`	Marketing & lifecycle (extracted from Storlaunch).
`linksnap`	URL shortener.
`pawpado`	GPU instance portal.
`catentio`	Agent platform.

Enabling a service that doesn't exist on this Huudis instance is silently accepted — the slug is stored but no first-party client/policy materialises until the service is registered. Useful for pre-provisioning, but expect quiet behavior.

Effects of enable / disable

Enable adds:

The product's first-party OIDC client appears in the workspace's clients list, and OIDC sign-ins to that client succeed.
The product's system policies appear in the workspace's policies list (Plugipay*, Storlaunch*, etc.).
The product's audit-log events flow into the workspace's audit feed.
A free-tier subscription is auto-provisioned in the product's billing system (the product's own Stripe/Plugipay).

Disable removes:

The first-party client disappears from the clients list. Existing consents stay in the database (the user keeps their usr_…); they just won't see the client surfaced.
The system policies disappear from the policies list. Existing attachments stay in place — the policy is still attached, just hidden. Re-enable the service and the attachments resurface untouched. This is a deliberate "don't accidentally lose configuration" choice.
The audit-log events stop appearing in the feed.
Billing for the product is not auto-canceled — you must cancel in the product's own surface.

Common workflows

Onboarding new product. Enable the service, then go through the product's own onboarding from its portal at plugipay.com/storlaunch.com/etc.
Trial wind-down. Cancel the subscription in the product's portal first, then disable the service. The order matters — reversed, you'd still be paying for a product you've hidden.
Per-environment isolation. Create separate workspaces with disjoint service sets ("Production with all enabled", "Staging with only Plugipay enabled").

Events

Event type	Fires on
`huudis.account.service_enabled.v1`	`POST /v1/account/services/enable` adds at least one new service.
`huudis.account.service_disabled.v1`	A service is removed. Reserved — not yet emitted in v1.

Audit-log entries: account.services_enabled and account.services_disabled.

Workspaces — the parent.
OIDC clients — first-party clients show up here when services are enabled.
Billing — Huudis's own plan (separate from per-product billing).