Skip to main content
An Event Context is the payload Omneo provides when an event fires, delivered through a webhook or a reaction. It differs from a standard API response: it includes enriched, related data alongside the triggering object so your handler can act without making extra API calls back to Omneo. The same context drives both surfaces. A webhook delivers the raw context as its request body. A reaction exposes every field in the context as a variable for filters and target templates.

Why contexts differ from API responses

A standard GET /api/v3/profiles/{id} response returns the profile object. The profile context sent with a profile.updated event also includes:
  • Aggregations (spend_12m, shop_count, and more)
  • flattened_tags and flattened_statuses (flat arrays for easier JSON Logic evaluation)
  • The current tier and its progress
  • Profile attribute objects (comms, appearance, dates)
  • Balances, identities, addresses, and preferred and joined location and staff
Your handler can act on the event without a follow-up call for these related objects.

How a context is built

Every context follows the same shape: the base object for the resource, plus a small set of event-specific keys. changes and originals describe what an update altered:
  • changes holds the fields that changed, with their new values.
  • originals holds the same fields with their previous values.
Not every .updated event carries both keys. Some carry changes only, and a few (such as credit.updated) carry the full object with no change record. The event reference states which applies per event.

The requested_by object

Most contexts also include a requested_by object describing the API token that caused the event. Use it in conditions to skip events your own integration triggered. It can be null for events raised by internal platform processes. See Filtering by event source.
Profile fields can be omitted from a context by tenant configuration. If a profile attribute you expect is absent, check whether it has been excluded for the tenant.

Event reference

Every event below can be used as a webhook trigger or a reaction trigger. Events that share an identical context are listed together, for example credit.updated | credit.extended | credit.released. “Full object” means the base object for that resource, documented under Detailed payloads for the common ones.

Profiles and identity

Transactions and orders

Incentives

Tiers and achievements

Lists, products, ratings, and interactions

Appointments

Groups and connections

Configuration and reference data

A few triggers exist mainly for internal orchestration and are rarely subscribed to directly: profile.before.update, reward.before.notify, aggregation.updated, profile-temporary.created, transaction.received, transaction.sync, transaction.recalculate, and transaction.profile.unattached. They carry the same context as their standard counterpart (for example transaction.received matches transaction.created). Prefer the standard events above.

Detailed payloads

The examples below show representative values, with arrays showing a single element. Every top-level field a context sends is included. Where a field nests another object that is itself a documented context (profile, definition, transaction, items, transactions), the example shows its identifying fields and a note points to the full object. Smaller nested objects that Omneo trims to a fixed set of fields, such as the profile and transaction on a transaction item, are shown in full.

Profile

Sent with profile.created, profile.updated, identity.created, and (in nested form) most events that involve a profile. Profile fields sit at the root of the context.
The comms object carries the full consent matrix. Alongside the fields shown, each channel (email, sms, push, phone, post) has _optout, _bounced, _promo, and per-purpose flags (_discover, _benefits, _reminders, _account, _bookings, _feedback, _location, _service), each with a matching _raw value.
profile.created and profile.updated are not delivered for incomplete profiles (is_completed is false) or system profile types. See Delivery behaviour.

Transaction

Sent with transaction.created and transaction.updated. The profile is nested under profile, so condition paths become profile.tier_handle, profile.aggregations.spend_12m, and so on.
The nested profile on a transaction is a lighter summary than the standalone profile context: it omits custom_attributes, special_hours, and similar profile-only detail, but keeps identity, tier, balances, and aggregations.

Transaction item

Sent with transaction-item.created and transaction-item.sync. The item includes trimmed profile and transaction summaries and the resolved product, so a handler has the item in full context without extra calls.
The nested profile and transaction here are fixed summaries specific to this context, not the full profile or transaction context.

Order

Sent with order.created and order.updated. An Order is the mutable pre-purchase record that becomes zero or more Transactions on finalisation, so the context can carry both its items and any resulting transactions.
profile and staff are the full profile context. Each items entry is the full order item context, and each transactions entry is the full transaction context.

Reward

Sent with reward.created, reward.updated, and reward.extended. A Reward is a dollar-value discount with an expiry, so the instance and its definition both appear.
profile is the full profile context and definition is the full reward definition context. source describes what earned the reward: its shape depends on source_type (transaction_item, transaction, or reward), and it is null when the reward has no source.

Benefit

Sent with benefit.created and benefit.updated. A Benefit is a non-monetary incentive such as a discount voucher, event RSVP, or free product.
definition is the full benefit definition context and profile is the full profile context. source follows the same pattern as rewards.

Credit

Sent with credit.created, credit.updated, credit.extended, and credit.released. Credits are store-issued value with a balance and expiry.
profile, creator_profile, and definition are the full profile and credit definition contexts. source follows the same pattern as rewards.

Tier

Sent with tier.achieved, tier.maintained, and tier-point.created. A Tier is a status level, so the context pairs the profile with the tier definition and current progress.
The profile shown here is the full profile context (see Profile). The related tier events carry a different shape: tier.switched sends new and old tier definitions, and tier.lost sends the profile, the new tier, and the lost definition.

Rating

Sent with rating.created and rating.updated. When the rating is linked to a transaction, the full transaction is included; otherwise transaction is null.
The transaction object is the full transaction context; the fields above are a representative subset. The profile here is a fixed summary of name, email, and identities.

Supporting objects

Some fields nest smaller context objects that recur across events:

Using contexts in reactions

All fields in a context are available as variables in reaction filters and target templates. For profile events the fields sit at the root (tier_handle, aggregations.spend_12m). For events with a nested profile, such as transactions, the paths are prefixed (profile.tier_handle). See JSON Conditions for the reference syntax.

Context versus API response

If you need data the context does not include, such as a full transaction history, make a follow-up API call using the id or profile_id from the context. Deleted events carry identifiers precisely so you can reconcile against your own copy without a lookup.