Send custom JSON payloads from idloom Shape the exact JSON idloom sends to your CRM or webhook endpoint.

Send your registration data in exactly the format your other systems expect

When a new attendee signs up, you usually want that information to flow straight into the rest of your stack — your CRM, your data warehouse, your marketing platform. The catch is that every system has its own opinion about how that data should look.

One expects a Salesforce-style "Lead" object, another wants the ticket details nested inside a "Booking" wrapper, a third needs a fixed source identifier on every record. "Can we just send it the way our CRM expects?" is usually where the conversation with the developer starts — and where the integration project quietly grows.
 

Structured JSON Payload is an idloom integration mode that solves this. You describe, just once, the exact shape your target system expects, mark the spots where live data should go, and idloom fills in the blanks automatically every time a registration comes in. No middleware to maintain, no developer round-trips when the receiving system changes its format. Structured JSON Payload is available to any idloom user with access to the Integrations area, on any integration that uses webhooks or the V4 API.

How to enable Structured JSON Payload on an integration

Structured JSON Payload is toggled per integration — not globally — so you can run it on some integrations while others stay on the classic flat Fields mapping mode.
 

1. In your idloom workspace, go to Manager → Integration → Idloom → Edit for the integration you want to switch.
2. Toggle Structured JSON payload on. The flat Fields mapping editor disappears and is replaced by a JSON editor. The toggle saves immediately.
3. Click one of the Load defaults buttons above the editor — Attendee, Event, or Payment — to pre-fill a complete reference template for that object type. Trim it to what your target system needs.
4. Edit the template using {{placeholder}} syntax (see below) and save.
    

Your previous flat Fields mapping configuration is preserved when you switch — it is not deleted, just paused. If you toggle Structured JSON Payload back off, the flat configuration is restored automatically.

Write your JSON template

A Structured JSON Payload template is a single JSON object with up to three top-level keys — "attendee", "event", and "payment" — each defining the shape for its object type. You only need to include the sections you use; a missing section falls back to the default payload for that object type, and the webhook still fires.

Placeholder syntax

Dynamic values are injected using {{placeholder}} syntax. A few rules to keep in mind:

• The placeholder must occupy the entire JSON value. Writing "Greeting": "Hello {{firstname}}" does not work — Structured JSON Payload is not a string interpolation engine, and the output keeps the literal text verbatim. Use "FirstName": "{{firstname}}" instead, and let the receiving system combine fields.
• Placeholders are resolved in values only, not in keys. A placeholder used as a JSON key is sent as literal text.
• Dot notation navigates nested objects: {{category.location.address.locality}} reads the city from the attendee's booked category.
• [[...]] double-bracket wrapping produces an array of objects. Wrap a single template object in [[...]] and use source.*.field notation inside — idloom iterates over the source array and produces one output object per item.

A complete example that combines all four patterns — static keys, simple placeholders, dot notation, and a [[...]] array:

{
  "attendee": {
    "Header": {
      "SourceSystem": "CRM-001",
      "InterfaceID":  "IF_001"
    },
    "Payload": {
      "Lead": {
        "FirstName": "{{firstname}}",
        "LastName":  "{{lastname}}",
        "Email":     "{{email}}",
        "Status":    "{{registration_status}}"
      },
      "Ticket": {
        "CategoryName": "{{category.name}}",
        "CategorySKU":  "{{category.sku}}",
        "Options": [[
          {
            "Name": "{{options.*.name}}",
            "SKU":  "{{options.*.sku}}"
          }
        ]]
      },
      "Event": {
        "Name":      "{{event.name}}",
        "StartDate": "{{event.start_date}}"
      }
    }
  }
}

Header and Payload here are JSON body keys required by the target CRM. HTTP headers like Authorization or X-API-Key are configured separately in the webhook definition and are not part of the template.
 

And here is what idloom actually sends when Johannes Müller registers as a VIP attendee and books two options:

{
  "attendee": {
    "Header": {
      "SourceSystem": "CRM-001",
      "InterfaceID":  "IF_001"
    },
    "Payload": {
      "Lead": {
        "FirstName": "Johannes",
        "LastName":  "Müller",
        "Email":     "j.muller@example.com",
        "Status":    "confirmed"
      },
      "Ticket": {
        "CategoryName": "VIP",
        "CategorySKU":  "VIP-001",
        "Options": [
          { "Name": "Workshop A",  "SKU": "WS-A"   },
          { "Name": "Gala Dinner", "SKU": "GAL-01" }
        ]
      },
      "Event": {
        "Name":      "Annual Conference 2025",
        "StartDate": "2025-11-27"
      }
    }
  }
}

Where Structured JSON Payload applies

The template shapes the payload in two places: outbound webhooks that idloom fires, and V4 API responses that external systems request.

Webhooks:

• guest.* events (such as guest.created, guest.updated) → use the "attendee" section
• event.* events (such as event.created, event.updated) → use the "event" section
• guest.payment and guest.payment.refund → use the "payment" section

V4 API endpoints:

• GET /attendees, POST /attendees → use the "attendee" section
• GET /events, POST /events, PUT /events/{uid} → use the "event" section

To bypass Structured JSON Payload on a specific V4 API call and return the raw default payload instead, add ignore_fields_mapping=1 as a query parameter.

Available placeholders

Each template section has its own set of available placeholders. The highlights:

Attendee section — covers core registration fields ({{firstname}}, {{email}}, {{registration_status}}), the attendee's booked category via dot notation ({{category.name}}, {{category.price}}), options and nested slots via [[...]] ({{options.*.name}}, {{options.*.slots.*.start_date}}), coupon details ({{coupon.code}}, {{coupon.discount}}), payment summary ({{amount_tax_incl}}, {{payment_status}}), invoicing, check-ins, and shortcut event fields ({{event_name}}, {{event_start_date}}). Every custom registration form field is also available — use the field's internal name from the idloom form builder, not its display label.
 

Event section — covers core attributes ({{uid}}, {{name}}, {{currency}}), dates, main location via dot notation ({{location.address.locality}}), and arrays of additional locations, speakers, sponsors, partners, categories, and options — all via [[...]].
 

Payment section — covers transaction-level data only ({{amount}}, {{currency}}, {{method}}, {{reference}}). Attendee and event fields are not available inside the "payment" key. To combine payment data with attendee context, configure a guest.* webhook on the same integration.