---
title: "Export leads with registrant details"
description: "Filter sponsor leads, include the captured registrant and creator, and follow every result page."
---

Read the lead records and explicitly request the related registrant objects. A token's association allowlist and the request's `include` parameter do different jobs.

## Configure access

The leads scope needs Read access to the event. Select the lead fields you need, enable the `sponsor_id` query filter, and allow the `registrant` and `created_by_registrant` associations with their desired fields. A sponsor restriction on the scope is the authorization boundary; a query filter alone does not restrict the token's access.

## Build the first page

The request uses `include=registrant,created-by-registrant`. The latter is the dashed relationship name; `created_by_registrant` is the scope configuration name.



```shell
curl --fail-with-body --silent --show-error --globoff --max-time 30 --request GET \
  --url "${BRELLA_API_BASE_URL}"'/api/core/organizations/123/events/456/leads?sponsor_id=103705&include=registrant,created-by-registrant&page[number]=1&page[size]=50' \
  --header "Accept: application/vnd.brella.v4+json" \
  --header "Brella-API-Access-Token: ${BRELLA_API_ACCESS_TOKEN}"
```



## Join the related records

For each lead, resolve `relationships.registrant.data` against `included` using **both `type` and `id`**. Resolve `relationships.created-by-registrant.data` the same way. Keep the lead even when creator linkage is `null`; this can be valid for a lead created without a creator registrant.

The association permits `external-id`, `first-name`, `last-name` and `email`. It does not expose arbitrary registrant fields. If you specifically need the imported `external_*` identity values, use a separately authorized [registrant read](https://docs.brella.io/reference/registrants) and join by registrant ID; do not silently substitute profile values.


An allowed association produces relationship linkage. Only an explicitly requested and allowed include produces an included object. Example with include=registrant:

```json
{
  "data": [
    {
      "id": "901",
      "type": "lead",
      "attributes": {
        "notes": "Requested a follow-up",
        "registrant-id": 1201
      },
      "relationships": {
        "registrant": {
          "data": {
            "id": "1201",
            "type": "event-registrant"
          }
        }
      }
    }
  ],
  "meta": {
    "total_count": 1,
    "total_pages": 1,
    "current_page": 1
  },
  "included": [
    {
      "id": "1201",
      "type": "event-registrant",
      "attributes": {
        "external-id": "CRM-10042",
        "first-name": "Alex",
        "last-name": "Morgan",
        "email": "alex@example.com"
      }
    }
  ]
}
```



## Export every page

Start at page 1, process `data` and `included` together, then increment `page[number]` until `meta.current_page` reaches `meta.total_pages`. Page size is at most 100. Deduplicate by lead ID if restarting an export, and preserve one output row per lead.

A multi-page export is not a database snapshot; records can change while you read. For routine exports, keep a fixed time window using authorized `created_from` and `created_to` filters. Dates should be explicit ISO 8601 values.

Keep exported contact data in the customer's intended destination. On **429**, respect `Retry-After`; see [retry guidance](https://docs.brella.io/concepts/responses-and-errors).