Skip to main content
POST
Create a user event for rules and fraud detection

Overview

Creates a new user event to track actions and behaviors within your application. Events are used for fraud detection, compliance monitoring, behavioral analytics, and audit trails. The system automatically registers devices, can optionally create entities when they don’t exist, and runs the rules engine to evaluate risk. The response includes rulesResult and rulesExecutionSummary when rules are triggered.
πŸ“‹ Events automatically register devices when deviceId and deviceDetails are provided, eliminating the need for separate device management.

Endpoint

Authentication

Requires a valid API key in the Authorization header:

Query Parameters

boolean
default:"false"
Enable automatic entity creation when an entity with the provided taxId doesn’t exist. When true, if the event includes a taxId and no entity exists with that tax ID, a new person or company entity will be automatically created.Example: ?withAutoEntity=true

Request Body

string
required
Type of event being tracked. Must be one of the supported event types (see Event Types section below), including authentication, transfers, biometric validation, and more.Example: "LOGIN_SUCCESS"
string
Your internal user identifier. Used to group events by user across different entities.Example: "user_12345"
string
gu1’s entity UUID. Provide this if you have the internal gu1 ID.
Entity Identification: You must provide at least ONE of: entityId, entityExternalId, or taxId. These fields support OR logic, so the system will find the entity using any of these identifiers. SDK exception: organizations with the SDK enabled may instead send only a sessionId for anonymous pre-login events.
string
Your external entity identifier. This is your unique ID for the entity in your system.Example: "user_12345"
string
Tax identification number (CPF, CNPJ, CUIT, etc.). When combined with ?withAutoEntity=true, this will create the entity if it doesn’t exist.Example: "20242455496"
string
When the event occurred in ISO 8601 datetime format. If not provided, defaults to the current server time.Example: "2026-01-30T14:30:00Z"
string
Business date for the event. Used by historical rules as the starting point for time windows (e.g. β€œlast 7 days” is calculated backwards from this date).Format: ISO 8601 datetime string with timezone (e.g. "2026-01-30T14:30:00Z" or "2026-01-30T00:00:00.000Z").If you don’t send it: The system uses the same value as timestamp (or the current server time if neither is sent). So the event is treated as β€œnow” for historical rulesβ€”no need to send it when the event is real-time.
  • Omitted β†’ We set eventDate = timestamp (or now). Historical rules use that as the starting point.
  • Format β†’ ISO 8601 with timezone: "YYYY-MM-DDTHH:mm:ss.sssZ" (e.g. "2026-01-30T00:00:00.000Z").
  • When to send β†’ When the event actually happened on a different date than when you’re sending it (e.g. backfilled or batch events).
string
Unique identifier for the device. This should be a stable identifier that persists across sessions.Example: "840e89e4d46efd67"
object
Detailed device information. When provided, the device will be automatically registered or updated.Structure:
string
IP address from which the event originated (IPv4 or IPv6).Example: "10.40.64.231"
string
ISO 3166-1 alpha-2 country code where the event occurred.Example: "AR"
boolean
default:"false"
Whether the connection is through a VPN
boolean
default:"false"
Whether the connection is through a proxy
boolean
New device flag stored on the event (is_new_device in the database). See How isNewDevice works below.
string
SDK session identifier (sess_..., max 64 chars). For organizations with the SDK enabled, an event carrying only a sessionId (no entity identifier) is accepted and persisted as an anonymous pre-login event; it is linked to the entity later on the first event that carries both sessionId and an entity identifier. Without the SDK enabled, an entity identifier is still required.Example: "sess_a1b2c3d4"
object
Structured signals emitted by the SDK (kept separate from free-form metadata). All fields optional: sessionId, sessionDuration, integrityScore (0–100), integrityFlags (fetchHooked, prototypeModified, debuggerAttached, framingDetected), and behavioralSignals (keystrokeAvgMs, pasteDetected, completionTimeMs, touchVelocity).
number
default:"0"
Number of failed authentication attempts (for authentication events)Example: 3
string
Destination account identifier for transfer events (CBU, CVU, etc.)Example: "0170042640000004234411"
string
Destination CUIT for transfer eventsExample: "27281455496"
string
Previous value for credential change events. This will be automatically hashed using SHA-256 for security.Example: "old_password_hash"
object
Additional event-specific data as key-value pairs. Use this for custom fields specific to your use case.Example:
string
Browser user agent string for web eventsExample: "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36..."

