Events

Complete guide to events in Omnium, including event structure, operation IDs, webhook integration, and subscription management.

Events & Webhooks

For most operations that occur in Omnium, whether executed via API or UI, an event is fired. You can subscribe to these events by registering an event subscriber.

Event Subscribers

An event subscriber listens to events and sends a message to the type of subscribers. Currently, the supported types of subscribers are:

Webhooks
Azure Storage Queues
Azure Service Bus
Apache Kafka

Event subscribers are registered in the Omnium UI. You will find it under Configuration => Event subscriptions. When registering a subscriber, you select which filters you want enabled for the current subscriber, ensuring that you only receive the event messages that interest you.

The example below shows how you would register a webhook subscriber with the following options:

Only order events
With order type: Click and collect
With status: Ready for pickup
With store: BikeSport Drammen

Event Structure

All events in Omnium follow a consistent structure. Here is an example of how the payload would look for an event message:

{
    "timestamp": "2022-12-04T07:23:07.6380021Z",
    "message": "Workflow completed",
    "className": "Order",
    "subClassName": "ClickAndcollect",
    "objectId": "EPIC0001",
    "category": "Workflow",
    "market": "NOR",
    "storeId": "epic_webshop_no",
    "user": "Ola Nordmann",
    "userId": "olanordmann@omnium.no",
    "status": "ReadyForPickup"
}

Event Field Descriptions

id: Unique event identifier generated by Omnium's event system. Used for deduplication and event tracking.
operationId: The numeric operation that categorizes the type of operation (see tables below).
timestamp: UTC timestamp indicating when the event occurred.
message: Human-readable description of what happened in the event.
className: The type of entity involved (Product, Order, Customer, etc.). See EventModelTypeConstants for valid values.
subClassName: Additional classification of the entity (e.g., order type, product type).
objectId: Primary identifier of the main entity involved in the event.
objectNumber: Human-readable identifier (e.g., order number). Usually this equals to objectId
category: Event category for grouping related events (such as "Created" or "Updated")
market: Market identifier where the event occurred.
storeId: Store identifier associated with the event.
user: Username or email of the user who triggered the event.
userId: Unique user identifier.
employee: Name of the employee (for multi-user setup, typically used in store).
employeeId: Employee identifier.
status: Current status of the entity after the event.
previousStatus: Previous status before the event occurred.
isError: Boolean indicating if this event represents an error condition.
isRead: Boolean for tracking if the event has been processed/read.
origin: The source/path that triggered the event (API endpoint, scheduled task, integration, etc.).
tags: Array of tags associated with the entity.
externalIds: External system identifiers for the entity.
properties: Key-value pairs with additional event-specific data.
attachments: Additional data attached to the event (workflow results for instance).
references: References to other related entities.

Event Operation IDs

Event operation IDs are unique numbers that identify different types of operations in Omnium. You use these IDs when subscribing to events to filter for specific operation types.

ID Structure

Event operation IDs follow a structured numbering system:

1x xxxx: Core operations
2x xxxx: Internal API (GUI) operations
3x xxxx: Public API operations
4x xxxx: Provider/Integration operations
5x xxxx: Domain events

Event Examples

Here are some examples of how events are triggered and what data they contain:

Product Update (140105 - PatchProduct)

Trigger: When a product is modified via Public API using the AddProductEvent method

Example:

{
    "timestamp": "2024-11-19T12:41:26.5063272Z",
    "id": "cRhxRJMBexpecWoMJxbJ",
    "operationId": 140105,
    "message": "Patch product",
    "className": "Product",
    "objectId": "sw-4321",
    "category": "Updated",
    "user": "Omniman",
    "userId": "omniman-1b421076-7c40-41da-a185-c5e2e88103ee",
    "isError": false,
    "isRead": false,
    "origin": "PATCH /api/Products/sw-4321"
}

Order Update (210110 - GuiOrderUpdateStatusMultipleWithWorkflow)

Order events track orders from start to finish. Here's an example of an status update for a shipment with ID "2" on an order with Id "901580" :

{
      "timestamp": "2025-10-29T12:27:04.0822953Z",
      "id": "kpzvL5oBTOMIzPDw4ELu",
      "operationId": 210110,
      "message": "Update shipment(2) and run workflow. Old status was New",
      "className": "Order",
      "subClassName": "Online",
      "objectId": "901580",
      "category": "Updated",
      "market": "ENG",
      "storeId": "BikeShopBerlin",
      "user": "J-Dawg",
      "userId": "jdawg@omnium.no",
      "status": "InProgress",
      "previousStatus": "New",
      "isError": false,
      "isRead": false,
      "indexIdentifier": "kpzvL5oBTOMIzPDw4ELu",
      "esMetadata": {},
      "attachments": [
          {
              "value": "2",
              "name": "ShipmentId"
          }
      ],
      "origin": "POST /api/internal/Order/UpdateManyOrdersAndRunWorkflow/",
      "tags": [
          "vip"
      ]
}

How to filter events

By what they affect

Orders: 110xxx, 210xxx, 310xxx
Products: 140xxx, 240xxx
Customers: 130xxx, 230xxx, 330xxx
Inventory: 150xxx, 250xxx, 350xxx
Providers: 40xxxx

By where they come from

Core operations: 1xxxxx
GUI actions: 2xxxxx
API calls: 3xxxxx
Provider integrations: 4xxxxx
Domain events: 5xxxxx

Event Log

On most entities, such as an order, you can inspect the event log in the Omnium UI by pressing the three dots in the top right corner and selecting Log. You can also view specific events for a single order or product by clicking the "Event log" button in the UI. This is also available in most list views.

You can search and browse all logged events in the Omnium UI by going to Configuration → Advanced → Events.

Subscription Result Events

Events will also be generated for the result of event subscriptions. For example, if you've set up a webhook subscription, a failed request event entry will look like this:

{
    "timestamp": "2025-10-17T07:13:45.755505Z",
    "id": "P3gE8ZkBTOMIzPDwg88p",
    "operationId": 290100,
    "message": "Order webhook: POST https://webhook.site/e405f903-ea5b-40d6-b0a0-be801ea162d3.  |Error: . Took: 558 ms",
    "className": "EventSubscription",
    "subClassName": "WebHook",
    "objectId": "901580",
    "category": "Order webhook",
    "user": "System",
    "userId": "System",
    "status": "Failed",
    "isError": false,
    "isRead": false
}

This is useful for inspecting subscription failures. Note that successful requests after retries will not be tracked as failures.

Retry Policies

Our default retry policy is 3 attempts with the following delays: 1 second, 5 seconds, and 15 seconds. This does not apply to responses with status codes 200-299, 404, 400, and 429.