Member groups

Reusable entitlement bundles — which model tiers a team can reach and how much they can spend — applied to endusers without per-person config.

Concept

What a member group is

A member group is a reusable bundle applied to endusers. It sets two things: the allowed model tier classes (budget / mid / premium / ultra — see Plans & Billing) and the weekly and monthly weighted-token caps per member. Give the support team budget + mid models and the research team premium, each with its own spend ceiling.

Manage groups with POST / GET / PATCH / DELETE /anoman/v1/accounts/{id}/member-groups. Caps are counted in weighted tokens, the same billing unit the whole platform uses.

# Create a member group: allowed model tier classes + per-member
# weekly / monthly weighted-token caps.
curl https://api.anoman.io/anoman/v1/accounts/acct_9f2b.../member-groups \
  -H "Authorization: Bearer anm-sk-..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Support team",
    "allowed_tiers": ["budget", "mid"],
    "weekly_weighted_cap": 5000000,
    "monthly_weighted_cap": 15000000
  }'

# List / update / delete:
#   GET    /anoman/v1/accounts/{id}/member-groups
#   PATCH  /anoman/v1/accounts/{id}/member-groups/{group_id}
#   DELETE /anoman/v1/accounts/{id}/member-groups/{group_id}
# Deleting a group that members still belong to → 409 group_in_use.

Not policy groups

Member groups vs policy groups

These are distinct. Member groups govern entitlement and quota — which models and how many tokens. Policy groups govern guardrails — injection, PII, content moderation. A member can be in one of each; they answer different questions.

Delete guard. You can't delete a group while members still belong to it — the request returns 409 group_in_use. Move those members to another group first.

Domain allowlist

Member-domain allowlist

Enduser invites are gated to allowed corporate email domains via PATCH / GET /anoman/v1/accounts/{id}/member-domains. An empty allowlist rejects every enduser invite with 400 no_member_domains, and an email outside the allowlist is rejected with 403. Staff invitations are not domain-gated — only endusers.

# Set the member-domain allowlist. Enduser invites are gated to these
# corporate domains; staff invites are NOT domain-gated.
curl -X PATCH \
  https://api.anoman.io/anoman/v1/accounts/acct_9f2b.../member-domains \
  -H "Authorization: Bearer anm-sk-..." \
  -H "Content-Type: application/json" \
  -d '{ "domains": ["acme.com", "acme.co.id"] }'

# GET /anoman/v1/accounts/{id}/member-domains   → current allowlist
#
# Empty allowlist → enduser invites rejected with 400 no_member_domains.
# Email outside the allowlist → 403.

This stops someone from onboarding a personal Gmail as an enduser on your org's pool. Set the allowlist before you invite managed endusers.

Dashboard

Where to manage it

In the dashboard: Members page → Groups tab (create and edit groups with tier chips and cap inputs) and the Settings tab (the domain allowlist).

Set up your groups

Define model access and spend caps once, then apply them to every enduser you invite.

Open Members Managed endusers