huudis.account.member_added.v1

Fires when a user joins a workspace — either via direct-add (POST /v1/iam/users) or via accepting an invite.

Subscribe if you mirror Huudis workspace membership into your own product (typical for products with seat-based billing or per-workspace user provisioning).

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

When it fires

When a new account_member row is created:

  • Direct add from /v1/iam/users (succeeds with an existing Huudis user that wasn't yet a member, or with a brand-new user).
  • Invite accept at /v1/iam/invites/accept.
  • Workspace creation — the creator becomes the first owner; this event fires alongside huudis.account.created.v1.

Payload

{
  "id": "evt_01KPG…",
  "type": "huudis.account.member_added.v1",
  "createdAt": "2026-05-12T23:30:00.000Z",
  "data": {
    "accountId": "acc_01KPG40…",
    "accountName": "Cafe Sumur",
    "userId": "usr_01KPG…",
    "userEmail": "recruit@forjio.com",
    "userName": "Recruit",
    "role": "member",
    "joinedAt": "2026-05-12T23:30:00.000Z",
    "addedVia": "invite_accept",
    "addedByUserId": "usr_01KPG30SP…"
  }
}
Field Meaning
addedVia direct_add | invite_accept | workspace_creation
addedByUserId The admin who triggered the add. Same as userId when addedVia: "workspace_creation".

Handler examples

// Node — mirror to product's own member table
if (event.type === 'huudis.account.member_added.v1') {
  const m = event.data;
  await db.members.upsert({
    huudisAccountId: m.accountId,
    huudisUserId: m.userId,
    role: m.role,
    joinedAt: m.joinedAt,
  });
  if (m.role === 'owner') {
    await billing.markPrimaryContact(m.accountId, m.userEmail);
  }
}
# Python
if event["type"] == "huudis.account.member_added.v1":
    m = event["data"]
    db.members.upsert(huudis_account_id=m["accountId"], huudis_user_id=m["userId"], role=m["role"])

What to do

  • Mirror the membership in your own product's member table.
  • For seat-based billing, increment your seat counter and re-evaluate plan limits.
  • Send a "welcome to {product}" email if this is the user's first time the workspace's service got enabled for their account.

Avoid:

  • Emailing the user from your side AND letting Huudis email them. Pick one.
  • Treating "owner" as superuser everywhere. Your product may want its own permission model layered on top.

Common pitfalls

  • Race with workspace-created. When a user signs up, you'll receive huudis.user.created.v1, huudis.account.created.v1, and huudis.account.member_added.v1 for the same user in quick succession. Handle each idempotently; deliveries aren't strictly ordered.
  • Role changes don't fire this event. Promoting from member to admin is a different operation; subscribe to huudis.account.member_role_changed.v1 (reserved, not yet emitted).
  • Member removal is also a separate event. huudis.account.member_removed.v1 is reserved but not yet emitted; the audit log carries account.member_removed meanwhile.

Next