Skip to main content

Overview

Entity webhook events allow you to receive real-time notifications when entities (persons, companies, devices, etc.) are created, updated, or their status changes in the Gu1 platform. These events enable you to keep your systems synchronized with Gu1 and automate workflows based on entity lifecycle changes.

Why Use Entity Events?

Real-Time Sync

Keep your database synchronized with Gu1 entity data

Automated Workflows

Trigger actions when entity status changes

Audit Trail

Track all entity changes for compliance

Efficient

No need to poll the API for updates

Available Events

entity.created

Triggered when a new entity is created in Gu1. When it fires:
  • A new person, company, device, or other entity is created via POST /entities
Filters available:
  • entityTypes: Only receive events for specific entity types (e.g., ["person", "company"])

entity.updated

Triggered when an entity’s data is updated (excluding status changes). When it fires:
  • Entity information is updated via PATCH /entities/:id
  • Changes to name, attributes, entity data, tax ID, etc.
Note: Status changes trigger entity.status_changed instead. Filters available:
  • entityTypes: Only receive events for specific entity types

entity.status_changed

Triggered when an entity’s status changes. When it fires:
  • Entity status transitions (e.g., under_review β†’ active, active β†’ blocked)
  • Status updates via PATCH /entities/:id or automated compliance actions
Filters available:
  • entityTypes: Filter by entity type
  • statusChanges.from: Only trigger when changing FROM specific status
  • statusChanges.to: Only trigger when changing TO specific status
Organizations explicitly configured to receive the legacy flat entity webhook also receive riskScore and documentNumber at the top level of the payload. These are additive fields; legacy status values such as IN_PROGRESS and APPROVED remain unchanged.

entity.country_activation_changed

Triggered when a merchant entity’s operational country activation status changes. When it fires:
  • PATCH /entities/:id/country-activations/:countryCode with a new status (not idempotent repeats)
Statuses: deactivated, activation_requested, activation_in_progress, activated. Transitions are free-form. Note: This is an operational flag only. Entity profile data is unchanged β€” re-fetch via GET /entities/:id if needed. Filters available:
  • entityTypes: Filter by entity type (e.g., ["company"])

Event Payload Examples

entity.created

Key Fields:
  • entity: Complete entity object with all data
  • entity.externalId: Your unique identifier for the entity
  • entity.type: Entity type (person, company, device, etc.)
  • entity.status: Current status (under_review, active, blocked, etc.)
  • createdBy: User ID who created the entity
  • metadata: Additional context about the creation

entity.updated

Key Fields:
  • entity: Complete entity object with updated data
  • changes: Object showing what changed (old vs new values)
  • updatedBy: User ID who updated the entity
  • reason: Optional reason for the update

entity.status_changed

Key Fields:
  • status: New status
  • previousStatus: Previous status
  • reason: Why the status changed
  • entity: Complete entity object

entity.country_activation_changed

Key Fields:
  • countryCode: Country whose activation changed (AR, BR, CL, CO, MX, US)
  • status / previousStatus: New and prior activation state
  • activeCountryCodes: Snapshot of all activated countries after this change (allowlist order)
  • countries: Full snapshot of all allowlist countries after this change
  • timeline: Chronological status changes for this country (from audit trail), each with previousStatus, status, and changedAt
  • entity.externalId: Your merchant identifier
  • changedAt: ISO timestamp of the change

Filter Configuration

Filter by Entity Type

Only receive events for specific entity types:
This configuration will only trigger webhooks for person and company entities, ignoring devices and other types.

Filter by Status Change

Only receive events when entity status changes to specific values:
This will only trigger when a person entity is changed TO blocked status. Filter when changing FROM a specific status:
This will only trigger when status changes from active to suspended.

Code Examples

Node.js - Handling Entity Events

Python - Handling Entity Events

Use Cases

Use Case 1: Real-Time Database Sync

Keep your local database synchronized with Gu1:

Use Case 2: Automated Account Activation

Automatically activate customer accounts when status changes to active:

Use Case 3: Compliance Monitoring

Track and respond to entity status changes for compliance:

Use Case 4: Customer Notifications

Notify customers when their information changes:

Best Practices

The entity.externalId is your unique identifier. Use it to look up entities in your database:
Always store the Gu1 entity ID in your database for reference:
Even if you only subscribe to specific events, handle all event types gracefully:
Keep an audit trail of all entity changes:
Use the entity ID and timestamp to prevent duplicate processing:
Configure filters to only receive relevant events:

Troubleshooting

Check:
  • Webhook is subscribed to entity.created event
  • Entity type matches your filters (if configured)
  • Webhook is enabled in dashboard
  • Endpoint is publicly accessible
Test:
The changes object only includes fields that actually changed. If you don’t see a field, it means it wasn’t updated.Example:
Only name changed, other fields remain the same.
Check:
  • Status actually changed (not just entity updated)
  • Filters match the status change (from/to)
  • Status change is not being filtered out
Example filter that might block events:
This will ONLY fire when status changes TO blocked.

Next Steps

KYC Events

Handle KYC verification events

Rule Events

Process compliance rule triggers

Webhook Security

Secure your webhook endpoints

Configuration

Configure webhook settings