Teams and sharing
Group principals once, then grant datasets and projects to the live roster.
Teams are engine-owned groups inside one organization. Membership names principals, and access is evaluated against the current roster on every check.
Create a team
An organization administrator creates and manages teams:
curl -s "$BASE_URL/v1/teams" \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d '{"name":"Support"}'Use the returned team UUID for membership and grants.
Add a member
Obtain the person's engine principal UUID from their GET /v1/me/usage
response or from the platform administrator. Never use the identity provider's
sub.
curl -s "$BASE_URL/v1/teams/$TEAM_ID/members" \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d "{\"user_id\":\"$PRINCIPAL_ID\"}"Grant a resource
Dataset and project grants accept user, role, and team principals. A team
grant is an upsert: a new grant returns 201; changing or repeating an existing
grant returns 200 and records the old and new permission in audit.
curl -s "$BASE_URL/v1/datasets/$DATASET_ID/grants" \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d "{\"principal_type\":\"team\",\"principal_id\":\"$TEAM_ID\",\"permission\":\"read\"}"The same shape applies under /v1/projects/{id}/grants.
Change or remove access
- Removing a member takes effect on the next authorization check; no token refresh is required.
- Deleting a team removes grants that name it.
- Team grants do not apply to model entitlements. Model grants remain organization, role, or user scoped.
- Only organization administrators mutate rosters. Members may list teams visible to them.