How isNewDevice works

The persisted value on each event drives fraud rules (for example historical.userEvent.newDevice and filters like isNewDevice: true on user_events).

Priority: your value wins when you send it

Use the explicit flag when your app already knows whether the session is on a new device (SDK, local storage, your own device registry). Omit it when you want gu1 to infer it from the device registry.

When you omit isNewDevice (server-side inference)

gu1 only auto-computes when both are present:
  • deviceId
  • deviceDetails
Flow:
  1. Register or update the device for the resolved entity (devices table).
  2. Set isNewDevice to true if either:
    • No row exists yet for (organization, entity, deviceId), or
    • The device exists but firstSeenAt is within the last 5 minutes (first-seen window).
  3. Otherwise set isNewDevice to false (device already known to gu1 for that entity).
Send deviceId + deviceDetails on login and security-sensitive events even when you set isNewDevice yourself, so gu1 keeps the device registry up to date for other rules and audits.

Request body field name

POST /events/user uses camelCase in JSON: isNewDevice. The snake_case name is_new_device is not read on this endpoint (use camelCase).

Examples

Client decides (recommended when you already detect new device):
Let gu1 infer (omit the flag; include device payload):

Event Types

πŸ“‹ Choose the most specific event type that matches your use case. Use OTHER_EVENT only when no specific type applies.

Authentication Events

  • LOGIN_SUCCESS - Successful login
  • LOGIN_FAILED - Failed login attempt
  • LOGOUT - User logout
  • TOKEN_GENERATED - Authentication token generated

Credential Change Events

  • PASSWORD_CHANGE - Password successfully changed
  • PASSWORD_CHANGE_FAILED - Failed password change attempt
  • EMAIL_CHANGE - Email address changed
  • PHONE_CHANGE - Phone number changed
  • PIN_CHANGE - PIN changed

Account Management Events

  • ACCOUNT_LINKED - Bank account linked
  • CONTACT_CREATED - Contact created
  • CONTACT_DELETED - Contact deleted
  • ADDRESS_CHANGED - Address updated
  • DEVICE_ADDED - New device added
  • DEVICE_DELETED - Device removed

Email Management Events

  • EMAIL_CREATED - Email created
  • EMAIL_ELIMINATED - Email eliminated
  • NAVIGATION - Page or screen navigation

Transfer Events

  • TRANSFER_SUCCESS - Successful transfer
  • TRANSFER_FAILED - Failed transfer attempt
  • TRANSFER_SCHEDULED - Transfer scheduled for future

Balance Events

  • BALANCE_CHECK - Account balance checked
  • BALANCE_CHECK_FAILED - Balance check failed

Account Access Events

  • ACCOUNTS_VIEW - Accounts list viewed
  • ACCOUNTS_VIEW_FAILED - Accounts view failed

Transaction Events

  • TRANSACTIONS_VIEW - Transaction history viewed
  • TRANSACTIONS_VIEW_FAILED - Transaction view failed

Recipient Events

  • SEARCH_RECIPIENTS - Recipients searched
  • SEARCH_RECIPIENTS_FAILED - Recipients search failed
  • SCHEDULE_RECIPIENT_FAILED - Recipient scheduling failed

Profile Events

  • PROFILE_VIEW - User profile viewed
  • PROFILE_UPDATED - User profile updated

Message Events

  • MESSAGES_VIEW - Messages viewed
  • MESSAGES_VIEW_FAILED - Messages view failed

