Event Triggers Index¶

Dxtra uses Hasura event triggers to react to database changes in real time. When a row is inserted or updated in a tracked table, Hasura fires a webhook to dx-conduit, which executes the corresponding business logic.

All event triggers authenticate via the nhost-webhook-secret header. Event payloads contain the new (and for updates, old) row data.

How Event Triggers Work¶

sequenceDiagram
    participant DB as PostgreSQL
    participant Hasura
    participant Conduit as dx-conduit
    DB->>Hasura: Row INSERT/UPDATE detected
    Hasura->>Conduit: POST webhook with event payload
    Conduit->>Conduit: Execute handler logic
    Conduit-->>Hasura: 200 OK (or error for retry)
    Note over Hasura,Conduit: Retries on failure per retry_conf

All Event Triggers¶

Trigger Details¶

Authentication Triggers (auth.users)¶

Three triggers fire on the auth.users table when a new user is inserted. They run in parallel.

auth_users_insert¶

Operation: INSERT on auth.users Handler: /hasura/events/auth/anonymous/verify Retries: 2 (10s interval)

Verifies newly inserted authentication users. Checks if the user is anonymous and performs any required verification steps.

create_data_subject¶

Operation: INSERT on auth.users Handler: /integrations/dxtra/users/insert Retries: 0

Creates a corresponding data subject record when a new user signs up. Links the auth user to the privacy data model. This is a critical step in the identity pipeline -- if it fails, the user will not have a data subject record.

link_user_from_invite¶

Operation: INSERT on auth.users Handler: /hasura/events/data-controllers/users/invite-email-match Retries: 3 (10s interval)

Matches newly created users against pending invitations by email address. If a match is found, the user is automatically linked to the inviting data controller's organization.

Data Controller Triggers¶

data_controllers_insert¶

Table: public.data_controllers Operation: INSERT Handler: /hasura/events/data-controllers/insert Retries: 3 (10s interval)

Fires when a new data controller (organization) is created. Handles initial setup tasks including:

• Creating the organization in Tag Manager
• Setting up default compliance templates
• Initializing privacy configuration

data_controller_details_update¶

Table: public.data_controller_details Operation: UPDATE (all columns) Handler: /hasura/events/data-controllers/tag-manager/create-update Retries: 0

Fires when a data controller's details are updated (name, address, DPO info, etc.). Synchronizes the updated details to Tag Manager to keep the Transparency Center content current.

Data Controller User Triggers¶

Three triggers on public.data_controller_users manage team member lifecycle.

data_controller_create_user¶

Operation: INSERT Handler: /integrations/dxtra/controller-users/insert Retries: 3 (10s interval)

Fires when a new team member is added to a data controller organization. Sets up the user's data subject record, identity associations, and initial permissions.

data_controller_users_update¶

Operation: UPDATE (all columns) Handler: /integrations/dxtra/controller-users/update Retries: 3 (10s interval)

Fires when a team member's record is updated (role change, status change, etc.). Propagates the changes to related systems.

update_tagmanager_users¶

Operation: UPDATE (status column only) Handler: /hasura/events/data-controllers/users/update-tag-manager Retries: 3 (30s interval)

Fires specifically when a team member's status changes. Synchronizes the user's status to Tag Manager -- for example, deactivating their Tag Manager account when they are removed from the organization.

Data Subject Triggers¶

data_subjects_insert¶

Table: public.data_subjects Operation: INSERT Handler: /hasura/events/data-subjects/insert Retries: 3 (10s interval)

Fires when a new data subject is created. Performs post-creation tasks such as DID generation and initial privacy profile setup.

data_subject_rights_requests_insert¶

Table: public.data_subject_rights_requests Operation: INSERT Handler: /hasura/events/data-subjects/rights-requests/insert Retries: 0

Fires when a new Data Subject Rights Request (DSAR) is submitted. The payload is transformed to extract id, data_subject_id, request_type, and description. Triggers the DSAR processing workflow including:

• Notifying the DPO
• Starting the compliance deadline timer
• Creating audit trail entries

data_subject_rights_requests_update¶

Table: public.data_subject_rights_requests Operation: UPDATE (status column only) Handler: /hasura/events/data-subjects/rights-requests/update Retries: 3 (10s interval)

