Create groupAdded in 8.8
POST/groups
Strongly Consistent About endpoint data consistency
Create a new group.
The supplied groupId is validated against ^[a-zA-Z0-9_~@.+-]+ (max 256 characters) by IdentifierValidator.validateIdin the runtime. This strict validation applies wherever the Groups API is available: in OIDC deployments that setcamunda.security.authentication.oidc.groupsClaim the Groups API (including this endpoint) is disabled entirely, so group CRUD never sees externally-minted IdP IDs. The BYOG relaxation only loosens validation when a group is referenced *as a member* of a role or tenant (assignRoleToGroup, assignGroupToTenant); group CRUD itself always uses the strict default-id regex. The constraint is not advertised on the GroupId` schema so that the same schema can be reused at
member-reference sites without falsely rejecting
externally-minted IdP group IDs there.
Request
Responses
- 201
- 400
- 401
- 403
- 409
- 500
- 503
The group was created successfully.
The provided data is not valid.
The request lacks valid authentication credentials.
Response Headers
Forbidden. The request is not allowed.
Group with this id already exists.
An internal error occurred while processing the request.
The service is currently unavailable. This may happen only on some requests where the system creates backpressure to prevent the server's compute resources from being exhausted, avoiding more severe failures. In this case, the title of the error object contains RESOURCE_EXHAUSTED. Clients are recommended to eventually retry those requests after a backoff period. You can learn more about the backpressure mechanism here: https://docs.camunda.io/docs/components/zeebe/technical-concepts/internal-processing/#handling-backpressure .