Account Holder Events

  • ACCOUNT_HOLDERS_VIEW - Account holders viewed
  • ACCOUNT_HOLDERS_VIEW_FAILED - Account holders view failed

Alias Events

  • ALIAS_VIEW - Alias viewed
  • ALIAS_VIEW_FAILED - Alias view failed
  • ALIAS_CHANGE - Alias changed
  • ALIAS_CHANGE_FAILED - Alias change failed

Payment / Device Events

  • CARD_ADDED - Payment card added
  • DEVICE_CONNECTED - Device connected

Biometric Validation Events

  • BIOMETRIC_VALIDATION_SUCCESS - Biometric validation succeeded
  • BIOMETRIC_VALIDATION_ERROR - Biometric validation failed

SDK Events

  • SESSION_STARTED - SDK session beacon (pre-login)
  • SESSION_IDENTIFIED - Session bound to an entity (sent with both sessionId and an entity identifier)
  • SCREEN_VIEW - Screen/navigation tracked by the SDK

Other Events

  • OTHER_EVENT - Custom or generic event

Response

boolean
Indicates if the request was successful
object
The created event object
string
gu1’s internal event UUID
string
Type of event created
string
User identifier
string
Associated entity UUID
string
External entity identifier
string
Tax identification number
string
Event timestamp (ISO 8601)
string
Business date used by historical rules for time windows (ISO 8601). Equals timestamp when not sent.
string
Device identifier
string
IP address
string
Country code
string
Event record creation timestamp
object
Entity information (when auto-created or existing)
string
Entity UUID
boolean
Whether the entity was auto-created by this event
object
Result of rules execution if the rules engine was triggered for this event. Includes:
  • success (boolean) - Whether rules executed successfully
  • rulesTriggered (number) - Number of rules that were triggered
  • alerts (array) - Alerts generated by rules
  • riskScore (number) - Final calculated risk score
  • decision (string) - Final decision (APPROVE, REJECT, HOLD, REVIEW_REQUIRED)
  • rulesExecutionSummary (object) - Detailed summary; see below.
object
Only present when the rules engine ran for this event. Summary of which rules matched (hit) vs did not match (no hit), executed actions, and total score. See Rules Execution Summary for the full structure and a complete example.
  • rulesHit (array) - Rules whose conditions were met. Each item: name, description, score, priority, category, status, conditions, actions.
  • rulesNoHit (array) - Rules evaluated but conditions not met. Same structure as rulesHit.
  • actionsExecuted (object) - Aggregated executed actions: alerts, suggestion, status, assignedUser, customKeys (array of strings, optional) β€” custom action keys from rules that matched (e.g. require_kyc, flag_for_review); for integrations/workflows.
  • totalScore (number) - Sum of score of all rules that hit (excluding shadow).

Examples

Login Event

Transfer Event

Auto-Create Entity

Response Example

Error Responses

400 Bad Request

401 Unauthorized

403 Forbidden

404 Not Found

500 Internal Server Error

Use Cases

Track Authentication Patterns

Monitor Transfer Activity

Compliance Audit Trail

Best Practices

Always Include Timestamps

Provide explicit timestamps when events are queued or buffered to maintain accurate chronological ordering.

Track Both Success and Failure

Always track both successful and failed events for comprehensive fraud detection and analytics.

Use Structured Metadata

Keep metadata consistent across similar event types to enable better analysis and querying.

Device information and isNewDevice

Always include deviceId and deviceDetails when available so gu1 can maintain the device registry. Set isNewDevice explicitly when your integration already classifies new devices; otherwise omit it and let gu1 infer (see How isNewDevice works).

Handle Auto-Creation Carefully

Use withAutoEntity=true only when you’re confident the tax ID is valid and you want entities created automatically.

Next Steps

List Events

Query events with filters

Event Statistics

Get aggregated statistics

Devices API

Learn about device integration

Fraud Rules

Build rules using event data