Leads

Leads: available fields, filters, associations, and API operations.

Path: events/{event_id}/leads
Methods: GET collection/record, POST, PATCH, DELETE.

GET

• Fields: event-id, sponsor-ids, registrant-id, created-by-registrant-id, notes, created-at, updated-at.
• Filters: sponsor_id, registrant_id, created_by_registrant_id, created_from, created_to, updated_from, updated_to.
• Associations:
  • sponsors: linkage only;
  • registrant: external-id, first-name, last-name, email;
  • created_by_registrant → response created-by-registrant: external-id, first-name, last-name, email;
  • custom_fields → response custom-fields: definition-key, definition-title, field-type, values.
• Row restriction: by the sponsors association.

GET .../leads?sponsor_id=103705&include=registrant,created_by_registrant,custom_fields

POST/PATCH inputs: registrant_id, created_by_registrant_id, notes, sponsor_id, custom_fields_attributes (raw JSON). The custom-field input is consumed on PATCH; lead creation does not process lead-scan answers.

{
  "sponsor_id": 103705,
  "registrant_id": 1201,
  "created_by_registrant_id": 1301,
  "notes": "Requested pricing information"
}

The target registrant, optional creator registrant, sponsor, and custom fields must belong to the URL event. On a scope restricted to exactly one sponsor, POST may omit sponsor_id; the restricted sponsor is injected. A sponsor-restricted scope cannot change created_by_registrant_id on PATCH. A lead created without a creator correctly returns created-by-registrant-id: null and a null relationship.

Lead-scan answers on PATCH use the configured request key for custom_fields_attributes and this raw shape:

{
  "custom_fields_attributes": [
    {
      "sponsor_id": 103705,
      "question_id": 901,
      "values": ["Q4"]
    }
  ]
}