Skip to content

Make Event Data Reference

This document describes how WhiteLabelCRO Integration API events are structured and accessed in Make scenarios.

Event to API Mapping

The Integration API emits 10 event types. In Make, you work directly with the API event structure.

API Event Type Description Common Use Case
client.created When a new client is enrolled Send welcome email, create CRM record
client.status_changed When client moves to different stage Trigger stage-specific workflows
lead.created When a new lead is captured Add to nurture campaign
invoice.created When invoice is generated Send payment reminder
invoice.status_changed When invoice payment status changes Update accounting system
payment.succeeded When payment processes successfully Send receipt, update billing
payment.failed When payment is declined Alert finance team, retry payment
affiliate.created When referral partner is added Send onboarding materials
document.uploaded When file is attached to record Process document, extract data
agreement.signed When e-signature is completed Trigger post-signature workflow

Event Envelope Structure

The Integration API returns events in this format:

{
  "id": 12345,
  "type": "client.created",
  "createdUtc": "2026-01-28T10:30:00Z",
  "companyId": 92,
  "payload": {
    "client_id": 5678,
    "first_name": "John",
    "last_name": "Doe",
    "email": "john@example.com"
  },
  "metadata": {
    "source": "web_portal",
    "user_id": 42
  }
}

Accessing Fields in Make

Standard Fields (All Events)

Present in every event:

In Make variables: - Event ID: {{id}} - Event type: {{type}} - Timestamp: {{createdUtc}} - Company ID: {{companyId}}

Payload Fields

Payload structure varies by event type. Access using dot notation:

Examples: - Client ID: {{payload.client_id}} - First name: {{payload.first_name}} - Email: {{payload.email}} - Invoice amount: {{payload.amount}} - Payment status: {{payload.invoice_status}}

See the Event Catalog (/03-events/event-catalog.md) for complete field definitions per event type.

Metadata Fields

Optional context provided with some events:

  • Source: {{metadata.source}}
  • User ID: {{metadata.user_id}}

Field Naming Conventions

Common Field Patterns

Across all event types: - IDs: client_id, employee_id, affiliate_id, invoice_id, payment_id - Status fields: status, previous_status, new_status, invoice_status - Date fields: created_date, changed_date, signed_date, due_date (ISO 8601 strings) - Person fields: first_name, last_name, full_name, email, phone

Handling Nested Data

For nested objects (if present):

{
  "payload": {
    "address": {
      "street": "123 Main St",
      "city": "Springfield"
    }
  }
}

Access in Make: - Street: {{payload.address.street}} - City: {{payload.address.city}}

Array Handling

If the payload contains arrays:

{
  "payload": {
    "tags": ["vip", "high_priority"]
  }
}

Access in Make: - First tag: {{payload.tags[1]}} (Make uses 1-based indexing) - All tags: Use Iterator module to process array

Working with Event Data

Routing by Event Type

Use Router module to route based on event type:

Add filters to routes: - Condition: {{type}} equals client.created - Condition: {{type}} equals payment.succeeded

Or use Filter module: - Condition: {{type}} = client.created

Extracting Specific Fields

Use Set Variable or Tools > Set multiple variables to create simplified data:

Example: - clientId: {{payload.client_id}} - fullName: {{payload.first_name}} {{payload.last_name}} - email: {{payload.email}}

Handling Missing Fields

Some optional fields may be null. Use default values:

{{ifempty(payload.phone; "No phone provided")}}

Or use Filter to check existence: - Condition: {{payload.phone}} exists

Field Type Handling

Date/Time Fields

  • API returns: ISO 8601 strings (e.g., 2026-01-28T10:30:00Z)
  • In Make: Use date/time functions to parse and format
  • Access as string: {{createdUtc}}
  • Format: Use formatDate() function

Boolean Fields

  • API returns: true or false (JSON boolean)
  • In Make: {{payload.is_approved}}
  • In conditions: Check equality with true or false

Numeric Fields

  • IDs: Always integers (e.g., client_id: 5678)
  • Amounts: May be decimal (e.g., amount: 99.99)
  • Access: {{payload.amount}}
  • Math operations: {{payload.amount * 1.1}}

Null/Missing Fields

  • If a field is null or absent: {{payload.field}} returns empty
  • Check for null with Filter: {{payload.field}} exists
  • Optional fields may not appear in every event

Debugging Event Data

View Full Event Structure

  1. Add JSON > Parse JSON module after webhook or HTTP module
  2. View full structure in scenario execution history
  3. Use Text parser modules to extract specific values if needed

Common Issues

Undefined field errors: - Field doesn't exist for this event type - Check Event Catalog for event-specific fields - Use filters to check field existence first

Type mismatch: - Ensure numeric fields aren't treated as strings - Use parseNumber() if needed - Check field type in API response

JSON Processing

Parsing Full Payload

If you need to process the entire payload:

Use JSON > Parse JSON module to convert string to structured data.

Transforming Data

Use Tools > Set multiple variables for transformations: - Extract commonly used fields - Combine fields (e.g., full name from first + last) - Convert formats or apply defaults

Aggregation

For processing multiple events: 1. Use Array aggregator to collect events 2. Process batch in subsequent modules 3. Use Iterator to process one-by-one if needed

Performance Considerations

Minimize Module Complexity

For repeatedly accessed fields: - Use Set multiple variables to extract once - Reference simplified variables in subsequent modules - Avoid redundant transformations

Batch Processing

For high-volume scenarios: 1. Use Aggregator to batch events 2. Reduce external API calls 3. Process in groups for efficiency

Version Stability

Current Implementation

The Integration API uses v1 (/api/v1/...). Event structures are stable within v1.

Backward Compatibility

Event payload structures are stable within v1: - New fields may be added (non-breaking) - Existing fields will not change type or be removed - Always check for field existence before accessing

If a v2 API is introduced in the future, migration guidance will be provided in advance.