Fires when a DSAR status changes (e.g., from pending to in_progress to completed). Sends notifications to the data subject and updates compliance tracking.

data_subject_preference_values_update¶

Table: public.data_subject_preference_values Operation: UPDATE (all columns) Handler: /hasura/events/data-subjects/preferences/update Retries: 0

Fires when a data subject's preference values change (e.g., marketing opt-in/out, communication preferences). The payload includes both old and new values for change tracking. Propagates preference changes to integrated systems (email providers, CRMs, etc.).

Processing Activities Trigger¶

data_processing_activities_insert¶

Table: public.data_processing_activities Operation: INSERT Handler: /hasura/events/data-processing-activities/insert Retries: 3 (10s interval)

Fires when a new data processing activity is recorded. Creates the corresponding compliance records and updates the processing activity log (Article 30 records).

Scheduled Events Trigger¶

scheduled_events_insert¶

Table: public.scheduled_events Operation: INSERT Handler: /hasura/events/scheduled-events/insert Retries: 3 (10s interval)

Fires when a new scheduled event is created. The payload is transformed to include all scheduling metadata:

• eventType, frequencyType, frequencyRate
• nextEventAt, lastEventAt, expiredAt
• eventCount, eventLimit, isActive
• id, createdAt, updatedAt, startDate, endDate
• reference

This powers the internal scheduling system for recurring tasks (e.g., periodic compliance checks, data retention scans).

Domain Verification Trigger¶

domain_verification_cors_sync¶

Table: public.domain_verifications Operation: UPDATE (verified column only) Handler: /hasura/events/domain-verifications/cors-sync Retries: 3 (60s interval) Manual trigger enabled: Yes

Fires when a domain's verified status changes. When a domain passes DNS verification, this trigger synchronizes the CORS allowlist to permit the domain for Transparency Center embedding and Tag Manager script delivery.

AI Document Generation Queue Triggers¶

These triggers use queue tables to decouple document generation from the request flow. Inserting a row into the queue table fires the trigger, which starts the AI generation pipeline.

generate_controller_documents¶

Table: public.trigger_generate_documents_queue Operation: INSERT Handler: /ai/document-generation/orchestrate Retries: 0 Timeout: 240s (4 minutes)

Orchestrates AI-powered document generation for a data controller. This is the main entry point for generating privacy notices, policies, and compliance documents. The extended timeout (240s vs the standard 60s) reflects the time required for AI generation.

trigger_document_recovery_assistant¶

Table: public.trigger_generate_recovery_queue Operation: INSERT Handler: /ai/recovery/orchestrate Retries: 0

Orchestrates the document recovery assistant, which regenerates documents that failed or need updating.

generate_v0_profile¶

Table: public.trigger_generate_assessments_queue Operation: INSERT Handler: /hasura/events/data-controllers/profile/data-controller-profile-insert-event Retries: 0

Generates the initial (v0) compliance profile for a data controller, including risk assessments and compliance gap analysis.

generate_controller_purposes¶

Table: public.trigger_generate_purposes_queue Operation: INSERT Handler: /ai/purposes/orchestrate Retries: 0

Orchestrates AI-powered purpose generation, mapping a data controller's data processing activities to standardized legal purposes and lawful bases.

Event Payload Format¶

All event triggers receive a standard Hasura event payload:

{
  "event": {
    "session_variables": {
      "x-hasura-role": "admin"
    },
    "op": "INSERT",
    "data": {
      "old": null,
      "new": {
        "id": "uuid-value",
        "created_at": "2026-04-06T00:00:00Z"
      }
    },
    "trace_context": {
      "trace_id": "...",
      "span_id": "..."
    }
  },
  "created_at": "2026-04-06T00:00:00.000000Z",
  "id": "event-uuid",
  "delivery_info": {
    "max_retries": 3,
    "current_retry": 0
  },
  "trigger": {
    "name": "trigger_name"
  },
  "table": {
    "schema": "public",
    "name": "table_name"
  }
}

For UPDATE events, data.old contains the previous row state and data.new contains the updated row.

Some triggers use request transforms (Kriti templates) to reshape the payload before sending to the webhook handler. This extracts only the needed fields rather than sending the full Hasura event envelope.

Retry Behavior¶