groups
Manage end-user access groups. A group bundles roles (_roleIds) and direct MCP-server grants (resourceGrants); member end users receive the union. Memberships are edited from the group side with add-members/remove-members, taking access-record ids (ashareIds) from end-users list.
REST API: Groups
celigo groups <subcommand> [args] [flags]Supports all global flags.
Subcommands
list
List all groups.
get <id>
Fetch one group by ID.
create
Create a group from a JSON body (--file <path> or stdin).
update <id>
Full replace from a JSON body (--file <path> or stdin); destructive PUT.
set <id> key=value …
Safe field edit (GET → modify → PUT). Supports key=file://<path>.
delete <id>
Delete a group.
add-members <groupId> <ashareIds...>
Add end users to the group as manual memberships.
remove-members <groupId> <ashareIds...>
Remove manual memberships from the group.
celigo groups list
List all groups. Rows are trimmed to _id, name, and the table columns client-side (the endpoint rejects server-side field projection); use --fields all for complete documents.
Signature
Arguments
None.
Flags
--fields <spec>
string
default
Fields to return per row. default returns _id, name, and the table columns; all returns complete documents; a comma-separated list requests specific fields. Applied client-side — see field projection.
Default table columns: _id, name, description, hasIdpSyncedMembers, lastModified.
Example
Corresponds to: GET /v1/groups
celigo groups get <id>
Fetch one group by ID, including its _roleIds, resourceGrants, and membership metadata.
Signature
Arguments
<id>
string
Yes
Group ID (the _id from groups list).
Example
Corresponds to: GET /v1/groups/{_id}
celigo groups create
Create a group from a JSON body. Read the body from a file with -f, --file (recommended), or pipe it on stdin. Group names are unique per account — a duplicate is rejected with 409 Conflict.
Signature
Flags
-f, --file <path>
string
—
Read the JSON body from a file instead of stdin (--file - also means stdin).
Request body
A JSON object matching the POST /v1/groups request schema: name (required, unique per account), optional description, _roleIds[] (roles every member receives), and resourceGrants[] (direct MCP-server grants — each entry names one server via _resourceId, or omits it for a wildcard across all, plus a capabilities[] list of tool:all, tool:<id>, api:all, api:<id>, or pset:<permissionSetId> values).
Example
Corresponds to: POST /v1/groups
celigo groups update <id>
Full replace of a group from a JSON body (--file <path> or stdin).
⚠️
updatereplaces the entire group.PUTerases any field you omit —description,_roleIds,resourceGrants.GETthe group first, edit it, then send the complete object back, or usesetfor targeted edits.
Signature
Arguments
<id>
string
Yes
Group ID.
Flags
-f, --file <path>
string
—
Read the JSON body from a file instead of stdin (--file - also means stdin).
--force
boolean
false
Submit even if the body contains masked credential values (***) copied from a GET.
Example
Corresponds to: PUT /v1/groups/{_id}
celigo groups set <id> [assignments...]
Edit one or more fields on a group without rewriting the whole document. Performs GET → apply assignments → PUT, so omitted fields survive. Dot and array-index notation are supported; key=null removes a field; key=file://<path> loads a value from a file.
Signature
Arguments
<id>
string
Yes
Group ID.
[assignments...]
key=value pairs
Yes (≥1)
Field assignments, e.g. description="EU support" or _roleIds[1]=null. Values are JSON-parsed.
Example
Corresponds to: GET /v1/groups/{_id} then PUT /v1/groups/{_id}
celigo groups delete <id>
Delete a group by ID. Prompts for confirmation unless -y is passed. Members lose whatever access they received through this group; their other groups, roles, and direct grants are untouched.
Signature
Arguments
<id>
string
Yes
Group ID.
Flags
-y, --yes
boolean
false
Skip the confirmation prompt.
Example
Corresponds to: DELETE /v1/groups/{_id}
celigo groups add-members <groupId> <ashareIds...>
Add end users to the group as manual memberships. Takes up to 100 access-record ids per call. Requires full mode — membership changes rewrite who can access your MCP servers.
Signature
Arguments
<groupId>
string
Yes
Group ID.
<ashareIds...>
string (variadic)
Yes
End-user access-record ids from end-users list (up to 100).
Example
Corresponds to: POST /v1/groups/{groupId}/members
celigo groups remove-members <groupId> <ashareIds...>
Remove manual memberships from the group. IdP-synced memberships (source: idp) cannot be removed here — change the IdP group mapping instead. Requires full mode.
Signature
Arguments
<groupId>
string
Yes
Group ID.
<ashareIds...>
string (variadic)
Yes
End-user access-record ids to remove (up to 100).
Example
Corresponds to: POST /v1/groups/{groupId}/members/remove
Gotchas
Group names are unique per account. Both
createand a rename viaupdate/setare rejected with409 Conflicton a duplicate.updateis a full PUT. A body that omitsdescription,_roleIds, orresourceGrantserases them. Prefersetfor single-field changes.Memberships are edited from the group side. There is no per-end-user membership command — pass ashareIds from
end-users listtoadd-members/remove-members.IdP-synced memberships are read-only here. Memberships with
source: idpcome from your IdP's group mapping and can only be changed there;remove-membersonly removes manual memberships.hasIdpSyncedMemberson the list output tells you which groups have them.A wildcard grant omits
_resourceId. AresourceGrants[]entry without_resourceIdapplies its capabilities across every MCP server on the account.Membership and structural changes require
fullmode.add-members,remove-members,create,update,set, anddeleteall change end-user access.listandgetwork inreadmode. See Profiles & regions.
Related
end-users — the members;
listsupplies the ashareIds these commands take.roles — the reusable grant sets a group bundles via
_roleIds.mcp-servers —
assign-groupsreplaces a group's grant for one server from the server side.
Last updated
Was this helpful?