# Events

The Events section contains a chronological log of activities and occurrences performed by users on the platform. This detailed history is useful for tracking and monitoring tasks.

In the events interface, you can view a list of users who have performed tasks, the types of tasks, and when they were carried out.

# Available Filters

To find specific events, use the available filters:

Date: Filter by a specific period or select a start and end date.
Type: Filter by an event type, such as Login, Email delivered or Form response created. The list is dynamic: it only offers the types that already happened at least once in the realm, so a brand new realm sees it almost empty. The full catalog is in Event types.
User: Search for events related to a specific user, or select all users of the realm.

# Listing columns

Each row of the list is an event. These are its columns:

Column	What it shows
User	Name and email of the realm user who generated the event. When the event was not associated with any user, it shows Unregistered User.
Type	Name of the event type, already translated. For example, Login or Order completed.
Description	Realm the event belongs to, with the format `Realm: realm name`.
Origin	Does not apply to realm events: it always shows `-`.
Context	Realm where the event happened.
Created at	Date and time the event was recorded.

To reach this screen, the admin needs the View Events permission on the realm.

# Event detail

Click the user of a row to open Log details, with every piece of data stored alongside the event. event_category, event_action and event_type always show up, which are the category, the action and the type, and so does user_agent, with the browser, the operating system and the device type it was generated from. The rest of the fields depend on the event type.

Two of them are the ones most used when auditing:

authentication_method: method the user logged in with, on session events. It takes the value direct for the realm form, otp for login with code, and saml, openidc, oauth2 or google_oauth2 for identity providers.
impersonator_id and impersonator_name: admin who was impersonating the user when the event happened. They only show up when the action was done during an impersonation, so their presence is the mark that the event was not generated by the user themselves.

# Event types

The type of an event is built from the category and the action that generated it, joined by an underscore: the user category with the login_log action gives the user_login_log type, which the panel displays as Login.

These are the types the platform records on its own, grouped by module. Remember that the Type filter only offers the ones that already happened in the realm.

# Session and account

Type	Label in the panel
`user_login_log`	Login
`user_logout_log`	Logout
`user_login_attempt_failed_log`	Login attempt failed
`user_otp_login_log`	Login with code
`user_otp_login_attempt_failed_log`	Login with code attempt failed
`user_created_log`	User created
`user_created_via_form_log`	User created
`user_created_via_order_log`	User created
`user_created_via_invitation_log`	User created
`user_signup_log`	User signup
`user_updated_log`	User updated
`user_enabled_log`	User enabled
`user_deleted_log`	User deleted
`user_password_reset_log`	User password reset
`user_web_push_subscribed`	WebPush notification subscription

The four creation variants share the User created label and are told apart only by their type: user_created_log is the base type, user_created_via_form_log is the user created by submitting a form, user_created_via_order_log when an order was generated, and user_created_via_invitation_log when they were invited as a participant of an origination. Since all four share the same label, the type is the only thing that tells you how the user came in.

# Email

The email provider generates these when reporting what happened with each delivery.

Type	Label in the panel
`email_delivered_log`	Email delivered
`email_opened_log`	Email opened
`email_click_log`	Email click
`email_dropped_log`	Email dropped
`email_bounce_log`	Email bounce
`email_unsubscribed_log`	Email unsubscribed
`email_spam_report_log`	Email spam report

# Notifications

Type	Label in the panel
`notification_opened_log`	Notification opened

# Forms

Type	Label in the panel
`form_response_created_log`	Form response created
`form_response_updated_log`	Form response updated

# Origination

Type	Label in the panel
`origination_submission_created_log`	Origination submission created
`origination_submission_started_log`	Origination submission started
`origination_submission_canceled_log`	Origination submission canceled
`origination_submission_completed_log`	Origination submission completed
`origination_submission_task_submitted_log`	Origination submission task submitted
`origination_submission_task_updated_log`	Origination submission task updated
`origination_submission_task_validation_deleted_log`	Origination submission task validation deleted
`origination_task_response_started_log`	Origination task response started
`origination_task_response_completed_log`	Origination task response completed
`origination_task_response_auto_completed_log`	Origination task response automatically completed
`origination_task_response_reopened_log`	Origination task response reopened
`origination_invitation_invitation_sent_log`	Origination submission invitation sent
`origination_invitation_invitation_resent_log`	Origination submission invitation resent
`origination_invitation_invitation_cancelled_log`	Origination submission invitation cancelled

The emails of an origination submission have their own types, with the same seven situations as the ones from the email module:

