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, andhuudis.account.member_added.v1for the same user in quick succession. Handle each idempotently; deliveries aren't strictly ordered. - Role changes don't fire this event. Promoting from
membertoadminis a different operation; subscribe tohuudis.account.member_role_changed.v1(reserved, not yet emitted). - Member removal is also a separate event.
huudis.account.member_removed.v1is reserved but not yet emitted; the audit log carriesaccount.member_removedmeanwhile.
Related events
huudis.user.created.v1— the user-creation that may precede member-added for fresh users.huudis.account.created.v1— the workspace-creation that precedes member-added for the founder.
Next
- Users resource — the admin API.
- Workspaces — the parent.