Why contexts differ from API responses
A standardGET /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_tagsandflattened_statuses(flat arrays for easier JSON Logic evaluation)- The current
tierand its progress - Profile attribute objects (
comms,appearance,dates) - Balances, identities, addresses, and preferred and joined location and staff
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:
changesholds the fields that changed, with their new values.originalsholds the same fields with their previous values.
.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 examplecredit.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 withprofile.created, profile.updated, identity.created, and (in nested form) most events that involve a profile. Profile fields sit at the root of the context.
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 withtransaction.created and transaction.updated. The profile is nested under profile, so condition paths become profile.tier_handle, profile.aggregations.spend_12m, and so on.
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 withtransaction-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.
profile and transaction here are fixed summaries specific to this context, not the full profile or transaction context.
Order
Sent withorder.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 withreward.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 withbenefit.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 withcredit.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 withtier.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.
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 withrating.created and rating.updated. When the rating is linked to a transaction, the full transaction is included; otherwise transaction is null.
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 theid or profile_id from the context. Deleted events carry identifiers precisely so you can reconcile against your own copy without a lookup.