Type	Label in the panel
`origination_submission_email_delivered_log`	Submission email delivered
`origination_submission_email_opened_log`	Submission email opened
`origination_submission_email_click_log`	Submission email click
`origination_submission_email_dropped_log`	Submission email dropped
`origination_submission_email_unsubscribed_log`	Submission email unsubscribed
`origination_submission_email_spam_report_log`	Submission email spam report

# Orders and payments

Type	Label in the panel
`order_created_log`	Order created
`order_placed_log`	Order placed
`order_placed_error_log`	Order placement error
`order_rejected_log`	Order rejected
`order_rejected_error_log`	Error in rejected order
`order_confirming_log`	Confirming order
`order_completed_log`	Order completed
`order_confirmation_failed_log`	Order confirmation failed
`order_tracking_log`	Order tracking log
`order_tracking_error_log`	Order process error
`tokenized_card_created_log`	Tokenized card created
`tokenized_card_activated_log`	Tokenized card activated
`tokenized_card_removed_log`	Tokenized card removed
`tokenized_card_inscription_failed_log`	Tokenized card inscription failed
`tokenized_card_unsubscription_failed_log`	Tokenized card unsubscription failed

# Identity providers

Type	Label in the panel
`identity_provider_sync_user_failed_log`	Identity provider sync user failed

# Export Events

Check the box next to one or more events and click the Export button, located below the list, to download a file in Excel or CSV format with the selected events.

# Register events from a site

POST SITE_URL/events

Any page of a Modyo site can record its own business events with this call. They land in the same realm Events list as the ones the platform records, and they feed the Insights dashboards, so this is how you instrument the business analytics of your own application.

The request goes to the site URL, not the account one, and it needs the user session in the realm. An event sent without an authenticated user is rejected with 422 and this body:

{
  "errors": ["Anonymous events are not allowed"]
}

# Accepted parameters

The endpoint accepts a closed set of parameters. Any other one you send is silently discarded and the event is stored anyway, with no errors.

Parameter	What it is for
`e_c`	Event category.
`e_a`	Event action.
`url`	URL of the page where the event happened.
`urlref`	URL the user came from.
`link`	URL of the outbound link that was followed.
`download`	URL of the file that was downloaded.
`action_name`	Page title.
`pv_id`	Pageview identifier.
`res`	Screen resolution.
`idgoal`	Goal conversion identifier.
`revenue`	Amount tied to the conversion.
`cp_id`	Campaign identifier.
`em_tp`	Email type.
`em_rec`	Recipient email.
`fr_id`	Form response identifier.
`fr_fid`	Form identifier.
`order_id`	Order identifier.
`order_pm`	Order payment method.
`card_id`	Tokenized card identifier.
`origination_uid`	Origination identifier.
`submission_uuid`	Origination submission identifier.
`task_id` and `task_uuid`	Identifiers of the origination task.
`au_mt`	Authentication method.
`au_err`	Detail of the authentication error.
`pf_net`, `pf_srv`, `pf_tfr`, `pf_dm1`, `pf_dm2` and `pf_onl`	Network, server, transfer, DOM processing, DOM completion and page load times.
`idsite`, `uid`, `ua` and `_id`	Site, user, browser and visitor. Modyo fills them in from the request context, so you do not need to send them.

Besides what you send, Modyo stores the user realm, the request IP and, if an admin is impersonating the user, who they are.

# The event type

The type is not sent: Modyo builds it by joining e_c and e_a with an underscore. An event with e_c=simulator and e_a=quote_requested ends up with the simulator_quote_requested type, and that is the value everything filters and groups by afterwards.

Attention

An event with neither e_c nor e_a is stored, but it stays out of the Events list and of the API: both only show events that have a type. Always send at least e_c.

Attention

Your own types have no translated label in the panel, so the Type column of the list and the title field of the API arrive empty for them. To recognize them, use the event_type field of the event detail.

# Response

With 201, the body returns the event exactly as it was stored: its id, the account_id, the created_at and the info object with the accepted parameters plus the context Modyo filled in.

Tip

The event is stored right away, but it takes a few seconds to show up in the Events list and in the API, because the record is processed in the background. If you are testing your instrumentation, wait a moment before giving an event up for lost.

Tip

Site pages carry a global _paq object already pointing at this same endpoint. It is an internal detail of the platform instrumentation and not a stable contract, so for your own events use the direct call to POST SITE_URL/events.

# Query the events of a user

An application can read the events of the user with the active session through GET ACCOUNT_URL/api/customers/realms/{realm_uid}/events. The full contract is in User events.

← Users Segments →