type, then manage membership according to that type. This guide covers creating a definition, running a static group end to end, and reading members for any group. For the model behind groups, see the Groups concept.
All endpoints are bearer authenticated and live under https://api.[tenant].getomneo.com/api/v3.
Choose a group type
Every Group Definition has one of three types. The type sets how membership is determined and which endpoints you use to manage it.Create a Group Definition
Create a definition withPOST /groups/definitions. Only name, handle, and type are required.
201 with the created definition, including its id, which you use in the membership endpoints below.
Dynamic groups add query and rule fields; favourite groups add
source_type and source_id. Those are covered on the sibling pages.
The
type is set when the definition is created and cannot be changed afterwards. To move membership to a different mechanism, create a new definition of the type you want.Read, update, and delete a definition
Read a single definition withGET /groups/definitions/{group}, change it with PUT, and remove it with DELETE. PUT accepts the same fields as create, except type, which is fixed once set. DELETE returns 204 and removes the definition together with its membership records.
type; fields that do not apply to the group’s type are null or empty. The response below is the static group created above.
Run a static group
A static group is a list you manage directly. Create astatic definition, then add and remove Profiles.
1
Add a Profile
200; a newly added Profile returns 201.2
Remove a Profile
404 when the Profile has no active membership in the group, so a 404 here means there was nothing to remove.Direct add and remove apply to
static groups only. Dynamic membership is computed from rules, and favourite membership is managed per Profile through the profile-scoped endpoints.Expire memberships
To make static memberships expire, setperiod and period_type on the definition, or set an absolute_expiry date. Each membership’s expiry is calculated once, at the moment the Profile is added.
period_type accepts days, weeks, months, years, absolute_date, absolute_week, or absolute_month. Use absolute_expiry when every membership should end on the same fixed date rather than a period counted from when each Profile joined.
Read members
List a group’s members withGET /groups/definitions/{group}/profiles. One endpoint returns members for every group type in the same shape, so consumers do not branch on type.
Each row has the same wrapper for every type: a
profile_id, a record_type that tells you which membership mechanism produced the row, and a record holding the underlying membership object. The example below is a static group, so every row is a group_profile.
record_type depends on the group’s type, and record carries the corresponding resource.
The listing is paginated. Page through
meta.pagination as with every Omneo list endpoint.
Worked example: a static VIP list
This walks a static group from creation to a running, expiring list.1
Create the definition
POST /groups/definitions with type: "static", period: 30, and period_type: "days". The response is 201 and includes the new id, for example 17. Every membership added from now on expires 30 days after it is added.2
Add members
POST /groups/definitions/17/profiles with a profile_id for each customer. A first add returns 201; re-adding the same Profile returns 200 without creating a duplicate. Pass source_type and source_id to record the import or system the membership came from.3
Read the current list
GET /groups/definitions/17/profiles returns group_profile rows and meta.pagination. GET /groups/definitions/17 shows current_member_count for a quick size.4
Remove a member
POST /groups/definitions/17/profiles/{profile}/remove ends the membership. If that Profile is not an active member, the call returns 404, so a 404 here means there was nothing to remove.5
Act on changes
Subscribe to
group.profile.add and group.profile.remove through a Reaction to message customers as they join or leave, including when a membership expires.Errors
Edge cases and gotchas
typeis immutable. You cannot convert a group betweenstatic,dynamic, andfavourite. Create a new definition instead.- Manual membership is static only. Add and remove calls are rejected with
422ondynamicandfavouritegroups. Dynamic membership is computed from rules; favourite membership is managed per Profile. - Expiry is fixed at add time. A membership’s expiry is calculated once, when the Profile is added. Changing
periodorabsolute_expirylater does not reschedule memberships already created. current_member_countis static only. It stays0for dynamic and favourite groups even when they have members. Size those from the member listing or the latest snapshot.- Instances are favourite only. Creating a profile-owned instance of a
staticordynamicdefinition returns422. See Favourite groups.
Subscribe to group events
Membership and definition changes emit events you can act on through Reactions and webhook Targets.
For example, subscribe to
group.profile.add to send a welcome message when a customer enters a VIP group, or to group.profile.remove to revoke access when they leave.
Next steps
Building dynamic groups
Compute membership from a candidate query and reusable inclusion and exclusion rules.
Favourite groups
Give each Profile its own set, resolved from that Profile’s connections.
Related
- Groups concept
- Building dynamic groups
- Favourite groups
- Reactions
- Targets
- Group Definition API
- Add Group Definition API
- Browse Group Definitions API
- Read Group Definition API
- Edit Group Definition API
- Delete Group Definition API
- Add a Profile to a static group API
- Remove a Profile from a static group API