Skip to main content
A Group is a named set of Profiles you target for messaging, personalisation, and integration. You create a Group Definition once, choose its 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 with POST /groups/definitions. Only name, handle, and type are required.
The response is 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 with GET /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.
A read returns the full definition. Every definition returns the same field set regardless of 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 a static definition, then add and remove Profiles.
1

Add a Profile

The add is idempotent. A Profile that is already an active member returns 200; a newly added Profile returns 201.
2

Remove a Profile

Removal returns 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, set period 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 with GET /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.
The 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.
The current_member_count on a definition counts static members only. It is always 0 for dynamic and favourite groups. To size a dynamic group, read its latest snapshot; to size a favourite group, page the member listing.

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

  • type is immutable. You cannot convert a group between static, dynamic, and favourite. Create a new definition instead.
  • Manual membership is static only. Add and remove calls are rejected with 422 on dynamic and favourite groups. 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 period or absolute_expiry later does not reschedule memberships already created.
  • current_member_count is static only. It stays 0 for 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 static or dynamic definition returns 422. 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.