`huudis.account.service_enabled.v1`

Fires when a workspace opts into a new Forjio service — e.g., enabling plugipay on a workspace that previously only had huudis.

Subscribe if your product wants to react to "this workspace is now my customer" beats — the right moment for product-side onboarding, free-trial provisioning, etc.

Not yet emitted in v1. Audit log carries account.services_enabled.

When it fires

When POST /v1/account/services/enable adds at least one new entry to the workspace's enabledServices. One event per services/enable call, regardless of how many services were added in that call — the payload's services array carries every newly added slug.

Re-enabling an already-enabled service does not fire (the call is a no-op).

Payload

{
  "id": "evt_01KPG…",
  "type": "huudis.account.service_enabled.v1",
  "createdAt": "2026-05-12T23:45:00.000Z",
  "data": {
    "accountId": "acc_01KPG40…",
    "accountName": "Cafe Sumur",
    "services": ["plugipay", "fulkruma"],
    "enabledByUserId": "usr_01KPG…",
    "enabledAt": "2026-05-12T23:45:00.000Z",
    "currentServices": ["huudis", "plugipay", "fulkruma"]
  }
}

services is the newly added subset. currentServices is the full post-enable list (always includes huudis).

Handler examples

// Node — provision a free-tier customer in our own product
if (event.type === 'huudis.account.service_enabled.v1' && event.data.services.includes('plugipay')) {
  const a = event.data;
  await plugipay.customers.create({
    accountId: a.accountId,
    primaryContact: await huudis.users.get(a.enabledByUserId),
  });
  await onboardingEmail.send(a.accountId);
}

# Python
if event["type"] == "huudis.account.service_enabled.v1":
    a = event["data"]
    if "plugipay" in a["services"]:
        plugipay.provision_workspace(a["accountId"])

What to do

Provision your product-side workspace state, keyed by accountId.
Send a "welcome to {your product}" email to the enabling user.
Start a free-trial timer if you offer one.

Avoid:

Assuming the user is technical. The enabling user is often the workspace owner, not an integrator; first-touch emails should be onboarding-y, not setup-y.
Charging immediately. Service enable is a free action; billing only kicks in after the user upgrades from your product's portal.

Common pitfalls

enabledByUserId may not be the workspace owner. Admins can enable services too. Look up the workspace's owner separately if your onboarding email should specifically address them.
Multiple services in one call. Customer might enable Plugipay + Fulkruma + Ripllo simultaneously (common for "Forjio bundle" sign-ups). One event covers all three; iterate services if you need per-service hooks.
Disabling is a separate, not-yet-emitted event. Subscribe to huudis.account.service_disabled.v1 defensively.

huudis.account.created.v1 — the workspace was created first; service enable typically follows shortly after.
huudis.account.service_disabled.v1 — reserved, not yet emitted.

Services resource — the enable/disable API.
Webhook subscriptions — subscription management.

huudis.account.service_enabled.v1