# API changelog
Source: https://partner-help.letsdothis.com/api-reference/changelog
Consumer-visible changes to the Let's Do This Public API.
Consumer-visible changes to the public API.
## September 2026
### Customer IDs on applications and participants
*2026-09-25*
Application and participant responses now include a nullable `customerId`. Records that resolve to the same person within your organization share this value, so you can join applications to participants without matching on email.
`customerId` is `null` until a record is linked to a customer. Existing applications may return `null` until their customer IDs are backfilled. Historic applicants who were never imported as participants have no participant record to join, even after their application receives a customer ID.
***
### Scoped API keys
*2026-09-21*
An API key can now be limited to specific event occurrences and to the endpoints that support scoped keys — currently only the registration check below. A scoped key is created and edited in the dashboard under **Settings → Credentials → Public API**. A call outside its scope, and any endpoint that does not support scoped keys, answers `403`. See [Scoped API keys](/api-reference/scoped-keys).
`GET /identity` is now documented. It is available to every key and returns the organization the key belongs to and, for a scoped key, the occurrences and endpoints it is limited to.
***
### Check whether an email is registered
*2026-09-21*
`POST /v0/event-occurrences/{id}/registration-status` answers whether an email address holds a confirmed place in an event occurrence. The response is the occurrence id and `registered: true` or `false`; nothing about the participant is returned. Matching is case-insensitive and ignores surrounding whitespace.
The endpoint is rate limited per key, with a burst limit and a daily quota stated on [its reference page](/api-reference/endpoints/eventoccurrences/check-whether-an-email-is-registered), and supports scoped keys.
***
## August 2026
### Read and update discount codes (restricted)
*2026-08-26*
`GET /v0/discount-codes/{id}` returns one of your discount codes, described with the same fields an import row accepts, plus its id and when it was created. `PATCH /v0/discount-codes/{id}` updates the code's internal name (`group`) and leaves every other field on it unchanged. The `id` is the `discountCodeId` an import reports for the code.
A code that belongs to another organization, one that has been deleted, and an id that identifies something other than a discount code — a credit, gift card or referral code — all answer `404`, so an id alone reveals nothing about codes you cannot access.
Both endpoints are restricted and not generally available: organizations that have not been enabled receive a `403`. Contact your Let's Do This representative if you'd like access.
***
### Imported discount codes can discount each entry
*2026-08-25*
Rows sent to `POST /v0/discount-codes/import` accept `appliesPer`, either `TRANSACTION` or `ENTRY`. `TRANSACTION` is the default and is what imported codes have always been: the code discounts a basket once, however many entries it holds. `ENTRY` discounts each participant's entry separately, so a basket of three entries is discounted three times.
The choice also changes how usage limits are counted. A per-entry code counts entries where a transaction code counts bookings, so `limitUsage` of `1` on a per-entry code is spent by the first participant rather than covering a whole booking.
`limitUsagePerTransaction` now requires `appliesPer` to be `ENTRY`. Only a per-entry code is capped that way at checkout, so the field was previously accepted and then silently ignored; a row that sets it without `appliesPer` set to `ENTRY` is now rejected along with the rest of the batch.
***
### Timing ingest accepts shipment updates
*2026-08-24*
`POST /timing-inbound/v1` now accepts a `data.shipping` object, so a timing provider can report that a participant's bib pack has been dispatched — `shippedAt` plus optional `status` (`SHIPPED`, `DELIVERED` or `RETURNED`; defaults to `SHIPPED`), `carrier`, `trackingNumber` and `trackingUrl`.
`schemaVersion` stays `"1.0"`: this is an additive change and nothing previously accepted is now rejected. Two things follow from that:
* `data.bibNumber` is no longer required, because a shipment update need not carry a bib. A message must still carry at least one recognised field — `data` with neither `bibNumber` nor `shipping` answers `400` rather than being accepted and dropped.
* A shipping field you omit leaves the stored value unchanged, so a status update need only carry what changed. It cannot clear a carrier or tracking number.
An unrecognised `status` answers `400`. Bib and shipping updates are ordered independently, so a shipment sent after a bib with an earlier `changedAt` still applies.
***
### Timing ingest endpoint published
*2026-08-20*
`POST /timing-inbound/v1` is now documented under the new **Timing** section. Timing providers enabled for the integration push data (currently bib numbers) back for startlist entries they received from Let's Do This, as a single message or a batch of up to 500.
The endpoint itself is not new — it was previously undocumented while the contract was agreed directly with the first partner. It is available to select timing partners only; other callers receive the standard `401`.
***
### Import endpoints you are not enabled for now answer `403`
*2026-08-10*
Every import surface — bookings, line items, add-on products, discount codes, credits, referrals, and reserved entry participants — previously answered `404` when your organization was not enabled for it. They now answer `403` with a message naming the surface:
```
Booking imports are not enabled for this organizer. Ask your Lets Do This contact to enable them.
```
The `404` said the endpoint did not exist, which was never true — it is documented here — and left no way to tell "not switched on yet" from a wrong URL. If you branch on the status code to detect that your organization lacks access, match `403` rather than `404`.
Job IDs are unaffected: a status endpoint still answers `404` for a job that does not exist or belongs to another organization, so it cannot be used to discover other organizations' jobs.
***
### A permanent import failure is no longer reported as `INTERNAL`
*2026-08-07*
A reserved entry participant assignment the import cannot use — one naming a blank identifier, for instance — now fails with the code `INVALID_ASSIGNMENT` in the job status `errors`. It previously reported `INTERNAL`.
The distinction matters for retries. `INTERNAL` means the cause could not be named, so trying again is reasonable. `INVALID_ASSIGNMENT` means the assignment itself was rejected before anything was written, so resubmitting the same row cannot succeed — correct the row and submit it again.
Other codes describe the state that blocked the assignment rather than the assignment itself, and that state can change: `NO_CAPACITY_REMAINING` clears when a place frees or the group's capacity is raised.
`code` is a free-form string, so no schema change is involved and existing handling continues to work.
***
### Read a booking's add-on allocations
*2026-08-05*
> **Restricted:** This endpoint is not generally available. Organizations that have not been enabled receive a `403`; contact your Let's Do This representative if you'd like access.
`GET /v0/bookings/{id}/add-on-allocations` returns a cursor-paginated list of the participant add-on allocations stored for a booking. Each allocation includes its participant and purchase line-item references, add-on and variant details, operational and financial status, and creation and update timestamps. Imported records also include external add-on, variant, and line-item identifiers when available.
***
## July 2026
### Delete an imported booking
*2026-07-27*
`DELETE /v0/bookings/{id}` retires a booking you imported through the Public API, so you can correct a bad row and import it again under the same `externalBookingId`.
The booking is not removed: it moves to `CANCELLED` and stays readable. The external ID it was imported under is freed at the same time, so re-importing that ID creates a new booking rather than reporting `alreadyImported`. Deleting is idempotent — deleting an already-deleted booking succeeds and changes nothing.
Only bookings whose `source` is `API` can be deleted. Anything else returns `403`, and a booking that does not exist or belongs to another organizer returns `404`.
***
### Breaking: the external-booking-ID lookup returns a list
*2026-07-27*
`GET /v0/bookings/external/{externalBookingId}` now returns a `PagedBookingSummaries` envelope instead of a single `Booking`, and an ID that matches nothing returns an empty list with `200` rather than `404`.
One external ID can legitimately match more than one booking — correcting an import cancels the original and re-imports it, so both survive under the ID you supplied. The previous shape had to choose one on your behalf and could not show you the other. Results are oldest first, matching the other list endpoints, so the most recent match is last. The endpoint accepts the standard `page[size]`, `page[after]`, and `page[before]` parameters.
The summaries are `BookingSummary` rather than the full `Booking` the endpoint used to return, matching the other list endpoints; use `GET /v0/bookings/{id}` to fetch one in full.
***
### Standardize event-occurrences list pagination
*2026-07-02*
`GET /v0/event-occurrences` now accepts the standard `page[size]`, `page[after]`, and `page[before]` query parameters, matching the other list endpoints. The legacy `pageSize`, `cursor[after]`, and `cursor[before]` parameters continue to work but are deprecated. The response schema is renamed to `PagedOrganizerEventOccurrenceSummaries`; the previous `EventOccurrencesResponse` name remains as a deprecated alias.
***
### Paginate the races, tickets, and reserved-entry-groups lists
*2026-07-01*
The races list (`GET /v0/event-occurrences/{id}/races`), the event tickets list (`GET /v0/events/{id}/tickets`), and the reserved entry groups list (`GET /v0/events/{id}/reserved-entries`) now return a `page` cursor alongside `data` and accept `page[size]`, `page[after]`, and `page[before]`, matching the other list endpoints. All continue to return every item by default, so existing integrations are unaffected. The response schemas are renamed to `PagedRaceSummaries`, `PagedTickets`, and `PagedReservedEntryGroups`; the previous `Races`, `Tickets`, and `ReservedEntryGroups` schema names remain as deprecated aliases.
***
### Read a single event occurrence
*2026-07-01*
You can retrieve an individual event occurrence with `GET /v0/event-occurrences/{id}`. Access is scoped to the organizer associated with your Public API credentials.
***
## June 2026
### Navigate from a race to its event occurrence
*2026-06-30*
`GET /v0/races/{id}` now includes `eventOccurrenceId` and `eventId`, so you can navigate from a race back to its event occurrence and event. These fields are returned on the single-race response; the race lists stay lean.
***
### Read a single race
*2026-06-30*
You can retrieve an individual race with `GET /v0/races/{id}`. Access is scoped to the organizer that owns the race's event occurrence.
***
### Find the booking forms that use a field
*2026-06-30*
You can look up which booking forms reference a given field with `GET /v0/booking-form-fields/{id}/booking-forms`. A field can be shared across many forms, so this returns a paginated list.
***
### Read booking form fields
*2026-06-30*
You can read the individual questions on a booking form. Use `GET /v0/booking-form-fields` to list fields, `GET /v0/booking-form-fields/{id}` to fetch one, and `GET /v0/booking-forms/{id}/fields` to list the fields on a specific form. Each field exposes its type, label, options, and whether an answer is required.
***
### Read booking forms
*2026-06-30*
You can retrieve a single booking form with `GET /v0/booking-forms/{id}`, and traverse between tickets and their booking forms: `GET /v0/tickets/{id}/booking-forms` lists the booking forms a ticket uses (usually zero or one), and `GET /v0/booking-forms/{id}/tickets` lists the tickets that share a booking form.
***
### Read individual tickets and a race's tickets
*2026-06-30*
You can retrieve a single ticket with `GET /v0/tickets/{id}`, and list the tickets belonging to a race with `GET /v0/races/{id}/tickets`. Ticket titles now include a `titleByLocale` map, always seeded with the default (`en-GB`) title alongside any translations.
***
### Races by event occurrence
*2026-06-01*
You can retrieve races for an event occurrence. Use `GET /v0/event-occurrences/{id}/races` if your integration needs race-level data.
***
## May 2026
### Application notes
*2026-05-26*
Application responses include stand-alone notes added from the dashboard. Use the `notes` field on application responses to read notes that are not approval or rejection reasons.
### Participant booking source
*2026-05-26*
Participant responses include `bookingSource`. Use this field to distinguish bookings made through Let's Do This from participants imported from an external platform.
### GivenGain partner lookup
*2026-05-22*
Partner lookups can use `givenGain` as an external ID type. Use `externalId=givenGain` when you need to query partners by their GivenGain identifier.
### Team roles on participants
*2026-05-20*
When `?features=teams` is enabled, participant `team` objects include `roles` with the participant's team role descriptions.
### Clearer errors for invalid IDs
*2026-05-08*
Requests with a malformed resource ID in the path (for example, `GET /v0/participants/not-a-valid-id`) now return `404 Not Found` instead of `500 Internal Server Error`.
***
## April 2026
### Implied donation field on applications
*2026-04-14*
Applications for tickets where donation is implied by the ticket include a synthetic `hasDonated` field, so integrations receive the same shape as tickets that ask the donation question directly.
***
## March 2026
### Charity opt-in partner names
*2026-03-11*
Participant `charityOptIn` values return partner names instead of opaque partner IDs where the partner can be resolved.
# Get add-on import status
Source: https://partner-help.letsdothis.com/api-reference/endpoints/addons/get-add-on-import-status
/openapi.json get /v0/add-ons/import/{jobId}
Returns task counts and paginated per-product results for an organizer-owned add-on product import. Poll until the status is completed or cancelled.
This endpoint is restricted and not generally available: organizations that have not been enabled receive a `403`. Contact your Let's Do This representative if you'd like access.
# Get an add-on by ID
Source: https://partner-help.letsdothis.com/api-reference/endpoints/addons/get-an-add-on-by-id
/openapi.json get /v0/add-ons/{id}
Returns one organizer-owned add-on. Foreign, ownerless, deleted, and unknown products return 404.
This endpoint is restricted and not generally available: organizations that have not been enabled receive a `403`. Contact your Let's Do This representative if you'd like access.
# Import add-ons
Source: https://partner-help.letsdothis.com/api-reference/endpoints/addons/import-add-ons
/openapi.json post /v0/add-ons/import
Creates add-on products from the batch, queueing one isolated task per product. This endpoint is create-only: a product whose `externalAddOnId` was already imported is reported as `alreadyImported` and left unchanged. Use the `PUT` endpoint to update imported products.
This endpoint is restricted and not generally available: organizations that have not been enabled receive a `403`. Contact your Let's Do This representative if you'd like access.
# List a booking's add-on allocations
Source: https://partner-help.letsdothis.com/api-reference/endpoints/addons/list-a-bookings-add-on-allocations
/openapi.json get /v0/bookings/{id}/add-on-allocations
Lists a booking's participant add-on allocations, including participant and line-item references, product and variant details, and operational and financial status.
This endpoint is restricted and not generally available: organizations that have not been enabled receive a `403`. Contact your Let's Do This representative if you'd like access.
# List add-ons
Source: https://partner-help.letsdothis.com/api-reference/endpoints/addons/list-add-ons
/openapi.json get /v0/add-ons
Returns organizer-owned participant add-ons, grouped by product and paginated before external import identities are enriched. Each add-on carries its restriction lists (`eventIds`, `eventOccurrenceIds`, `raceIds`, `ticketSlugs`) — alternative grants combined with OR, all empty meaning organizer-wide — which determine the bookings it can be sold with or imported onto.
This endpoint is restricted and not generally available: organizations that have not been enabled receive a `403`. Contact your Let's Do This representative if you'd like access.
# List add-ons for an event occurrence
Source: https://partner-help.letsdothis.com/api-reference/endpoints/addons/list-add-ons-for-an-event-occurrence
/openapi.json get /v0/event-occurrences/{id}/add-ons
Returns organizer-owned add-ons whose current event, occurrence, race, and ticket restrictions apply to this occurrence. An add-on may still apply to only some of the occurrence’s tickets: read its restriction lists (`eventIds`, `eventOccurrenceIds`, `raceIds`, `ticketSlugs`) — alternative grants combined with OR — and match them against the occurrence’s tickets, joining `ticketSlugs` on each ticket’s `ticketSlug` and `raceIds` on its `raceId`.
This endpoint is restricted and not generally available: organizations that have not been enabled receive a `403`. Contact your Let's Do This representative if you'd like access.
# Upsert imported add-ons
Source: https://partner-help.letsdothis.com/api-reference/endpoints/addons/upsert-imported-add-ons
/openapi.json put /v0/add-ons/import
Creates or updates add-on products, matched on their organizer-scoped `externalAddOnId`, queueing one isolated task per product. Only products and variants created through the import are ever updated — products created in the dashboard are never touched. Variants omitted from a product are retained.
This endpoint is restricted and not generally available: organizations that have not been enabled receive a `403`. Contact your Let's Do This representative if you'd like access.
# Get an application by ID
Source: https://partner-help.letsdothis.com/api-reference/endpoints/application/get-an-application-by-id
/openapi.json get /v0/applications/{id}
Returns an application by ID if you have access to it.
# List applications
Source: https://partner-help.letsdothis.com/api-reference/endpoints/application/list-applications
/openapi.json get /v0/applications
Returns all applications that you have access to.
# List applications for an event
Source: https://partner-help.letsdothis.com/api-reference/endpoints/application/list-applications-for-an-event
/openapi.json get /v0/events/{id}/applications
Returns all applications associated with an event.
# Get a booking form field by ID
Source: https://partner-help.letsdothis.com/api-reference/endpoints/bookingformfields/get-a-booking-form-field-by-id
/openapi.json get /v0/booking-form-fields/{id}
Returns a single booking form field by ID if it belongs to the organizer associated with your Public API credentials.
# Get a booking form's import contract
Source: https://partner-help.letsdothis.com/api-reference/endpoints/bookingformfields/get-a-booking-forms-import-contract
/openapi.json get /v0/booking-forms/{id}/import-fields
Returns everything a `POST /v0/bookings/import` payload can address for this form: core fields with the form's requiredness, the ticket's custom questions, and the booking-level booker fields. Each row carries the import contract — where the answer belongs, its shape, sub-keys for keyed answers, and the exact option tokens accepted by import validation. Results are scoped to the organizer associated with your Public API credentials.
# List booking form fields
Source: https://partner-help.letsdothis.com/api-reference/endpoints/bookingformfields/list-booking-form-fields
/openapi.json get /v0/booking-form-fields
Returns a paginated list of the booking form fields owned by the organizer associated with your Public API credentials.
# List booking forms for a field
Source: https://partner-help.letsdothis.com/api-reference/endpoints/bookingformfields/list-booking-forms-for-a-field
/openapi.json get /v0/booking-form-fields/{id}/booking-forms
Returns a paginated list of the booking forms that contain a given field. Results are scoped to the organizer associated with your Public API credentials.
# List fields for a booking form
Source: https://partner-help.letsdothis.com/api-reference/endpoints/bookingformfields/list-fields-for-a-booking-form
/openapi.json get /v0/booking-forms/{id}/fields
Returns a paginated list of the fields used by a given booking form. Results are scoped to the organizer associated with your Public API credentials.
# Get a booking form by ID
Source: https://partner-help.letsdothis.com/api-reference/endpoints/bookingforms/get-a-booking-form-by-id
/openapi.json get /v0/booking-forms/{id}
Returns a single booking form by ID if it belongs to the organizer associated with your Public API credentials.
# List booking forms for a ticket
Source: https://partner-help.letsdothis.com/api-reference/endpoints/bookingforms/list-booking-forms-for-a-ticket
/openapi.json get /v0/tickets/{id}/booking-forms
Returns a paginated list of the booking forms a given ticket appears in. Results are scoped to the organizer associated with your Public API credentials.
# List tickets for a booking form
Source: https://partner-help.letsdothis.com/api-reference/endpoints/bookingforms/list-tickets-for-a-booking-form
/openapi.json get /v0/booking-forms/{id}/tickets
Returns a paginated list of the tickets that use a given booking form. Results are scoped to the organizer associated with your Public API credentials.
# Delete an imported booking
Source: https://partner-help.letsdothis.com/api-reference/endpoints/bookings/delete-an-imported-booking
/openapi.json delete /v0/bookings/{id}
Deletes a booking that was imported through the Public API, so a corrected row can be imported in its place. The booking is not removed — it moves to `CANCELLED` and stays readable — but the `externalBookingId` it was imported under is freed, so re-importing that id creates a new booking rather than reporting `alreadyImported`.
Deleting is idempotent: deleting an already-deleted booking succeeds and changes nothing. Only bookings whose `source` is `API` can be deleted; anything else returns 403, and a booking that does not exist or belongs to another organizer returns 404.
This endpoint is restricted and not generally available: organizations that have not been enabled receive a `403`. Contact your Let's Do This representative if you'd like access.
# Get a booking by ID
Source: https://partner-help.letsdothis.com/api-reference/endpoints/bookings/get-a-booking-by-id
/openapi.json get /v0/bookings/{id}
Returns a single booking by ID if it belongs to the organizer associated with your Public API credentials.
# Get booking import status
Source: https://partner-help.letsdothis.com/api-reference/endpoints/bookings/get-booking-import-status
/openapi.json get /v0/bookings/import/{jobId}
Returns the progress of an asynchronous booking import and the per-row outcomes recorded so far. Poll until `status` is `completed`, then read `results` for each row — failures carry the same error vocabulary as the submit-time validation response.
To resolve a single row later, use the external-booking-id lookup endpoint.
This endpoint is restricted and not generally available: organizations that have not been enabled receive a `403`. Contact your Let's Do This representative if you'd like access.
# Get line item import status
Source: https://partner-help.letsdothis.com/api-reference/endpoints/bookings/get-line-item-import-status
/openapi.json get /v0/bookings/line-items/import/{jobId}
Returns the job id, lowercase job status, booking-group progress counts, and available per-item results for an asynchronous line-item import, matching the booking-import polling envelope.
This endpoint is restricted and not generally available: organizations that have not been enabled receive a `403`. Contact your Let's Do This representative if you'd like access.
# Import bookings
Source: https://partner-help.letsdothis.com/api-reference/endpoints/bookings/import-bookings
/openapi.json post /v0/bookings/import
Asynchronously imports a batch of bookings. The whole batch is validated synchronously against each ticket's booking form — use the booking form fields endpoints to discover the import contract — and either every row is accepted (202 with a job to poll) or nothing is imported (422 with every problem, aggregated by error class).
`externalBookingId` is the row's idempotency key: imports are create-once, so re-importing one returns the original booking (reported as `alreadyImported`) rather than creating a second — supply a fresh row `idempotencyKey` to import corrected data for the same id. Send an `Idempotency-Key` header to make the submission replayable: retrying the same key and body returns the original job; reusing a key with a different body is rejected (409).
A row may pin the booking form it validates against via `bookingFormId`; the pin is required (`AMBIGUOUS_BOOKING_FORM`) when the ticket has more than one live form, and a supplied pin must be a live form of the row's ticket (`UNKNOWN_BOOKING_FORM`).
Rows sharing an `externalOrderId` are given one `bookingReference`, so a purchase that produced several bookings stays one order; the reference is derived from the id, so rows split across batches or retried later still join it. `externalOrderId` is deliberately not an idempotency key — reusing one is how an order gains bookings, and rows carrying it still dedup individually on `externalBookingId`. It groups bookings, not payments: the financial records stay one per booking.
A row may carry a `status` for backfilling history: withdrawn, deferred and canceled bookings, and bookings flagged as due to be transferred, are created in that state rather than created and then changed, so importing them sends no withdrawal or deferral emails to participants. Omit it for a confirmed booking. A completed transfer is not importable, because its meaning lives in the link between two bookings, which this API gives you no way to express; nor is a refund, or a refund taken as credit, because both imply payment or credit records an import does not create.
This endpoint is restricted and not generally available: organizations that have not been enabled receive a `403`. Contact your Let's Do This representative if you'd like access.
# Import line items
Source: https://partner-help.letsdothis.com/api-reference/endpoints/bookings/import-line-items
/openapi.json post /v0/bookings/line-items/import
Performs request-local validation, then queues one isolated task per booking. Booking-dependent financial validation runs asynchronously; poll the returned job id for progress, validation failures, and item results.
This endpoint is restricted and not generally available: organizations that have not been enabled receive a `403`. Contact your Let's Do This representative if you'd like access.
# List a booking's line items
Source: https://partner-help.letsdothis.com/api-reference/endpoints/bookings/list-a-bookings-line-items
/openapi.json get /v0/bookings/{id}/line-items
Returns a paginated list of the booking's financial line items.
# List a booking's participants
Source: https://partner-help.letsdothis.com/api-reference/endpoints/bookings/list-a-bookings-participants
/openapi.json get /v0/bookings/{id}/participants
Returns a paginated list of the booking's participants (entries), if the booking belongs to the organizer associated with your Public API credentials.
# List bookings
Source: https://partner-help.letsdothis.com/api-reference/endpoints/bookings/list-bookings
/openapi.json get /v0/bookings
Returns a paginated list of the organizer's bookings. Filter by `source`, `status`, `externalBookingId`, or `externalOrderId` — for example to verify an import, or to read back every booking of an order you imported. Filters combine, so an order can be narrowed by status.
# List bookings by your external booking ID
Source: https://partner-help.letsdothis.com/api-reference/endpoints/bookings/list-bookings-by-your-external-booking-id
/openapi.json get /v0/bookings/external/{externalBookingId}
Lists the bookings carrying the external id you supplied when importing, scoped to the organizer associated with your Public API credentials.
Several bookings can share one external id — correcting an import cancels the original and re-imports it, so both remain — and every match is returned, oldest first — so the most recent is last — for you to choose between. An id you have not used, and one belonging to another organizer, both return an empty list.
# List bookings by your external order ID
Source: https://partner-help.letsdothis.com/api-reference/endpoints/bookings/list-bookings-by-your-external-order-id
/openapi.json get /v0/bookings/external-order/{externalOrderId}
Lists the bookings of one imported order, by the order id you supplied on its import rows, scoped to the organizer associated with your Public API credentials. A purchase that produced several bookings returns all of them, and they share one `bookingReference`. Reusing an order id is how an order gains bookings, so more than one match is expected.
The same lookup is available as the `externalOrderId` filter on `GET /v0/bookings`, which additionally composes with the `source` and `status` filters. An id you have not used, and one belonging to another organizer, both return an empty list.
# List bookings for an event occurrence
Source: https://partner-help.letsdothis.com/api-reference/endpoints/bookings/list-bookings-for-an-event-occurrence
/openapi.json get /v0/event-occurrences/{id}/bookings
Returns a paginated list of the organizer's bookings for a given event occurrence. Filter by `source` or `status`.
# Upsert imported line items
Source: https://partner-help.letsdothis.com/api-reference/endpoints/bookings/upsert-imported-line-items
/openapi.json put /v0/bookings/line-items/import
Performs request-local validation, then queues one isolated task per booking. Booking-dependent financial validation runs asynchronously; poll the returned job id for progress, validation failures, and item results.
This endpoint is restricted and not generally available: organizations that have not been enabled receive a `403`. Contact your Let's Do This representative if you'd like access.
# Get credit import status
Source: https://partner-help.letsdothis.com/api-reference/endpoints/credits/get-credit-import-status
/openapi.json get /v0/credits/import/{jobId}
Returns the progress of an asynchronous credit import and the per-row outcomes recorded so far. Poll until `status` is `completed`, then read `results` for each row.
This endpoint is restricted and not generally available: organizations that have not been enabled receive a `403`. Contact your Let's Do This representative if you'd like access.
# Import credits
Source: https://partner-help.letsdothis.com/api-reference/endpoints/credits/import-credits
/openapi.json post /v0/credits/import
Asynchronously imports a batch of participant credits. The whole batch is validated synchronously — either every row is accepted (202 with a job to poll) or nothing is (422 with every problem, aggregated by error class). Execution is per-row from there: one row failing never rejects the others.
Imports are create-once per `externalCreditId`: re-importing the same id returns the originally imported credit untouched, reported as `alreadyImported`.
Send an `Idempotency-Key` header to make the submission replayable: retrying the same key and body returns the original job; reusing a key with a different body is rejected (409).
This endpoint is restricted and not generally available: organizations that have not been enabled receive a `403`. Contact your Let's Do This representative if you'd like access.
# Get a discount code
Source: https://partner-help.letsdothis.com/api-reference/endpoints/discountcodes/get-a-discount-code
/openapi.json get /v0/discount-codes/{id}
Returns one of your discount codes by ID, described with the same fields an import accepts. The `id` is the `discountCodeId` an import reports for the code. Codes belonging to another organizer, and deleted codes, return 404.
This endpoint is restricted and not generally available: organizations that have not been enabled receive a `403`. Contact your Let's Do This representative if you'd like access.
# Get discount code import status
Source: https://partner-help.letsdothis.com/api-reference/endpoints/discountcodes/get-discount-code-import-status
/openapi.json get /v0/discount-codes/import/{jobId}
Returns the progress of an asynchronous discount code import and the per-row outcomes recorded so far. Poll until `status` is `completed`, then read `results` for each row.
This endpoint is restricted and not generally available: organizations that have not been enabled receive a `403`. Contact your Let's Do This representative if you'd like access.
# Import discount codes
Source: https://partner-help.letsdothis.com/api-reference/endpoints/discountcodes/import-discount-codes
/openapi.json post /v0/discount-codes/import
Asynchronously imports a batch of discount codes. The whole batch is validated synchronously — either every row is accepted (202 with a job to poll) or nothing is (422 with every problem, aggregated by error class). Execution is per-row from there: one row failing never rejects the others.
Imports are create-once per `code`: re-importing an existing code returns it untouched, reported as `alreadyImported`.
Send an `Idempotency-Key` header to make the submission replayable: retrying the same key and body returns the original job; reusing a key with a different body is rejected (409).
This endpoint is restricted and not generally available: organizations that have not been enabled receive a `403`. Contact your Let's Do This representative if you'd like access.
# Update a discount code
Source: https://partner-help.letsdothis.com/api-reference/endpoints/discountcodes/update-a-discount-code
/openapi.json patch /v0/discount-codes/{id}
Updates the internal code name — the `group` an import sets and the organizer dashboard shows in its code list — on one of your discount codes, leaving every other field on the code as it is. The `id` is the `discountCodeId` an import reports for the code. Send an empty `group` to clear the name. Codes belonging to another organizer, and deleted codes, return 404.
This endpoint is restricted and not generally available: organizations that have not been enabled receive a `403`. Contact your Let's Do This representative if you'd like access.
# Check whether an email is registered
Source: https://partner-help.letsdothis.com/api-reference/endpoints/eventoccurrences/check-whether-an-email-is-registered
/openapi.json post /v0/event-occurrences/{id}/registration-status
Answers whether an email address holds a confirmed place in the event occurrence.
Built for partners who need a yes/no at the point of sale — a sponsor validating a participant discount, for example — without access to any participant data. The response carries only the occurrence id and the answer, and an email that is not registered (or has never been seen) is simply `false`.
Only entries with a confirmed status count. Pending payment, deferred, withdrawn, cancelled, refunded and transferred entries answer `false`.
Send the email in the request body, not the URL. Matching is case-insensitive and ignores surrounding whitespace.
Supports [scoped API keys](/api-reference/scoped-keys): this is the `registrationStatus` endpoint, and it reads the occurrence from the path. A key limited by endpoint must include `registrationStatus`; a key limited by occurrence must include the occurrence in the path; a key limited by both must satisfy both.
This endpoint is rate limited per API key in two ways: a burst limit of 5 requests per second, and a quota of 10,000 requests per 24-hour window. Exceeding either answers `429`; a burst rejection carries a `retry-after` header, and a quota rejection says so in its message. A checkout that asks once per customer will not approach either limit.
# Get an event occurrence by ID
Source: https://partner-help.letsdothis.com/api-reference/endpoints/eventoccurrences/get-an-event-occurrence-by-id
/openapi.json get /v0/event-occurrences/{id}
Returns a single event occurrence by ID if it belongs to the organizer associated with your Public API credentials.
# List event occurrences
Source: https://partner-help.letsdothis.com/api-reference/endpoints/eventoccurrences/list-event-occurrences
/openapi.json get /v0/event-occurrences
Returns a paginated list of event occurrences owned by your account.
Results are scoped to the organizer associated with your Public API credentials, so the per-item organizer block from the marketplace events endpoint is omitted.
Published and draft occurrences are both returned, discoverable or not, and past dates are included however old. The only occurrences omitted are those with no start date, which this response has no shape for.
# List events
Source: https://partner-help.letsdothis.com/api-reference/endpoints/events/list-events
/openapi.json get /marketplace/v1/events/
Returns a paginated list of available events on Let's Do This.
Note that this endpoint requires special marketplace API credentials.
If you wish to use this endpoint, please contact the Let's Do This team for more information.
# Show what your API key can reach
Source: https://partner-help.letsdothis.com/api-reference/endpoints/identity/show-what-your-api-key-can-reach
/openapi.json get /identity
Describes the key used to make the call: the organization it belongs to and, for a [scoped key](/api-reference/scoped-keys), the event occurrences, endpoints and booking form answers it is limited to. Every list is empty for a key with full access.
This is the one endpoint every key can call regardless of its scope, so a partner can confirm what they were given before integrating, and you can check a key's scope without opening the dashboard. The response describes the key only; it never includes the key itself or anything about participants.
The `endpoints` values are stable names such as `registrationStatus`, not URL paths. Each endpoint that supports scoped keys names its id on its own reference page.
# Get a line item by ID
Source: https://partner-help.letsdothis.com/api-reference/endpoints/lineitem/get-a-line-item-by-id
/openapi.json get /v0/line-items/{id}
Returns a line item by ID.
# List line items
Source: https://partner-help.letsdothis.com/api-reference/endpoints/lineitem/list-line-items
/openapi.json get /v0/line-items
Returns all line items that you have access to.
# Get a participant by ID
Source: https://partner-help.letsdothis.com/api-reference/endpoints/participant/get-a-participant-by-id
/openapi.json get /v0/participants/{id}
Returns a participant by ID if you have access to it.
# Import an off-platform marketing opt-in
Source: https://partner-help.letsdothis.com/api-reference/endpoints/participant/import-an-off-platform-marketing-opt-in
/openapi.json post /v0/opt-ins
Import a single off-platform marketing opt-in — an email address collected by an external form tool such as a Webflow form — into the organiser's subscriber list, subscribed to marketing. A stable origin id makes retries leave the subscriber untouched, including when they unsubscribed after the first delivery. Throws if the import does not land, so a caller can retry. Use only for addresses whose owner explicitly opted in.
# List participants
Source: https://partner-help.letsdothis.com/api-reference/endpoints/participant/list-participants
/openapi.json get /v0/participants
Returns all participants that you have access to.
# List participants by their answer to a booking form field
Source: https://partner-help.letsdothis.com/api-reference/endpoints/participant/list-participants-by-their-answer-to-a-booking-form-field
/openapi.json get /v0/event-occurrences/{id}/form-field-responses/{publicId}
Returns confirmed participants whose answer to a booking form field matches the supplied value. Each result includes participant identity details and the matched answer.
Specify the field's public ID and an exact `value`, including any surrounding whitespace. Matching uses the public ID stored with each participant's answer. If multiple fields share that public ID, an answer to any of them can match. No matching answers returns an empty list.
For example, use a marketing opt-in field and its affirmative answer to find participants who opted in.
# List participants for a race
Source: https://partner-help.letsdothis.com/api-reference/endpoints/participant/list-participants-for-a-race
/openapi.json get /v0/races/{id}/participants
Returns all participants associated with a race.
# Update a participant's race day fields
Source: https://partner-help.letsdothis.com/api-reference/endpoints/participant/update-a-participants-race-day-fields
/openapi.json patch /v0/participants/{id}/raceday
Updates a participant's bib number and race day custom fields. Note: Updates are processed asynchronously and may take a few moments to reflect in participant data.
# Create a claim link
Source: https://partner-help.letsdothis.com/api-reference/endpoints/partner/create-a-claim-link
/openapi.json post /v0/partners/{id}/claim-links
Creates a claim link for a given partner or reserved entry group.
When providing a `reservedEntryId`, the claim link will point to the dashboard where the partner can manage their entries and allocate them.
Otherwise the claim link will point to the general partner dashboard, where partners can manage their general settings.
# Create a partner
Source: https://partner-help.letsdothis.com/api-reference/endpoints/partner/create-a-partner
/openapi.json post /v0/partners
Creates a new partner.
# Get a partner by ID
Source: https://partner-help.letsdothis.com/api-reference/endpoints/partner/get-a-partner-by-id
/openapi.json get /v0/partners/{id}
Returns a partner by ID if you have access to it. In case the partner's ID is unknown, querying by an external ID (Enthuse or JustGiving) is also possible, for example `/v0/partners/:id?externalId=enthuse`.
# List partners
Source: https://partner-help.letsdothis.com/api-reference/endpoints/partner/list-partners
/openapi.json get /v0/partners
Returns all partners that you have access to.
# Update a partner by ID
Source: https://partner-help.letsdothis.com/api-reference/endpoints/partner/update-a-partner-by-id
/openapi.json patch /v0/partners/{id}
Updates a partner by ID or external ID.
# Get a race by ID
Source: https://partner-help.letsdothis.com/api-reference/endpoints/races/get-a-race-by-id
/openapi.json get /v0/races/{id}
Returns a single race by ID if it belongs to the organizer associated with your Public API credentials.
# List races for an event occurrence
Source: https://partner-help.letsdothis.com/api-reference/endpoints/races/list-races-for-an-event-occurrence
/openapi.json get /v0/event-occurrences/{id}/races
Returns a paginated list of races associated with a given event occurrence.
# Get referral import status
Source: https://partner-help.letsdothis.com/api-reference/endpoints/referrals/get-referral-import-status
/openapi.json get /v0/referrals/import/{jobId}
Returns the progress of an asynchronous referral import and the per-row outcomes recorded so far. Poll until `status` is `completed`, then read `results` for each row.
This endpoint is restricted and not generally available: organizations that have not been enabled receive a `403`. Contact your Let's Do This representative if you'd like access.
# Import referrals
Source: https://partner-help.letsdothis.com/api-reference/endpoints/referrals/import-referrals
/openapi.json post /v0/referrals/import
Asynchronously imports referral progress between existing bookings created through the Public API. Each row names the `referredBookingId`, whose start-list entries each count as referral progress, and the `referralCodeOwnerBookingId`, whose generated referral code receives credit. The owner booking's code is reused or generated internally.
Both bookings must belong to this organizer and their occurrences must be covered by the same active referral program. This operation does not create bookings or participants and does not trigger booking or threshold emails.
The whole batch is validated synchronously — either every row is accepted or none is. Each start-list entry is attributed at most once. Send an `Idempotency-Key` header to make submission replayable.
This endpoint is restricted and not generally available: organizations that have not been enabled receive a `403`. Contact your Let's Do This representative if you'd like access.
# List referral programs
Source: https://partner-help.letsdothis.com/api-reference/endpoints/referrals/list-referral-programs
/openapi.json get /v0/referral-programs
Returns your referral programs — their ids, status, reward configuration, and covered event occurrences. Registered referrers are exposed through the separate, paginated referral-program referrers endpoint.
This endpoint is restricted and not generally available: organizations that have not been enabled receive a `403`. Contact your Let's Do This representative if you'd like access.
# List referrals for a referrer
Source: https://partner-help.letsdothis.com/api-reference/endpoints/referrals/list-referrals-for-a-referrer
/openapi.json get /v0/referral-programs/{referralProgramId}/referrers/{referralCodeOwnerBookingId}/referrals
Returns the paginated start-list entries whose attributed referral code matches the generated code owned by the requested booking. When a referrer has multiple owner bookings, any of their ids returns the same referrals.
This endpoint is restricted and not generally available: organizations that have not been enabled receive a `403`. Contact your Let's Do This representative if you'd like access.
# List referrers for a referral program
Source: https://partner-help.letsdothis.com/api-reference/endpoints/referrals/list-referrers-for-a-referral-program
/openapi.json get /v0/referral-programs/{referralProgramId}/referrers
Returns one referrer per generated referral code, including every booking that owns the code. Multi-buy checkouts can produce multiple owner booking ids; any one can be used with the nested referrals endpoint. Uses the standard Public API data/page cursor format.
This endpoint is restricted and not generally available: organizations that have not been enabled receive a `403`. Contact your Let's Do This representative if you'd like access.
# Create a reserved entry group for an event
Source: https://partner-help.letsdothis.com/api-reference/endpoints/reservedentries/create-a-reserved-entry-group-for-an-event
/openapi.json post /v0/events/{id}/reserved-entries
Creates a reserved entry group under an event's current occurrence. Deprecated in favor of `POST /v0/event-occurrences/{id}/reserved-entries`: an event can have several occurrences, and this route cannot say which one the group is for, so a group meant for a past or future occurrence lands on the wrong one and its tickets will not match. Returns 409 Conflict when the requested allocation cannot fit within the available capacity.
# Create a reserved entry group for an event occurrence
Source: https://partner-help.letsdothis.com/api-reference/endpoints/reservedentries/create-a-reserved-entry-group-for-an-event-occurrence
/openapi.json post /v0/event-occurrences/{id}/reserved-entries
Creates a reserved entry group against a specific occurrence of an event. Use this rather than the event-scoped route, which cannot say which occurrence a group belongs to. Returns 409 Conflict when the requested allocation cannot fit within the available capacity.
# Delete a reserved entry group
Source: https://partner-help.letsdothis.com/api-reference/endpoints/reservedentries/delete-a-reserved-entry-group
/openapi.json delete /v0/reserved-entries/{id}
Deletes a reserved entry group.
# Get a reserved entry group by ID
Source: https://partner-help.letsdothis.com/api-reference/endpoints/reservedentries/get-a-reserved-entry-group-by-id
/openapi.json get /v0/reserved-entries/{id}
Returns a reserved entry group by ID.
# Get reserved entry participant import status
Source: https://partner-help.letsdothis.com/api-reference/endpoints/reservedentries/get-reserved-entry-participant-import-status
/openapi.json get /v0/reserved-entries/participants/import/{jobId}
Returns the progress and outcomes of a submission returned by `POST /v0/reserved-entries/participants/import`. Poll until `status` is `completed` before treating `results` as final — they accumulate as the job works through the batch.
Results are per participant, not per submitted row: a row naming a `bookingId` produces one result per participant on that booking, all sharing its `rowIndex`.
Every result echoes `bookingId`, `entryId` and `participantId` so a caller can reconcile on whichever identifier they hold; store `participantId`, which is the durable key the reserved entry links on. `alreadyImported` means that participant already held a place in that group and nothing was applied.
This endpoint is restricted and not generally available: organizations that have not been enabled receive a `403`. Contact your Let's Do This representative if you'd like access.
# Import reserved entry participants
Source: https://partner-help.letsdothis.com/api-reference/endpoints/reservedentries/import-reserved-entry-participants
/openapi.json post /v0/reserved-entries/participants/import
Asynchronously assigns already-imported entries to reserved entry groups. Each row names its group and exactly one of `bookingId`, `entryId` or `participantId`; a `bookingId` row is expanded to every participant on that booking, so results are reported per participant and can outnumber the rows submitted.
The whole batch is resolved synchronously and either every row resolves (202 with a job to poll) or nothing is imported (422 with every problem).
Assignments are create-once and scoped to `(reservedEntryGroupId, participantId)`: re-importing a participant already holding a place in that group reports `alreadyImported` and consumes no place, and a participant already placed in a *different* group is reported as `ALREADY_ASSIGNED_ELSEWHERE` rather than moved.
Send an `Idempotency-Key` header to make the submission replayable: retrying the same key and body returns the original job; reusing a key with a different body is rejected (409).
This endpoint is restricted and not generally available: organizations that have not been enabled receive a `403`. Contact your Let's Do This representative if you'd like access.
# List reserved entry groups for an event
Source: https://partner-help.letsdothis.com/api-reference/endpoints/reservedentries/list-reserved-entry-groups-for-an-event
/openapi.json get /v0/events/{id}/reserved-entries
Returns a paginated list of reserved entry groups associated with an event, across **every** occurrence of it. Deprecated in favor of `GET /v0/event-occurrences/{id}/reserved-entries`, which scopes to a single occurrence. This route is not a synonym for that one — it deliberately returns a wider set.
# List reserved entry groups for an event occurrence
Source: https://partner-help.letsdothis.com/api-reference/endpoints/reservedentries/list-reserved-entry-groups-for-an-event-occurrence
/openapi.json get /v0/event-occurrences/{id}/reserved-entries
Returns a paginated list of reserved entry groups for a single occurrence of an event. Prefer this to the event-scoped list, which spans every occurrence.
# Update a reserved entry group
Source: https://partner-help.letsdothis.com/api-reference/endpoints/reservedentries/update-a-reserved-entry-group
/openapi.json patch /v0/reserved-entries/{id}
Updates a reserved entry group. Returns 409 Conflict when the requested allocation cannot fit within the available capacity.
# Get a ticket by ID
Source: https://partner-help.letsdothis.com/api-reference/endpoints/tickets/get-a-ticket-by-id
/openapi.json get /v0/tickets/{id}
Returns a single ticket by ID if it belongs to the organizer associated with your Public API credentials.
# List tickets for a race
Source: https://partner-help.letsdothis.com/api-reference/endpoints/tickets/list-tickets-for-a-race
/openapi.json get /v0/races/{id}/tickets
Returns a paginated list of tickets belonging to a given race. Results are scoped to the organizer associated with your Public API credentials.
Every ticket is returned whatever its state, apart from ones that have been deleted; read `availability` on each to tell a bookable ticket from one that is sold out, closed or not yet on sale.
# List tickets for an event
Source: https://partner-help.letsdothis.com/api-reference/endpoints/tickets/list-tickets-for-an-event
/openapi.json get /v0/events/{id}/tickets
Returns a paginated list of the bookable tickets on an event, for the occurrence we resolve for you — the next upcoming one, or the most recent if none is upcoming.
Only tickets that can be booked right now are returned: sold out, closed and not-yet-on-sale tickets are omitted, so a ticket's absence here is not evidence that it does not exist. To see every ticket on a specific date, with an `availability` on each, use the list under an **event occurrence** instead.
# List tickets for an event occurrence
Source: https://partner-help.letsdothis.com/api-reference/endpoints/tickets/list-tickets-for-an-event-occurrence
/openapi.json get /v0/event-occurrences/{id}/tickets
Returns a paginated list of the tickets on a given event occurrence. Use this when you need the tickets for a specific date — the equivalent list under an event resolves the occurrence for you, returning the next upcoming one.
Every ticket is returned whatever its state, apart from ones that have been deleted; read `availability` on each to tell a bookable ticket from one that is sold out, closed or not yet on sale. This differs from the equivalent list under an **event**, which returns only bookable tickets — so a ticket you cannot find there may still exist here.
Historical occurrences are answered the same way as any other, including those created before 2024-02-05, which previously returned `409` because their tickets could not be resolved unambiguously.
# Ingest timing data from a timing provider
Source: https://partner-help.letsdothis.com/api-reference/endpoints/timing/ingest-timing-data-from-a-timing-provider
/openapi.json post /timing-inbound/v1
Available to select timing partners on a per-account basis — contact your account manager to enable it. Authenticate with the timing-provider token issued during onboarding as a bearer token; other callers receive `401`.
Push data — bib numbers and bib-pack shipments — back to Let's Do This for startlist entries you received from us. Send one message or a batch of up to 500, each carrying at least one recognized field in `data`.
A `202` means the batch was accepted for processing, not that values were applied. Messages are applied asynchronously, and an update whose `changedAt` is older than the last applied one for the same field is skipped — bib and shipping updates are ordered independently. `messageId` de-duplicates retries, so resubmitting an entire request after a timeout or `5xx` response is safe.
Rate limit as of today: 20 requests per second.
# Public API
Source: https://partner-help.letsdothis.com/api-reference/overview
Use the Let's Do This REST API to work with your events, bookings, participants, and related data.
The Let's Do This Public API provides a REST interface for the data you use to plan, promote, and run events. Requests and responses use JSON.
Keep your API key secret. Do not share it or include it in a public website,
mobile app, or client-side application.
## Get an API key
Create an API key from the **Settings** → **Credentials** section of your Let's Do This account. Contact your Let's Do This representative if you cannot access this section.
If an API key is exposed, revoke it from the same section and create a replacement.
## Send your first request
Include your API key as a bearer token in the `Authorization` header:
```bash theme={null}
curl --request GET \
--url "https://api.letsdothis.com/v0/participants" \
--header "Authorization: Bearer YOUR_API_KEY"
```
Use the production server for live data and the staging server when testing an integration.
| Environment | Base URL |
| - | - |
| Production | `https://api.letsdothis.com` |
| Staging | `https://api.staging.letsdothis.com` |
The code samples on endpoint pages are copyable but do not send requests from
this documentation site. This prevents API keys from passing through a
documentation proxy.
## Paginated responses
List endpoints return results in `data` and pagination information in `page`:
```json theme={null}
{
"data": [
{
"id": "6399c20015d60ae3ff28f24c"
}
],
"page": {
"totalResults": 1,
"first": "6399c20015d60ae3ff28f24c",
"last": "64577f3fa6449247e0322e8e",
"prev": "",
"next": "64577f3fa6449247e0322e8e"
}
}
```
Pass `page[after]` or `page[before]` from a response into your next request. Use `page[size]` to control the number of results where the endpoint supports it.
## Optional features
Some endpoints accept a comma-separated `features` query parameter. Features add fields or behavior for one request without changing the default response contract.
For example:
```text theme={null}
GET /v0/participants?features=tags,waves
```
Each endpoint page lists the feature values it supports.
## Error responses
| Status | Meaning |
| - | - |
| `400` | The request parameters or body are invalid. |
| `401` | The API key is missing, invalid, or revoked. |
| `403` | Your organization does not have access to the requested operation. |
| `404` | The resource does not exist or is not accessible with your API key. |
| `429` | The request exceeded an API rate limit. Retry after the period indicated by the server. |
| `500` | The API encountered an unexpected error. Contact your Let's Do This representative if it persists. |
## Rate limiting
Every import endpoint, the registration-status check and the timing ingest endpoint are rate limited, so a request to one can be rejected with a `429`:
* `POST` and `PUT /v0/bookings/line-items/import`
* `POST` and `PUT /v0/add-ons/import`
* `POST /v0/bookings/import`
* `POST /v0/credits/import`
* `POST /v0/discount-codes/import`
* `POST /v0/opt-ins`
* `POST /v0/referrals/import`
* `POST /v0/reserved-entries/participants/import`
* `POST /v0/event-occurrences/{id}/registration-status`
* `POST /timing-inbound/v1`
Limits apply per API key and per endpoint, so a burst against one import does not consume the allowance of another. The registration-status check also carries a daily quota per key on top of its burst limit; its reference page states both numbers. A few endpoints outside this list carry their own, separate allowances — the `x-ratelimit-*` headers on a response are what tell you a limit applies, so treat `429` as a response any endpoint can return.
Sequential requests are unlikely to be affected. Sending requests in parallel, which is the natural way to drive a bulk import, is what exhausts an allowance.
Every response from these endpoints reports the current state of your allowance:
| Header | Meaning |
| - | - |
| `x-ratelimit-limit` | Requests permitted in the current window. |
| `x-ratelimit-remaining` | Requests still permitted in the current window. |
| `x-ratelimit-reset` | Seconds until the current window resets. |
A rejected request also returns a `retry-after` header with the number of seconds to wait:
```json theme={null}
{
"statusCode": 429,
"error": "Too Many Requests",
"message": "Rate limit exceeded, retry in 1 second"
}
```
Treat these headers as the authoritative source rather than hard coding a
figure. Which endpoints are limited, and how generous each allowance is, can
change.
Handle a `429` by waiting for the period given in `retry-after` and retrying. A rejected request is never processed, so retrying it is safe — no import is partially applied because of a rate limit.
## OpenAPI schema
You can [download the OpenAPI schema](/openapi.json) to use with tools such as Postman or an OpenAPI client generator.
See the [API changelog](/api-reference/changelog) before upgrading an existing integration.
# Scoped API keys
Source: https://partner-help.letsdothis.com/api-reference/scoped-keys
Limit an API key to specific event occurrences, endpoints and booking form answers.
An API key normally has access to everything in your organization. A **scoped key** carries restrictions that limit what it can reach, and every call is checked against them. Use one whenever someone needs narrower access than a full key gives.
A scoped key looks and behaves like any other API key: same header, same base URLs. The only difference is what it is allowed to call.
## How restrictions work
A scoped key is limited in up to three ways, and every call is checked against each one it carries:
* **Event occurrences** — the key can only act on the occurrences it carries.
* **Endpoints** — the key can only call the endpoints it carries. Values are stable names such as `registrationStatus`, not URL paths, so a key stays valid if a path changes.
* **Booking form answers** — on endpoints that return participants by their answer to a booking form field, the key can only ask for the fields and answers it carries. This one works differently from the other two: a scoped key without any answers can't call those endpoints at all, rather than asking for any answer.
Endpoints that do not support scoped keys are off-limits to every scoped key. Each endpoint that does support them says so, and names its id, on its own reference page.
### Out-of-scope calls
A call outside the key's scope is refused, and the message says why. An occurrence the key does not carry:
```json theme={null}
{
"statusCode": 403,
"error": "Forbidden",
"message": "This API key is not permitted to access event occurrence 12345678902"
}
```
An endpoint the key does not carry, or one that does not support scoped keys at all:
```json theme={null}
{
"statusCode": 403,
"error": "Forbidden",
"message": "This API key is not permitted to call this endpoint"
}
```
A booking form field or answer the key does not carry — for example, asking for `No thanks` with a key granted `Opt-in`:
```json theme={null}
{
"statusCode": 403,
"error": "Forbidden",
"message": "This API key is not permitted to ask for this booking form answer"
}
```
A `403` means the key is working but the call is out of scope; a `401` means the key itself is invalid or has been revoked.
### Checking a key's scope
[`GET /identity`](/api-reference/endpoints/identity/show-what-your-api-key-can-reach) is available to every key, scoped or not, and returns what the calling key can reach:
```bash theme={null}
curl --request GET \
--url "https://api.letsdothis.com/identity" \
--header "Authorization: Bearer PARTNER_API_KEY"
```
```json theme={null}
{
"organiserId": "81274",
"eventOccurrenceIds": ["12345678901"],
"endpoints": ["registrationStatus"],
"formFieldAnswers": []
}
```
Every list is empty for a key with full access. A partner can call this to confirm what they were given; you can call it to check a key without opening the dashboard.
## Managing scoped keys
Scoped keys are created, edited and revoked alongside your other API keys, under **Settings** → **Credentials** → **Public API** in the dashboard. The screen walks you through choosing what a key can do.
Two things worth knowing that the screen does not spell out:
* Restrictions are part of a key from the moment it is created; there is no window in which it is unrestricted.
* Editing a key's restrictions does not change its secret. The partner holding the key does not need to do anything, and the new scope applies within a minute — this is how to roll a key over to next year's edition without re-issuing it. Revoking a key also takes up to a minute to propagate.
## Use case: a partner registration check
The most common reason for a scoped key is a partner who needs one answer from you — whether an email is registered for an event — and nothing else.
Create a key limited to the occurrences the partner should be able to check and to the registration check itself — the dashboard offers this as a single choice. The partner can check whether an email is registered for those occurrences. They cannot list participants or bookings, read or change event setup, or reach any other part of the API — they see a yes or a no, never participant details.
With the key, the partner calls the registration check for one of the chosen occurrences:
```bash theme={null}
curl --request POST \
--url "https://api.letsdothis.com/v0/event-occurrences/12345678901/registration-status" \
--header "Authorization: Bearer PARTNER_API_KEY" \
--header "Content-Type: application/json" \
--data '{ "email": "runner@example.com" }'
```
```json theme={null}
{ "eventOccurrenceId": "12345678901", "registered": true }
```
An email that is not registered answers `false` rather than an error. Only confirmed places count; matching ignores case and surrounding whitespace. The check is rate limited per key, so a checkout should ask once per customer rather than on every page load. See [Check whether an email is registered](/api-reference/endpoints/eventoccurrences/check-whether-an-email-is-registered) for the full contract and the exact limits.
Everything else the partner tries — another occurrence, `GET /v0/participants` even for a chosen occurrence — answers `403` as described above. Participant and booking lists stay with your own unrestricted keys.
## Use case: sharing an opt-in audience with a partner
A booking form can ask participants whether they want to hear from a partner — "Tick this box to hear from our official coaching app". A scoped key lets you hand that partner exactly the people who ticked it, and nobody else.
Create a key limited to the occurrences the partner should see, to the form field responses endpoint, and to the field and answer that mean consent. The field is named by the public ID you gave it, and the answer must be one of the options the field offers:
```json theme={null}
{
"organiserId": "81274",
"eventOccurrenceIds": ["12345678901"],
"endpoints": ["formFieldResponses"],
"formFieldAnswers": [{ "publicId": "marketingOptIn", "values": ["Opt-in"] }]
}
```
The partner asks for that answer on one of the chosen occurrences:
```bash theme={null}
curl --request GET \
--url "https://api.letsdothis.com/v0/event-occurrences/12345678901/form-field-responses/marketingOptIn?value=Opt-in" \
--header "Authorization: Bearer PARTNER_API_KEY"
```
They receive the confirmed participants who gave that answer, with their name, email and matched answer. Other booking form answers are not included. Asking for another answer (`?value=No thanks`), another field, or `GET /v0/participants` answers `403`. See [List participants by their answer to a booking form field](/api-reference/endpoints/participant/list-participants-by-their-answer-to-a-booking-form-field) for the full contract.
Before sharing, check that the field's wording promises what the partner will receive. If it says you'll pass on something this endpoint doesn't return, or the reverse, change the wording or the arrangement first.
## Endpoints that support scoped keys
| Endpoint | Id | Occurrence-scoped |
| - | - | - |
| [`POST /v0/event-occurrences/{id}/registration-status`](/api-reference/endpoints/eventoccurrences/check-whether-an-email-is-registered) | `registrationStatus` | Yes |
| [`GET /v0/event-occurrences/{id}/form-field-responses/{publicId}`](/api-reference/endpoints/participant/list-participants-by-their-answer-to-a-booking-form-field) | `formFieldResponses` | Yes, and answer-scoped |
| [`GET /identity`](/api-reference/endpoints/identity/show-what-your-api-key-can-reach) | always allowed | — |
Every other endpoint answers `403` to a scoped key, including ones that name an occurrence in their URL.
# Individual applications
Source: https://partner-help.letsdothis.com/docs/ballots-applications/individual-applications
Let participants apply for themselves, then select who gets a place — by ballot or by reviewing each application.
Application tickets are set up for you by Let's Do This — they are not
self-serve. To add an individual application ticket to your event, contact
your Technical Account Manager.
An **individual application** is a request from a single participant for their own place. It is the building block of a ballot — individuals apply, and a set number are drawn at random — but you can also use it without a ballot to review and approve applicants one by one.
Reach for individual applications when each person applies for themselves and you want control over who gets in: an oversubscribed ballot, or an event where you check something about each applicant before granting a place.
## Participant experience
On your event page, the application ticket shows an **Apply now** button. The participant selects how many places they want, enters their details, and provides a payment method.
After applying, the participant sees a confirmation that sets expectations. For a ballot it reads that they have been entered; otherwise it confirms their application has been received. They understand they have applied, not secured a spot.
Depending on the payment timing set up for your ticket, the participant is either charged now or only if they are selected. On a **Pay when successful** ticket, their card is pre-authorized when they apply and charged only on approval. Their card must stay valid until the decision is made.
Approved applicants receive a unique, single-use link to claim their reserved entry. They open it, complete the entry form, pay if payment is due at that point, and then appear on your **Startlist**.
## Application statuses
Each individual application carries a status so you always know where it stands:
| Status | What it means |
| - | - |
| **Pending** | Applied and awaiting your decision or the draw |
| **Successful** | Selected — a reserved entry has been, or will be, created on approval |
| **Unsuccessful** | Not selected |
| **Pending payment** | Approved on a **Pay when successful** ticket, with payment not yet taken |
| **Cancelled** | The applicant cancelled their application |
## Viewing and managing applications
Your **Applications** table lists every application for the selected ticket. You can search by application ID, applicant name, or email, filter by status, and export results. Open any application to review the details and update its outcome.
## Approving and rejecting applicants
To decide an application without running a ballot, open it from your **Applications** table and mark it **Successful** or **Unsuccessful**. This suits events where you are checking each applicant individually rather than drawing at random.
When you mark an applicant **Successful**, the system creates a reserved entry — a held place they claim through their unique link.
## Running a ballot draw
A ballot selects a set number of applicants at random from those who are **Pending** and match the ballot's criteria. Ballots are configured and run by your Technical Account Manager — see [Setting up a ballot](/docs/ballots-applications/setting-up-a-ballot) for how a ballot is structured and what decisions you make together.
## Guaranteeing a place before the draw
If your event uses a ballot, you can mark a specific applicant **Successful** ahead of the draw — for example to guarantee someone a place.
This updates their status as if they had been drawn, but **nothing else** is
processed — no emails, bookings, payments, or reserved entries — until the
ballot is run and closed. Use it to lock in an outcome, not to skip the draw.
## The Startlist
Approving an application does not put the participant on your Startlist straight away. Approval creates a reserved entry and sends the participant their claim link. They only appear as a confirmed participant once they open that link and complete the entry form.
Until then they hold a place but have not finished registering, so your successful-applicant count and your Startlist count will not match until everyone has claimed.
## Applicant notifications
Applicants are notified of their outcome when the ballot is closed or when their application is updated:
* **Successful applicants** receive an email containing their unique claim link and instructions to complete their entry.
* **Unsuccessful applicants** receive an email letting them know they were not selected.
Coordinate the timing of outcome notifications with your Technical Account Manager so that emails go out at the right moment — for a ballot, this lines up with the close step rather than the draw itself.
## Next steps
* [Setting up a ballot](/docs/ballots-applications/setting-up-a-ballot) — how a ballot is configured and run for your event.
* [Partner applications](/docs/ballots-applications/partner-applications) — block allocations for partners, charities, and companies.
# Partner applications
Source: https://partner-help.letsdothis.com/docs/ballots-applications/partner-applications
Let partners, charities, and companies request a block of entries, then allocate a group of places for them to distribute.
Partner application tickets are set up for you by Let's Do This. To accept
partner applications on your event, contact your Technical Account Manager.
A **partner application** is a request from an organization — a partner, charity, or company — for a block of entries, rather than a single participant applying for themselves. The organization applies for the places it wants, and on approval you allocate a group of reserved entries it distributes to its own people.
Use partner applications when you allocate places to organizations rather than individuals: charity places, company team blocks, or official partners who bring their own participants.
The key difference from an individual application is the allocation: approving a partner allocates a *group* of reserved entries the organization hands out, rather than a single place. The rest of the journey — apply, approve, claim — is covered in [What are applications?](/docs/ballots-applications/what-are-applications).
## Collecting information from the partner
You can add questions to the application form for the organization to answer when it applies — for example a contact name, the organization it represents, or how many places it expects to use. Their answers come through with the application, so you have the information you need before deciding.
## Paying for places
Companies can pay up front for their block of places using the **Pay when successful** setting: their card is pre-authorized when they apply, and the charge is taken once you approve the application. This secures payment for the allocation at the point you grant it.
## Approving a partner application
Find the partner application in your **Applications** table — you can search by partner as well as by applicant name, email, or application ID — and open it to review.
On the approval screen, set up the group of reserved entries the partner will receive — the block of places they can hand out.
Approve to allocate the entries. The partner can be notified by email and receives links to claim and distribute their places. Each place is then claimed and completed individually.
Approving allocates a block of held places — it doesn't put anyone on your
Startlist yet. Your Startlist fills up as the partner distributes places and
each person completes their entry form, so an allocated block and your
Startlist count won't match until every place is claimed.
## Partner management access
Once you approve a partner, they distribute and track their allocated places from their own **partner dashboard** — a separate area their organization logs into. They invite people to fill places, watch their fill rate, and manage individual entries from there. See [Partner dashboard](/docs/ballots-applications/partner-dashboard) for what your partners can do.
## Checking for duplicate applications
Organizations sometimes apply more than once. Ask your Technical Account Manager to check for duplicates and a list of potential matches is generated from first name, last name, and email address, so you don't allocate the same place twice.
# Partner dashboard
Source: https://partner-help.letsdothis.com/docs/ballots-applications/partner-dashboard
Where your partners manage and distribute the reserved entries you allocate to them.
This page is for **you, the organizer** — how to give partners access, what
you control, and how to support them. For the step-by-step instructions to
**share with your partners**, send them the [Partner dashboard
guide](/docs/ballots-applications/partner-dashboard-guide) and, where it
applies, the [Partner discounts and invoicing
guide](/docs/ballots-applications/partner-invoicing-guide).
When you allocate a block of reserved entries to a partner — either directly or
by approving a [partner
application](/docs/ballots-applications/partner-applications) — they manage and
distribute those places from their own **partner dashboard**, a separate area
they log into. You never need Let's Do This to set this up, and you can open the
dashboard yourself, as if you were the partner, to operate it on their behalf and
troubleshoot.
A **partner** is an organization you allocate entries to — a charity, company, or
official partner — rather than an individual participant. A **reserved entry** is
a held place; a group of them is what a partner receives to hand out.
A partner has a separate dashboard for **each organizer** they work with. In
the dashboard for your organization, they see all of your events they hold
entries for — they'll have a different dashboard for another organizer's
events.
## Giving a partner access
Give the partner a block of reserved entries from your event — directly, or by approving a partner application. This is what grants them dashboard access; there's no separate invite step to manage.
The partner receives an email invitation and claims their permissions with the **work email you granted access to**. Point them to the [Partner dashboard guide](/docs/ballots-applications/partner-dashboard-guide) for the exact steps.
A partner must log in with the exact email the access was granted to, or
they'll see a permissions error. Ask them to check their spam folder for the
invitation first; if they need access on a different address, you or your
Technical Account Manager can issue a fresh invitation link.
## Organizer controls
You set the rules when you **create the reserved entries** — the partner works
within whatever you choose. Your settings decide:
* **Which tickets** the reserved-entry link unlocks.
* **Any discount** applied automatically at checkout.
* Whether each link is **single-use and tied to one person's email** (name and email pre-filled for that person) or a shared multi-use link.
* Whether the partner can **cancel entries** from their dashboard.
* Whether each of the partner's team members gets **view-only** or **full** access, so some can only watch progress while others distribute and manage entries.
When you make links single-use and tied to a specific email, the recipient's
name and email are pre-filled and any discount is applied for them
automatically. Each link is then meant for one named person, so encourage
partners to double-check the data they upload before sending.
## Partner tasks
Once they're in, partners run the day-to-day distribution themselves. In
summary, they can allocate places to people, send and re-send invitation emails,
track each place from **Not allocated** through to **Completed**, cancel entries
if you allowed it, and export their data. If you've enabled marketing opt-ins,
they can also see and export the participants who opted in to hear from them.
The full walkthrough lives in the [Partner dashboard
guide](/docs/ballots-applications/partner-dashboard-guide) — that's the link to
share with them. A place only shows as **Completed**, and the participant only
appears on your Startlist, once the person who received the link finishes their
own registration.
## Discounts and invoicing
If you've enabled partner discounts and invoicing, partners can lower the price
their participants pay by covering part of the cost themselves, then settle the
resulting invoices. You control whether a group is **paid upfront** (entries lock
until the invoice is paid) or **paid as entries are claimed** when you set up the
reserved entries. Share the [Partner discounts and invoicing
guide](/docs/ballots-applications/partner-invoicing-guide) with partners who have
this available.
## Supporting a partner directly
* A partner sees **only their own** organization, events, and entries — never your full organizer dashboard or another partner's data.
* You can open a partner's dashboard yourself to see exactly what they see and help them directly.
* Your Technical Account Manager can help with access or allocation questions.
# Partner dashboard guide
Source: https://partner-help.letsdothis.com/docs/ballots-applications/partner-dashboard-guide
For partners: how to log in to your partner dashboard, distribute your reserved entries, and track registrations.
This guide is written for **partners** — charities, companies, and
organizations that have been given a block of entries to an event.
Your **partner dashboard** is where you manage the entries an event organizer has given you. From it you invite people to take your places, watch registrations come in, and export your data. A **reserved entry** is a place held for you to hand out using a special link.
You have a separate dashboard for each organizer you work with. The dashboard for one organizer shows all of their events you hold entries for; another organizer's events live on a different dashboard.
## Logging in
You'll receive a link by email. Clicking it takes you to Let's Do This.
![The partner invitation email containing the link that opens Let's Do This to claim access]()
Create an account with your **work email address** — or log in as usual if you already have one. Use the email address you want the permissions on.
Once you're logged in, click the button to **claim your partner permissions**.
In the navigation bar at the top, click **Partner Dashboard**. You'll see a list of the events you've been granted permissions for. Click into an event to open its **Reserved Entries** page or view your **Marketing opt-ins**.
![The Partner Dashboard showing the list of events you hold entries for]()
Events won't show until you've been allocated entries or have marketing
opt-ins. If your dashboard looks empty, your organizer may not have made the
allocation yet.
### Login problems
* **No invitation email?** Check your spam folder, or contact your event organizer to ask for a new one.
* **Seeing a permissions error?** You've probably logged in with an email that doesn't have permissions. Log out and back in with the exact email address the access was granted to.
* **Need access on a different email?** Ask your event organizer to send an additional claim link.
## Sending invitations to your participants
Your reserved entries work through links you send to participants, letting them enter the event themselves. Your organizer sets the rules for these links — which tickets they unlock and any discount that's applied automatically at checkout.
Depending on the settings your organizer chose, reserved entry links can be
**single-use** and tied to a specific person's email address — so a link works
only once, for that one person. When that's the case, the recipient's first
name, last name, and email are pre-filled, so double-check the details you
upload to make sure each invitation reaches the person it's meant for.
From your Partner Dashboard, select the event, then choose **Reserved Entries** in the left-hand menu. This page summarizes the entries you've been granted.
![A reserved entry card on the Reserved Entries page showing entries unallocated, with View entries and Apply discount buttons]()
Click **View entries** to open a page where you can view, manage, and allocate your entries.
First, tick the checkboxes on the left to select the entries you want to allocate — you can't allocate until at least one entry is selected. Then click **Modify** and choose **Allocate**. In the window that opens, upload a CSV of your participants' names and email addresses, or enter people one at a time. You can send a test email to yourself first to see the design, then email the invitation links out.
![Reserved entries selected with the Modify menu open, showing the Allocate option]()
![The Allocate window for uploading a CSV of participant names and email addresses, or adding people manually]()
Save your sheet as a **CSV** file so it uploads correctly, and include first
and last name columns so each email is personalized and you can keep track of
who you've allocated a place to.
### Tracking your registrations
After you send invitations, you get a confirmation screen and can return to your dashboard to watch registrations arrive in real time. Sort by columns and search the table to find specific entries. Each place shows one of these statuses:
| Status | What it means |
| - | - |
| **Not allocated** | This entry hasn't been used yet |
| **Allocated** | This entry has been assigned to someone, but no invitation has been sent yet |
| **Invitation sent** | An invitation email has been sent at least once |
| **Completed** | This person has successfully registered for the event |
| **Cancelled** | This entry has been cancelled |
Use **Modify** to send invitations again or keep allocating entries. If your organizer has given you permission, you can also cancel entries from there.
### Exporting your data
Click the **Export** button on the right to download your data as a CSV or XLSX file. The whole table is exported, including reserved entries that haven't been allocated yet. To turn a CSV into an XLSX, open it in Excel and choose **Save as** with an Excel format.
## Your marketing opt-ins
From your Partner Dashboard, select an event and click **Marketing opt-in** in the left-hand menu. You'll see a table of everyone who opted in to hear from you, including how many other charities each person opted to hear from. Click **Export** at the top right to download it as a CSV.
By downloading this data you confirm you'll only contact entrants about the
event they applied for — and other events associated with your organization —
in the ways they specified. If you bought advertising on a general or ballot
entry form, those opt-ins also appear here.
## Participant experience
When you send an invitation, your participant receives an email with their reserved entry link inside an **Enter now** button. Clicking it takes them to the ticket selection page, where only the tickets available to them appear and any discount is applied automatically.
Once they complete the form and confirm their entry, they receive a confirmation email and a receipt. They can return to manage their booking from a link in that confirmation email — to view their fundraising page and event information, or update their details if anything changes.
## Discounting your entries and paying invoices
If your organizer has enabled it, you can lower the price your participants pay by covering part of the cost yourself, then settle the invoices for what you cover. See the [Partner discounts and invoicing guide](/docs/ballots-applications/partner-invoicing-guide) for how it works. If you don't see an **Apply discount** button or a **Payments** page, your organizer hasn't turned this on for your entries.
## Additional support
If something didn't make sense or you're still stuck, contact your event organizer, who can also open your dashboard to help you directly.
# Partner discounts and invoicing
Source: https://partner-help.letsdothis.com/docs/ballots-applications/partner-invoicing-guide
For partners: discount your reserved entry links so participants pay less, and settle the invoices for the entries you cover.
This guide is written for **partners** — charities, companies, and
organizations that have been given a block of entries to an event. For how to
log in and send invitations, start with the [Partner dashboard
guide](/docs/ballots-applications/partner-dashboard-guide).
Discounts and invoicing are available only when your event organizer has
turned them on for your entries and set up how you'll be billed. If you don't
see an **Apply discount** button or a **Payments** page, your organizer hasn't
enabled this yet — contact them to ask.
A **discount** lets you lower the price your participants pay by covering part
of the cost yourself. When you discount your reserved entry links, each
participant pays less at checkout and you're billed for the difference. This
guide covers how to apply a discount, how the two billing arrangements work, and
how to settle your invoices.
Two things shape how you pay:
* **Whether your organizer set your entries to *pay upfront* or *pay as you go*.** You don't choose this — your organizer does, and it decides when you pay and whether your entries lock until you've paid.
* **The discount you apply** — a flat amount off or a percentage off, applied to the whole group.
## Single-use and multi-use links
Your entries are grouped by how their links work. You'll see both types split
into their own sections on your Reserved Entries and Payments pages.
Each participant gets their own unique link that claims a single entry. Use
these to invite specific people.
One shared link anyone can use to claim an entry, up to the group's
capacity. Share it wherever you like — only multi-use groups give you a
**Copy invite link** option.
The link type changes how you *share* entries, not how you discount them. A
discount always applies to the **whole group** — you can't discount only some
entries in a group, whichever link type it uses.
## Discounting your entries
You apply a discount from your **Reserved Entries** page. A group can only be
discounted while it still has unclaimed entries, and entries that were already
claimed keep the price they were claimed at.
![A reserved entry card on the Reserved Entries page with the Apply discount button in the card footer]()
From your Partner Dashboard, select the event and open **Reserved Entries**.
Each group appears as a card showing how many entries it holds and how many
have been claimed.
On the group you want to discount, click **Apply discount**. If the group
already has a discount, use the card's three-dot menu and choose **Edit
discount** instead. The **Discount entries** window opens.
![The Discount entries window with the Minus / Percentage dropdown and the You cover and Each participant pays summary]()
Under **Apply a discount**, pick how much you'll cover:
* **Minus (-)** — a flat amount off each entry (for example, \$10 off).
* **Percentage (%)** — a percentage off each entry, from 0 to 100.
With a percentage discount you can also tick **Allow booking fee to be
discounted** to cover part of the booking fee too. A flat discount never
touches the booking fee.
As you type, a live summary shows the **Ticket price**, the **Booking fee**,
how much **You cover**, and what **Each participant pays**. It also shows how
you'll be invoiced, which depends on your billing arrangement (see below).
Click **Save discount**. What happens next depends on whether your entries
are pay upfront or pay as you go.
## Pay upfront vs. pay as you go
Your organizer sets one of two billing arrangements per group. The **Discount
entries** window tells you which one applies before you save.
Your entries **lock until the invoice is cleared**. Saving a discount raises
a single invoice for the group's remaining entries, and participants can't
claim their places until you've paid it. This locks in today's price.
You're **billed for each entry as a participant claims it** — nothing locks,
and you can start sharing straight away. You settle what's been claimed
whenever you like, up to a final due date.
![A reserved entry card in the pay-upfront locked state, showing entries locked until paid in amber]()
**Pay upfront.** After you save, you'll see a note like *"These are pay-upfront,
so you'll be able to share them once the invoice has been paid."* The group
shows how many entries are locked until paid, and a **Pay for entries** button
takes you to your Payments page to settle up. Once the invoice is paid, the
entries unlock and you can share them.
**Pay as you go.** After you save, you're ready to share immediately — your
invite link works right away and you're billed as participants claim their
places. You may see a **Final payment due** date for settling the remainder.
## Settling your invoices
Your **Payments** page lists every group that needs invoice payments, split into
single-use and multi-use sections. Use the search box to find a group and
**Refresh** to pull in the latest status — payment happens on a secure Stripe
page in a separate tab, so refresh after paying to see it update.
![The Payments page listing reserved entry groups as cards, each showing paid of total and a progress bar]()
Each group card shows:
* A paid-vs-total line, such as **paid / total paid for**, with a progress bar.
* How many entries are **paid for** and how many have been **claimed**.
* A **Final payment due** date where one applies. This turns red as the date approaches or once it's overdue.
Click **View invoices** on a group card. You'll see **Total**, **Paid**, and
**Outstanding** totals, followed by the list of invoices for that group.
Each invoice shows its amount, the number of entries it covers, a reference,
the date, and a status.
![A group's invoices view with Total, Paid, and Outstanding summary tiles above the list of invoices and their status badges]()
Click **Pay now** — either on the group card, or on an individual invoice
after opening **View invoices**. This opens a secure Stripe payment page in a
new tab. For a pay-as-you-go group, you'll first confirm the payment for the
entries claimed so far, then continue to Stripe. Complete the payment there.
![A group card on the Payments page with the Pay now button, showing entries locked until paid and a final payment due date]()
![A group's invoices with an invoice marked Due now, alongside Download invoice and Pay now buttons]()
Return to your Payments page and click **Refresh**. The invoice status
updates to **Paid**, and for pay-upfront groups the entries unlock so you
can share them.
To reopen a payment page for an invoice you've already started or paid, use
**View invoice** on that invoice.
### Invoice statuses
| Status | What it means |
| - | - |
| **Due now** | The invoice is outstanding and waiting to be paid. |
| **Paid** | The invoice has been paid in full through Stripe. |
| **Paid — offline** | Your organizer has recorded this invoice as settled outside Stripe. |
| **Voided** | The invoice was cancelled and no longer needs to be paid. |
## Changing or removing a discount
You can edit a discount from the group's three-dot menu using **Edit discount**,
or remove it with **Remove discount**.
**What happens:** Removing a discount stops covering future claims — new claims
pay full price. Entries that were already claimed keep the price they had.
**Why:** On a pay-upfront group, removing the discount also cancels that group's
unpaid invoice. On a pay-as-you-go group, you can't change the discount while an
invoice for the current discount is still unpaid — you'll see *"This group has
an unpaid invoice for the current discount. Pay it before changing the
discount."* Pay or cancel that invoice first.
## Cancelling an invoice
On pay-as-you-go groups, you can cancel an outstanding (**Due now**) invoice
from its row.
**What happens:** Cancelling voids the invoice — its Stripe payment page stops
working, and anything it billed becomes payable again on a future invoice.
**Why:** An invoice that has already been paid can't be cancelled, and
pay-upfront invoices can't be cancelled this way — remove the discount instead
to cancel a pay-upfront group's unpaid invoice.
## Entries that can't be discounted yet
**What happens:** A pay-upfront group that contains more than one ticket type
can't be discounted at the moment. You'll see a message asking you to contact
your event organizer.
**What to do:** Contact your organizer — they can adjust the group or arrange
the discount another way.
Some groups also can't be discounted because there's nothing to discount: a
group whose entries are already **free**, a group that's **fully paid**, or a
group where **all entries have already been claimed**.
## Additional support
If something didn't make sense or you're still stuck, contact your event
organizer, who can also open your dashboard to help you directly.
# Setting up a ballot
Source: https://partner-help.letsdothis.com/docs/ballots-applications/setting-up-a-ballot
Run a ballot to draw a set number of places at random from everyone who applied and matches your criteria.
Ballots are configured and run for you by Let's Do This. When none has been
set up, your event prompts you to contact your Technical Account Manager to
configure one. This page explains how a ballot works and the decisions you'll
make together.
A **ballot** (also called a lottery) allocates places at random instead of selling them first-come: you collect applications, then draw a set number of winners from the pool. It suits a heavily oversubscribed event: you can open registration to everyone without places selling out in minutes.
Use a ballot when demand far exceeds supply and you want every applicant to have an equal chance. If you need to choose applicants on merit — a qualifying time, say — a ballot isn't the right fit; review applications individually instead. You can also combine the two: draw most places by ballot and hand-pick a few.
Not sure a ballot is right for you? Let's Do This can consult on whether it
fits your event and your business, and help you set it up.
## The two types of ballot
There are two ways to run a ballot. Both are valid — the choice is which suits your event and business best, and your Technical Account Manager can advise:
* **Pay when successful.** Entrants' cards are pre-authorized when they apply and charged only if they're drawn. Best when you want payment secured up front.
* **Claim windows.** Winners are given a window in which to claim their place and pay. Once the window passes, unclaimed places can be released. Best when you want to give winners time to commit.
## Organizer decisions
These choices shape the ballot — worth settling before you talk to your Technical Account Manager:
* **How many places to draw.** The maximum number of applicants marked successful.
* **Which applications are eligible.** The application ticket the ballot runs against, plus any criteria an applicant must match to be included.
* **What successful applicants receive.** The entry ticket winners get when the ballot closes — the actual place at your event.
* **Whether to reject everyone who isn't drawn.** Automatically mark unsuccessful applicants, or leave them pending for a later draw.
* **When applicants pay** — at the point of applying, or only if they're successful. See [Participant payment](/docs/ballots-applications/what-are-applications#participant-payment).
## Ballot process
A ballot moves through three stages. Your Technical Account Manager runs the draw and close steps; you watch the results update in your Applications table.
Participants apply through the ticket on your event page, and each arrives as **Pending**. Entrants see a confirmation that they've been entered into the ballot — not that they've secured a place.
A set number of applicants are selected at random from those who match the criteria and updated to **Successful**. If you chose to reject the rest, the remaining matched applicants are marked **Unsuccessful** at the same time. A summary shows how many were drawn and how many will be rejected.
Closing turns the result into real places: each successful applicant gets a reserved entry and a unique, single-use link to claim their place and complete the entry form. You choose when to close, so you can line up your applicant communications first.
Results aren't announced the moment a draw runs — closing the ballot is what
generates each winner's claim link. Coordinate the timing of your "you're in"
and "not this time" messages with your Technical Account Manager so they line
up with the close step.
## Running more than one draw
You don't have to allocate every place at once. Leave non-drawn applicants **Pending** rather than rejecting them and they stay in the pool for a later draw — useful for releasing places in waves or filling spots that open up. Agree a multi-draw plan with your Technical Account Manager up front.
## Guaranteeing a place before the draw
You can mark a specific applicant **Successful** ahead of the draw — for example to guarantee someone a place.
This updates their status as if they'd been drawn, but **nothing else** is
processed — no emails, bookings, payments, or reserved entries — until the
ballot is run and closed. Use it to lock in an outcome, not to skip the draw.
# What are applications?
Source: https://partner-help.letsdothis.com/docs/ballots-applications/what-are-applications
Let participants apply for a place rather than buy instantly, then select who gets in — by lottery or review.
Applications and lotteries are set up for you by Let's Do This — they are not
self-serve. To add an application ticket or run a lottery for your event,
contact your Technical Account Manager. This page explains what the system can
do and why you might use it, so you know what to ask for.
Applications let participants **request** a place at your event instead of buying a ticket outright. They apply for the places they want and choose how they'll pay, and you decide who gets in. When you approve someone, the system creates a **reserved entry** — a held place the participant claims through a unique link — and after they complete the entry form they appear on your Startlist like any other participant.
Reach for applications whenever demand outstrips places, or when a place should be granted rather than sold first-come. Common uses:
* **Lotteries (ballots)** for oversubscribed events, where places are drawn at random from a pool of applicants.
* **Partner, charity, and company allocations**, where an organization requests a block of entries.
* **Vetting** applicants — for example checking a qualifying time — before granting a place.
If everyone who wants a ticket should simply be able to buy one, you don't
need applications — a standard ticket is the better fit.
## The two kinds of application
A single participant applies for themselves. Used most often for lotteries,
where individuals enter and a set number are drawn at random.
A partner, charity, or company applies for a block of entries. On approval
you allocate a group of reserved entries for them to distribute to their
own people.
## Application process
The journey is the same whether you select applicants by lottery or review them one by one:
On your event page, an application ticket shows an **Apply now** button instead of a normal add-to-basket flow. The participant applies for the places they want and chooses their payment method.
New applications arrive as **Pending** in your **Applications** table. Nothing is charged yet beyond what your payment timing requires.
Decide the outcome — either by running a lottery (set up by your Technical Account Manager) or by reviewing applications and marking each one **Successful** or **Unsuccessful**.
Approval creates the reserved entry and sends the participant a unique, single-use link. They open it, complete the entry form, pay if payment is due, and then appear on your **Startlist**.
Approving an application doesn't put the participant on your Startlist right
away — it creates a held place and a claim link. They only become confirmed
once they open that link and complete the entry form, so a
successful-applicant count and your Startlist count won't match until everyone
has claimed.
## Participant payment
When your application ticket is set up, you choose **when** a successful applicant is charged:
* **Pay now** — the full price is taken at the point of applying.
* **Pay when successful** — the participant is only charged if they're selected.
With **Pay when successful**, the participant's card is **pre-authorized**
when they apply, not charged. The charge is only taken if they're approved.
Their card must stay valid until the decision is made — if the payment can't
be taken when they're selected, the place can be offered to someone else.
## Application statuses
Each application carries a status so you always know where it stands:
| Status | What it means |
| - | - |
| **Pending** | Applied and awaiting a decision |
| **Successful** | Selected — a reserved entry has been, or will be, created |
| **Unsuccessful** | Not selected |
| **Pending payment** | Approved on a **Pay when successful** ticket, with payment not yet taken |
| **Cancelled** | The applicant cancelled their application |
## Managing applications
Your **Applications** table lists every application for the selected ticket. You can search by application ID, applicant name, email, or partner, filter by status, and export the results. From here you open an application to review it, mark it **Successful** or **Unsuccessful**, and start the approval that creates the participant's reserved entry.
## Next steps
* [Setting up a lottery](/docs/ballots-applications/setting-up-a-ballot) — how a lottery is configured and run for your event.
* [Partner applications](/docs/ballots-applications/partner-applications) — block allocations for partners, charities, and companies.
# Adding an event
Source: https://partner-help.letsdothis.com/docs/creating-managing-events/adding-an-event
Create a new event on Let's Do This — from scratch or using an existing event as a starting point.
When you're ready to list a new event, open your organizer dashboard and click **Add event**. You'll be asked to choose how you want to start:
* **Copy an event** — use one of your existing events as a template. The listing content, tickets, and registration forms are carried across so you can adapt them. Choose this when the new event shares most of its setup with one you've already built. (See [Copying and renewing events](./copying-and-renewing-events) for a full walkthrough.)
* **Start from scratch** — open a blank event setup and build everything from the ground up.
Select your preferred path and click **Continue**. Either way, you land on the event setup screen — see [Event setup](./event-setup) for a full guide to configuring your races, tickets, registration forms, and event page content.
# Checkout branding
Source: https://partner-help.letsdothis.com/docs/creating-managing-events/checkout-branding
Apply your brand's colors, logo, and fonts to the participant checkout flow and post-booking pages.
Checkout branding lets you apply a custom visual theme to the checkout flow and post-booking pages that participants see when they register for your event. A branded checkout reinforces your event identity and gives participants a consistent experience from your marketing materials through to their confirmation page.
Themes are configured at the organizer level and reused across events. You can apply an existing theme to an event, or create event-specific customizations.
## Creating and managing themes
Themes live in your organizer settings. To manage them, open your dashboard and go to **Branding** in the organization settings area.
Click **Create new theme** and give it a name. Themes are reusable — name them in a way that makes it easy to pick the right one when setting up events (for example, by brand or series name).
The **Website configuration** section controls how your brand appears in the checkout and post-booking flows:
* **Brand name** — how your organization is referenced in checkout footers and automated messages.
* **Primary color** — your main brand color, used for buttons and interactive elements.
* **Appearance** — choose **Light** or **Dark** as the base theme for checkout and post-booking pages.
* **Background tint** — tints the background and card surfaces throughout the checkout.
* **Checkout header logo** — a square image (minimum 500×500 px, JPG or PNG) displayed in the header bar at the top of checkout. Use your event logo or organization logo.
* **Checkout header background color** — the color behind your logo in the header bar.
* **Heading font** — choose from a set of preset fonts for branded headings:
Barlow Condensed, Oswald, Bebas Neue, Barlow, Montserrat, Inter, Plus Jakarta Sans, Space Grotesk, DM Sans, Arial, and Helvetica. Contact your account manager if you need a custom font.
* **Heading color** — the color used for branded headings in checkout.
The **CRM configuration** section controls how your brand appears in transactional and marketing emails:
* **Logo** — your organization or brand logo, shown in email headers.
* **Button background color** and **Button text color** — the color scheme for call-to-action buttons in emails.
* **Header text color** — the color of text in the email header.
* **Body text color** — the color of body text in emails.
* **Background color** — the email background.
* **Font** — the font used throughout the email.
As you make changes, a live preview on the right shows how the ticket selection page will look with your theme applied — including your logo, colors, and font on example event content.
Click **Save** when you're happy with the theme.
## Applying a theme to an event
Once you have themes set up, apply one to a specific event from the event's setup screen.
On the event setup screen, go to **Customize appearance**. Select the theme you want to apply from the dropdown. The checkout for that event will immediately reflect the selected theme.
To use a different look for one event without changing the global theme, select **Custom** from the dropdown and configure settings specific to that event occurrence.
## Updating a theme
You can edit a theme at any time from **Branding** in your organizer settings. Changes apply immediately to any event that uses the theme.
If a theme is used by an active email campaign, updating it may affect emails
that are in-progress or scheduled to send. Review any active campaigns before
making significant changes to a shared theme.
# Copying and renewing events
Source: https://partner-help.letsdothis.com/docs/creating-managing-events/copying-and-renewing-events
Create a new event by copying an existing one, or renew a past event to carry over its historical performance data.
When you click **Add event** in your organizer dashboard and choose **Copy an event**, you can start a new event using an existing one as a template. There are two distinct flows — **Copy** and **Renew** — and choosing the right one matters because they behave differently.
Creates an independent new event with no historical link to the original.
Use this for a genuinely separate new event that happens to share a similar
setup.
Creates the next annual or periodic edition of the same event. Historical
reporting data, marketplace performance, and participant reviews carry over.
Use this for recurring events like a yearly race.
## Copying an event
Use **Copy** when you are setting up a brand new event — one that is separate from the original and should not inherit its history.
From your dashboard, click **Add event** → **Copy an event** → **Continue**.
You can also copy from the event card's menu (the **⋯** icon) → **Make a copy**.
Choose any event from your account — past or upcoming — to use as the template. All your events are available here.
* **New event name** — the title of the new event (required).
* **New start date** — must be a date in the future (required).
Review the warning about what is and isn't carried over, then click **Confirm**.
**What is copied:**
* Event listing content (descriptions, images, FAQ)
* Tickets and their configurations
* Registration forms and booking form fields
**What is not copied:**
* Reporting and registration data
* Historic startlist entries
* Event page reviews
* Ticket capacities, waitlists, and price changes
* Transactional emails
* Discount codes
* Credits
* Participant settings (withdrawals, deferrals)
Your new event is created as unlisted — not visible to the public. Review and update the setup, then contact your account manager when you're ready to go live.
A copied event is not historically linked to the original. Registration
numbers, reviews, and performance data start fresh. If you want to carry that
history over, use **Renew** instead.
## Renewing an event
Use **Renew** when you are preparing the next edition of an ongoing event — for example, next year's race. The renewed event carries forward your historical marketplace performance, reporting, and participant reviews, which helps with discoverability and year-over-year tracking.
From your dashboard, click **Add event** → **Copy an event** → **Continue**, then select **Renew** in the following modal.
You can also open this directly from the event card's **⋯** menu if that option is available.
Choose from your past events. Only completed events are available in the renew flow.
* **Next event name** — the title of the new edition (required).
* **New start date** — must be a date in the future (required).
Review the callout explaining what will and won't carry over, then click **Renew**.
**What is carried over:**
* Existing event setup and listing content
* Historic reporting data
* Participant reviews
**What is not carried over:**
* Limited capacities
* Discount codes
* Credits
* Participant settings (withdrawals, deferrals)
* Ticket price changes
Your renewed event is created as unlisted. Make any edits you need — updated dates, new pricing, refreshed content — then contact your account manager to publish it.
A renewed event is linked historically to its predecessor, so your marketplace
performance and reviews transfer to the new edition. If you want a completely
clean break, use **Copy** instead.
## Choosing between copy and renew
| | Copy | Renew |
| - | - | - |
| Use for | A new, unrelated event | The next edition of an ongoing event |
| Historical data | Not carried over | Carried over |
| Participant reviews | Not carried over | Carried over |
| Reporting | Fresh start | Continues from previous event |
| Event URL | New URL | May change — update any shared links |
# Event setup
Source: https://partner-help.letsdothis.com/docs/creating-managing-events/event-setup
Configure races, tickets, registration forms, and event page content — everything you need before going live.
The event setup screen is where you build and manage every aspect of your event. It is organized into tabs — **Details**, **Races**, **Tickets**, **Form fields**, **Forms**, and others — so you can work through each area and return to update them at any time. Click **Save** at any point to save without publishing.
## Event details and event page
All core event information and your public-facing event page content are managed from the **Details** tab.
Fill in the core fields first:
* **Event title** — the public name participants will see on the Let's Do This marketplace and in their confirmation emails.
* **Website** — your event's own website URL, if you have one.
* **Contact email address** — where participants can reach you with questions.
* **Location** — search for your venue or location. Toggle **Display full location details** on to show the complete address on the event page; leave it off to show only a general area until closer to race day.
Then fill in the event page content — the public listing on Let's Do This that participants browse and share before registering. A complete event page improves discoverability on the marketplace and answers the questions participants would otherwise email you about. You can update any of this at any time; changes go live immediately.
* **Primary Photo** — the main hero image shown at the top of the event page and in marketplace search results. Use a high-quality landscape photo.
* **Additional images** — a gallery of supporting photos.
* **Course details** — the route, terrain, elevation, or course layout.
* **What's included** — what's in the entry fee (medal, t-shirt, timing chip, finish line food, etc.).
* **Race day logistics** — bag drop, parking, start procedures, and what participants need to bring.
* **Travel** — directions, public transport options, and parking information.
* **Kit list** — what participants should wear or carry.
* **Spectators** — where spectators can watch from and how to get there.
* **FAQs** — click **Add New FAQ** for question-and-answer pairs covering anything not in the sections above (refund policy, age limits, chip timing, etc.).
* **Terms and Conditions URL** — link to your event's full T\&Cs, shown to participants at checkout.
* **Privacy Policy URL** — link to your privacy policy.
Changing your event title changes the event's URL. If you have already shared
the event page link publicly, the old URL will break. Update any published
links after renaming your event.
## Races
A race is a distinct distance, wave, or category within your event. Participants choose a race when they select a ticket, so set up your races before creating tickets.
On the **Races** tab, click **Add Race** to create a new race. Each race has:
* **Race title** — the name shown to participants (for example, "Half Marathon" or "Elite Wave").
* **Discipline** — the activity type (running, cycling, triathlon, etc.).
* **Distance** — the race length and unit (miles, K, etc.).
* **Race start time** — hours and minutes. Toggle **Display start date and time** on to show this on the event page; leave it off if you prefer to communicate start times separately.
* **Display distance** — toggle on to show the distance on the event page and ticket selector.
You can add as many races as your event has categories.
## Tickets
Tickets are the purchasable entries participants buy. Each ticket is linked to a specific race and has its own price, sale window, and settings.
On the **Tickets** tab, click **Add Ticket** to create a new ticket. Key fields:
* **Ticket title and description** — displayed at checkout and in confirmation emails.
* **Race** — which race this ticket is for. A participant buying this ticket enters that race.
* **Type** — **Standard** (anyone can buy) or **Application** (participants submit an application that you approve before a place is confirmed).
Application tickets require additional configuration. Contact your account
manager to get application tickets set up for your event.
* **Price and currency** — the amount charged at checkout. Set to zero for free entries.
* **Sale start and end dates** — when the ticket becomes available and when it closes. Outside these dates, the ticket is not shown in checkout.
* **Minimum and maximum tickets per booking** — controls how many of this ticket a single booking can include. Useful for group bookings or to prevent bulk purchases.
**Ticket toggles:**
| Toggle | What it does |
| - | - |
| Make visible in checkout | Shows or hides the ticket in the ticket selector. Turn off to temporarily hide a ticket without deleting it. |
| Mark as Sold Out | Closes sales immediately and shows a sold-out label. |
| Enable Waitlist | When capacity is full, participants can join a waiting list. See [Waitlists](../event-setup/tickets/event-create-waitlist). |
| Enable Payment Plans | Lets participants split the cost into monthly installments. See [Payment Plans](../event-setup/payment-plans). |
| Enable Fast Checkout | Shortens the booking form for participants who have registered with you before. |
| Enable check-in with race day app | Enables QR code scanning for check-in on the day. |
## Booking form fields
Form fields are the individual questions you can include in a booking form. You create and configure them on the **Form fields** tab before attaching them to a form.
On the **Form fields** tab, click **Add field**. Choose a field type, then configure its name and settings.
**Available field types:**
| Type | Use for |
| - | - |
| Text | Single-line free text (e.g., club name, emergency contact name). |
| Text area | Multi-line free text (e.g., additional notes). |
| Phone number | A phone number with country code validation. |
| Select / Dropdown | A list of options where the participant picks one (or multiple, if multi-select is enabled). |
| Date | A date input (e.g., date of birth, date of a qualifying event). |
| Checkboxes | Multiple options where the participant can select several. |
| Radio buttons | Multiple options where the participant picks exactly one. |
| Address | A structured address input (street, city, postcode, country). |
| Waiver | A legal agreement participants must acknowledge. See [Waivers](./waivers). |
| Email | An email address input with format validation. |
| Duration | A time duration input (e.g., a qualifying race finish time). |
For most field types, you can mark the field as required and add a description or placeholder to guide participants.
Standard participant details — first name, last name, email, date of birth, gender — are collected automatically on every booking and do not need to be added as custom fields.
**Charity marketing opt-in** is an additional field type available for events
with a charity partner. It presents participants with an opt-in to receive
communications from the charity. This field type is configured by Let's Do
This staff — contact your account manager to add it to your event.
## Booking forms
A booking form groups fields together and attaches them to a specific ticket. Participants buying that ticket complete its form at checkout. Each form is attached to exactly one ticket — create one form per ticket that needs custom questions.
On the **Forms** tab, click **Add Form**. Give the form a name, select the ticket it applies to, and ensure **Booking Enabled** is turned on so it appears at checkout.
With a form open, add the fields you created on the **Form fields** tab. You can set the order fields appear in, and configure conditionality to show or hide individual fields based on earlier answers.
### Conditional fields
Fields on a form can be set to show or hide based on how a participant answers an earlier question in the same form. For example: show a "Club name" text field only when a participant selects "Yes" in a "Are you a club member?" dropdown, or show an emergency contact section only when a specific race distance is chosen.
Conditions can check for an exact value match, or combine multiple conditions with AND / OR logic. When a field's condition is not met, the field is hidden and its answer is not required.
Setting up conditional fields requires help from your account manager. Contact
them with the logic you need and they will configure it for you.
## Waivers
Waivers are a special booking form field type that present a legal agreement participants must acknowledge before completing checkout. See [Waivers](./waivers) for a full guide to setting them up, signature options, and what participants see.
## Sales options
On the **Details** tab, scroll to **Sales options** for event-level controls:
* **Enable Payment Plans** — turns on the monthly installment option for the event. Configure the maximum number of payments and the last possible payment date (see [Payment Plans](../event-setup/payment-plans)).
* **Enable Bulk Buy discounts** — lets you offer price reductions when participants buy multiple tickets at once (see [Bulk Buy Discounts](../event-setup/bulk-buy-discount)).
* **Undiscoverable (Unlisted)** — hides the event from search and browse on Let's Do This. Keep this on while you're setting up.
## Previewing and going live
Once your setup is complete, click the **Preview** link at the top of the event dashboard to see exactly what participants will see — the full event page with your content, images, and ticket selector — before the event is visible to anyone.
When you're happy with everything, contact your account manager to list the event publicly and open registrations.
# Image specifications
Source: https://partner-help.letsdothis.com/docs/creating-managing-events/image-specs
Recommended sizes, formats, and safe-zone guidance for every image you can upload to your event.
The platform uses a single image for both mobile and desktop. The image is
cropped depending on the viewer's screen size — keep key content (text, logos,
faces) centered and well clear of the edges.
Before uploading images for your event, share these specifications with whoever is producing the assets. Getting the dimensions and safe zones right avoids cropping surprises and display issues across devices.
## File requirements
These limits apply to all images on the platform, unless a specific section below notes otherwise.
| Setting | Value |
| - | - |
| Max file size | 3 MB (2 MB for Campaign Emails) |
| Accepted formats | JPEG, PNG, WebP, GIF |
## Event hero image
The hero image appears at the top of your event's public page and in booking confirmation emails.
| Setting | Value |
| - | - |
| Recommended size | 1500 × 1000 px |
| Aspect ratio | 3:2 |
The image is cropped differently across screen sizes. Keep your key subjects and any text centered — anything near the edges may be cut off on some devices.
## Event logo
The event logo appears on your event page alongside the event name.
| Setting | Value |
| - | - |
| Recommended size | 250 × 250 px |
| Aspect ratio | 1:1 (square) |
## Organizer logo
Your organization's logo is configured during account setup and appears on event pages and throughout the registration flow.
| Setting | Value |
| - | - |
| Recommended size | 200 × 200 px |
| Aspect ratio | 1:1 (square) |
The platform validates the aspect ratio on upload. Images that are significantly off-square may appear letterboxed.
## Bundle image
The bundle image appears on upsell cards shown to participants during checkout.
| Setting | Value |
| - | - |
| Recommended size | 1400 × 785 px |
| Safe zone (always visible) | Central 1400 × 415 px |
One image is used across mobile and desktop. Content outside the central 1400 × 415 px area may be cropped on smaller screens. Keep all text, logos, and key visuals within that central strip.
## Add-on product image
Add-on (merch) product photos appear as thumbnails on the Add-ons step in checkout, and in a larger view when a participant opens a product for more detail.
| Setting | Value |
| - | - |
| Recommended size | 500 × 500 px (minimum) |
| Aspect ratio | Square (1:1) |
The thumbnail list crops to a wider box, while the full-size product view crops to a square — keep your subject and any text centered with margin on all sides so nothing important is cut off in either view. The platform automatically compresses and optimizes the image for web display, so you don't need to resize or convert the file yourself before uploading.
## Campaign emails
Images used in the **Advanced Email Builder** for marketing campaigns have their own size guidance and a lower file-size limit.
Around 70% of emails are opened on mobile. Stack images vertically rather than
side by side, and avoid placing important text inside images — use live text
wherever possible so it stays readable at any size.
| Element | Recommended width | Notes |
| - | - | - |
| Header image | 600 px wide | Keep height proportional — a banner 150–250 px tall works well for most headers. |
| Footer image | 600–680 px wide, 50–100 px tall | Enough space for a logo and legal info without dominating the email. |
| General content images | 600 px wide | For multi-column layouts, divide accordingly — for example, 300 px per column in a 2-col layout. |
| Max file size | 2 MB | Larger files increase load time and may affect deliverability. |
| Accepted formats | JPEG, PNG, GIF | |
## Tips for getting images right
* **Keep text and logos away from the edges.** Images crop differently on different screen sizes — anything important should sit well inside the center.
* **Use PNG for graphics that contain text or logos** (sharper edges at any size). Use JPEG for photographs.
* **Compress before uploading.** Export at 72 dpi for web use and compress the file to stay under the size limit.
* **Check the aspect ratio before uploading.** An off-ratio image will trigger a warning in the dashboard and may appear letterboxed.
* **In emails, prefer live text over text in images.** Baked-in text can be too small to read on mobile and is not picked up by screen readers or spam filters.
# Repeating events
Source: https://partner-help.letsdothis.com/docs/creating-managing-events/repeating-events
Add multiple future dates and times to an event so participants can register for the instance that suits them.
Repeating events let you offer the same event across multiple dates — for example, a monthly trail run or a weekly parkour session — without rebuilding your setup from scratch each time. You create one fully configured event, then use the **Repeat** feature to generate additional instances from it. Each instance is a separate event occurrence that participants can book independently.
We recommend completing your event setup — races, tickets, registration forms, descriptions — before adding repeat dates. The more complete your template, the less you'll need to edit each new instance individually.
## Adding repeat dates
From your organizer dashboard, find your event and click the **⋯** menu on the event card. Select **Repeat event**.
You can also open this from within the event dashboard — look for the **Add repeat dates/times** link.
The modal shows your template event on the left. On the right, use the **Date** and **Time** fields to add each new occurrence:
1. Enter a date and time.
2. Click **Add**.
3. Repeat for each date you want to add.
Dates are shown in your event's configured timezone. You cannot add the same date and time twice — the **Add** button is disabled for duplicate entries.
Remove a date from the list by clicking the **×** next to it before confirming.
Review the list of dates you're adding, then click **Confirm**. The new instances are created immediately.
## Repeated event behavior
Each new instance starts as **unlisted** — not visible to the public on Let's Do This or in search engines. This gives you time to review and adjust each occurrence before it goes live. When you're ready to open registrations for a date, contact your account manager to list it.
A success message confirms the dates that were created, and reminds you that they are unlisted until you publish them.
## Managing instances
To see all dates for a repeating event, open the event dashboard and click **All dates/times**. This opens a full-screen view listing every occurrence — past and upcoming.
Each occurrence card shows:
* The date, time, and timezone.
* Whether the instance is **Listed** (publicly visible) or **Unlisted**.
* A **Past** label for dates that have already happened (shown at reduced opacity).
From the **⋯** menu on each card you can:
* **Edit event** — open that occurrence's setup to adjust dates, descriptions, tickets, or any other settings.
* **View** (if listed) — open the public event page for that occurrence.
* **Preview** (if unlisted) — open a private preview link.
* **Repeat event** — add further dates using this occurrence as the template.
You can filter the list to show or hide past events, unlisted events, and non-bookable events.
## Editing individual instances
Each occurrence is independent after creation — changes you make to one instance do not affect the others. To edit a specific date, open **All dates/times**, find the occurrence, and click **Edit event** from its menu.
# Supporting multiple languages
Source: https://partner-help.letsdothis.com/docs/creating-managing-events/supporting-multiple-languages
Let participants register in their own language, and add your own translations of your event content.
Let's Do This is available in multiple languages. Participants see the platform — including your event page, the checkout, and their confirmation emails — in their own language automatically, without you setting anything up. On top of that, you can add your own translations of the content you write (your event title, ticket names, and booking form questions) so those appear in a participant's language too.
There is nothing to switch on. Language support works for every event. The two things worth understanding are how a participant's language gets chosen, and how to translate the specific text you've written yourself.
Language is decided per participant, not per event. There is no single
"default language" you set for an event — each participant sees the platform
in the language they have chosen or that their browser requests.
## Languages we support
The platform interface — buttons, form labels, dates, validation messages, and the checkout flow — is translated into the following languages:
| Language |
| - |
| English (UK) |
| English (US) |
| English (Australia) |
| French (France) |
| French (Canada) |
| German |
| Spanish |
| Italian |
| Portuguese (Portugal) |
| Welsh |
| Japanese |
| Polish |
## Participant language selection
You don't choose a language for your participants — each participant gets one of two ways to land on the right one:
* **Automatic detection.** When someone opens your event page or checkout, the platform reads the language preference their browser sends and matches it to a supported language. If there's no match, it falls back to English (UK).
* **Manual selection.** A participant can change their language at any time using the region and language selector in the page footer. The option is titled **Change your Region or Language** and lets them pick from the supported languages. Their choice is remembered as they move through the site, including checkout.
The language a participant is viewing in when they complete checkout is also used for their confirmation and other booking emails when that email translation exists. Polish booking emails currently fall back to English (UK).
## Translating your event content
The interface is translated for you, but the text you write yourself — your event title, ticket names, and booking form questions — is not translated automatically. To have that text appear in a participant's language, add your own translation of it.
Fields that support translation include:
* Your **event title**
* Your **ticket titles**
* **Booking form field** names, descriptions, and placeholder text, along with any custom section headings on your forms
On the event setup screen, go to the field — for example a ticket title or a
booking form question — and find its language option.
Select the language you want to add a version for from the list of supported
languages.
Type the version of the text for that language. Participants viewing in that
language will see your translation; everyone else continues to see the text
you originally wrote.
You only need to add translations for the languages you want to support directly. Any language you don't add a translation for falls back to the original text you wrote.
## Participant language experience
Once a participant has a language set — by detection or by choosing one — that language is applied across their whole experience:
* **Your event page** — the interface, plus any title and content you've translated.
* **The checkout** — form labels, instructions, validation messages, and dates, all formatted for their language. Your translated ticket names and booking form questions appear here too.
* **Booking emails** — confirmation emails and other booking-related emails (such as waitlist acceptances) are sent in the language the participant used at checkout, with dates formatted to match. Note that email translations are available for all supported languages except Polish — Polish participants will receive booking emails in English (UK).
## Content requiring manual translation
The platform interface is translated for you, but **free-text content you write is only translated where you provide the translation yourself.** If you haven't added a translation for a particular field in a particular language, participants viewing in that language see the original text you wrote.
There is also **no event-level language setting.** You can't force an event to always display in one language, and you can't set a default language that overrides each participant's own choice. Language always follows the individual participant.
If a participant tells you the site or their confirmation email came through in the wrong language, ask them to open the **Change your Region or Language** option in the footer and select the language they want — their choice is remembered from that point on.
# Waivers
Source: https://partner-help.letsdothis.com/docs/creating-managing-events/waivers
Collect legally binding waiver agreements from participants at the point of registration.
Waivers let you present a legal agreement to participants during checkout and
require them to accept it before completing their registration.
Use a waiver when you need a participant's written acknowledgment of risk,
rules, or terms specific to your event — for example, a race safety disclaimer
or a photography consent form. Waivers are particularly well-suited when you
also want a dated record of acceptance, an optional electronic signature, or
age-appropriate consent handling for minors. If you only need participants to
accept your standard terms and conditions, a checkbox field is usually
sufficient.
Waivers are booking form fields. You create a waiver field once, then attach
it to any booking form. Because each ticket uses a booking form, you can
present a different waiver on different ticket types.
## Creating a waiver field
Waiver fields are created on the **Form Fields** tab in your event setup, the
same place you create other custom fields. Click **Add Form Field**, set the
field's type to **Waiver**, and you'll be asked to provide:
* **Title** — the name shown above the waiver content during checkout (for
example, `Terms and Conditions Waiver`). This also appears as the label on
the agreement checkbox.
* **Content** — the text of the waiver. HTML formatting is supported.
* **Signature requirement** — whether to collect an electronic signature
(see [Electronic signature](#electronic-signature)).
* **Filter registration options by age** — whether to narrow the signing
options based on the participant's date of birth (see
[Age-based filtering](#age-based-filtering)).
Once the field is created, attach it to a booking form on the **Forms** tab.
The waiver then appears at checkout for every ticket that uses that form.
Waiver fields are always required — participants must complete the waiver
before they can proceed through checkout.
## Registration options
When a participant reaches the waiver during checkout, they first select who
they are registering for. There are three options:
* **Myself** — the purchaser is also the participant.
* **Someone else** — the purchaser is registering another adult.
* **A minor or someone I'm legal guardian of** — the purchaser is a parent or
legal guardian registering a minor.
What the participant is asked to do next depends on which option they choose.
### Registering for myself
The participant reads the waiver content, enters today's date in the date
field, and checks the agreement checkbox. If electronic signature collection
is enabled, they also type their full name in the signature field.
The date must be today's date. Entering any other date — including a past or
future date — produces an **Incorrect date** error.
### Registering for a minor
When registering a minor, the purchaser is acting as the participant's legal
guardian. Two checkboxes are shown:
1. **I confirm I am the parent/legal guardian** — confirms the purchaser has
the authority to sign on the participant's behalf.
2. The waiver agreement checkbox — the same agreement the participant would
sign for themselves.
A date field is also shown and must be completed with today's date.
If electronic signature collection is enabled, a signature field appears as
well (see [Electronic signature](#electronic-signature)).
### Registering for someone else
When the purchaser selects **Someone else**, the waiver content is shown along
with an important information notice. No date, signature, or agreement
checkbox is presented to the purchaser — the booking can be completed without
the purchaser signing.
This reflects the fact that the adult participant needs to accept the waiver
themselves. If your event requires every participant to have personally signed
the waiver before race day, follow up with participants directly or use a
separate post-registration process to collect their agreement.
## Electronic signature
In addition to the agreement checkbox, you can require or offer an electronic
signature — a full-name text field that participants type into as a formal
confirmation.
There are three settings:
| Setting | What the participant sees |
| - | - |
| **Hidden** (default) | No signature field. Acceptance is recorded via the date and checkbox only. |
| **Optional** | A signature field is shown. Participants may fill it in, but leaving it blank does not block checkout. |
| **Required** | The signature field must be filled in before checkout can continue. Leaving it blank shows the error: **Please enter your full name to sign the waiver**. |
The signature field is shown for **Myself** and **minor** registrations. It is
never shown when the purchaser selects **Someone else**, regardless of the
signature setting.
Use **Required** when you need a clear record that the individual (or their
guardian) personally acknowledged the waiver — for example, when your insurer
or governing body expects a named signature on file.
## Age-based filtering
When **Filter registration options by age** is turned on, the registration
options shown to the participant narrow automatically based on the date of
birth they entered earlier in checkout.
* If the participant will be **under 18 on the race date**, only the
**A minor or someone I'm legal guardian of** option is shown.
* If the participant will be **18 or over on the race date**, only **Myself**
and **Someone else** are shown.
* If no date of birth has been entered yet, all three options remain visible
until one is provided.
If a participant updates their date of birth and their previously chosen option
is no longer valid — for example, they entered an adult DOB after selecting the
minor option — that selection is automatically cleared and they'll need to
choose again.
Use this setting when your event has a minimum age and you want to ensure that
anyone under that age is registered via a guardian rather than on their own
behalf.
## Participant checkout experience
The waiver section appears on the participant details page during checkout.
It shows:
1. A scrollable box containing your waiver content.
2. A **Read the full waiver** link that opens the complete waiver in a new tab.
3. The **I'm registering for** question with the relevant radio options.
4. The date field, guardian checkbox, agreement checkbox, and signature field
— depending on the option selected and your signature setting.
The section is labeled with your waiver's title. If you have not set a custom
title, a default label is used.
If a participant tries to advance to the next step without completing the
waiver, they see a **This field is required** message (if no option was
selected) or a **Waiver agreement required** message (if an option was chosen
but the checkbox was not ticked).
## Editing a waiver after booking
Participants who need to re-submit their waiver after completing their booking
can do so from their manage-booking page. An **Edit waivers** option appears
there when the booking includes at least one waiver field.
Selecting it opens a focused view of the waiver fields only, separate from
the rest of the booking form.
If a participant already signed the waiver when they booked, the agreement
checkbox and signature field are shown as locked — the previous acceptance is
preserved and cannot be overwritten. The date field is not shown for an
already-signed waiver.
## Downloading waiver PDFs
For any participant in your startlist, you can generate a PDF record of their
waiver acceptance. This is useful if you need to share a signed copy with a
venue, insurer, or governing body.
The PDF download is available from the participant's entry in your event's
startlist. You need organizer write access to your event to generate PDFs.
## Validation error meanings
This section covers the errors participants may see and what causes them, so
you can answer their questions confidently.
### "This field is required"
Shown when the participant tries to move to the next step without selecting a
registration option (**Myself**, **Someone else**, or **A minor…**). They need
to choose an option before proceeding.
### "Waiver agreement required"
Shown when the participant selected a registration option but did not tick the
agreement checkbox. This applies to the **Myself** and **minor** paths — both
require the checkbox to be checked.
### "Incorrect date"
Shown when the participant enters a date in the date field that is not today's
date. The field only accepts today's date. Common causes: the participant
entered their date of birth by mistake, or they copied a date from somewhere
else. Ask them to re-enter today's date in the format shown in the field
placeholder (this matches their locale — for example, DD/MM/YYYY for UK
participants and MM/DD/YYYY for US participants).
### "Please enter your full name to sign the waiver"
Shown when the signature field is set to **Required** and the participant
leaves it blank. They need to type their full legal name into the signature
field before the form can be submitted.
# Audiences
Source: https://partner-help.letsdothis.com/docs/email-communications/audiences
Understand how marketing and transactional audiences differ, and how to target the right participants.
Every email campaign needs an audience — the group of people who will receive it. Marketing and transactional campaigns pull from different pools of data, and each supports different ways of narrowing that pool to the right recipients.
## Marketing audiences vs. transactional audiences
**Marketing campaigns** draw from your full customer database: everyone who has registered for any of your events. However, only participants who have actively opted in to receive marketing emails from you are eligible to receive a marketing campaign. The dashboard shows your opted-in subscriber count on the marketing campaigns list — this is your reachable marketing audience, and it may be significantly smaller than your total participant count.
**Transactional campaigns** draw from the participant startlist for a specific event. Because transactional emails relate directly to an event the participant is registered for — not to marketing or promotions — they are sent regardless of the participant's marketing email preference. The audience pool for a transactional campaign is everyone registered for that event.
## Configuring the audience for a campaign
The Audience step of the campaign wizard is where you decide which participants within the eligible pool actually receive the email. You have two options:
### Full eligible pool
Leave the audience empty to send to all eligible recipients — your entire opted-in subscriber base for a marketing campaign, or all event participants for a transactional campaign. The Launch step will show the estimated recipient count before you confirm.
Sending to your full audience means everyone in the pool receives the email.
If that is wider than you intend, apply a segment or filter before sending.
### Imported segments
If you have a pre-built audience list — for example, a list of participants from a previous year, or a list you imported from an external source — select **Imported** and choose the segment from the dropdown.
Imported segments are managed under **Audience management** in the CRM section of your dashboard. You can upload a list there, and it becomes available to select on the Audience step of any campaign.
By uploading a list and using it as a campaign audience, you confirm that you
have the right to contact every person on that list. Ensure the people on your
list have given appropriate consent to receive email from you before
importing.
You can also configure **exclusions** alongside an imported segment — a second list of participants to remove from the import before sending. This is useful for removing participants who have already received a certain communication or who should not receive this particular email.
### Filters
Select **Filters** to narrow the audience using criteria based on participant data. You can add multiple filter conditions and combine them with AND / OR logic to target a specific subset.
Typical filter criteria include:
* **Event or occurrence** — limit to participants of a specific event or a specific occurrence of a repeating event.
* **Location** — filter by country, region, or locale.
* **Membership status** — target members or non-members of an affiliated club or federation.
After applying filters, the Audience step shows an estimated count of how many participants match. This is an estimate — the exact send count is calculated at the moment the campaign is dispatched.
## Participant email experience
A participant's experience depends on the campaign type:
* **Marketing email**: they receive it only if they have opted in. An unsubscribe link in the footer lets them opt out at any time.
* **Transactional email**: they receive it as a registered participant of the event. Transactional emails do not include an unsubscribe link — participants cannot opt out of them through the email itself.
If a participant asks why they received (or did not receive) an email, check their marketing preferences on their profile in the **Customers** section of your dashboard. For transactional emails, confirm they are active on the event's participant list.
# Branding & Custom Domains
Source: https://partner-help.letsdothis.com/docs/email-communications/branding
Apply your visual identity to emails with brand themes, and configure a custom sending domain.
Branding controls how your emails look and where they appear to come from. There are two parts: **brand themes**, which apply your visual identity to the email layout, and **send configuration**, where you can set a custom from address so emails appear to come from your own domain.
## Brand themes
A brand theme is a set of visual settings — primarily colors — that are applied to the structural elements of an email layout: the header, buttons, background, and similar areas. Applying a theme means your emails look like they come from your brand rather than a generic template.
### Creating a theme
In your dashboard, go to **Settings → Branding**. The Branding page lists all themes you have created, with the most recently updated at the top.
Click **Create new theme**. The theme editor opens.
Enter a name for the theme and configure the color settings. Your organizer logo is used in the preview so you can see how the email will look with your branding applied.
Click **Save**. The theme is now available to select when composing a campaign.
### Editing a theme
On the Branding settings page, click a theme card to open it in the editor. Make your changes and click **Save changes**. Updates apply to future sends — emails already sent are not affected.
### Applying a theme to a campaign
When you create or edit a campaign, the **Overview** step includes a **Select brand theme** dropdown. Choose the theme you want to apply. The theme affects how the email's layout elements are rendered — it does not change the content you write in the Builder step.
You can switch themes up until the campaign is sent. If you make changes to the theme after selecting it, the campaign picks up the updated version at send time.
## Send configuration: from email and custom domains
By default, emails from your campaigns are sent from a Let's Do This address. For a more professional appearance, you can configure campaigns to send from your own domain.
### Custom sending domains
To use a custom from email address, your account needs at least one verified sending domain. You set this up yourself in **Settings → Branding → Custom Domains** by adding your domain and adding two records at your DNS provider. See [Custom Domains](/docs/email-communications/custom-domains) for the full process.
Once a domain is verified, the **Use a custom from email** option on the campaign Overview step becomes active.
### Configuring the from address on a campaign
On the campaign Overview step, check **Use a custom from email**. If the checkbox is greyed out, your account does not yet have a verified sending domain — add one in [Custom Domains](/docs/email-communications/custom-domains) first.
In the field on the left, type the part of the email address before the @. For example, to send from `events@yourdomain.com`, type `events`.
Choose from the dropdown on the right. It lists the verified domains on your account. Select the domain you want to send from.
The full from address — local part plus domain — is validated before you can proceed. If the address is invalid, an error message tells you what to correct.
### Reply-to address
The **Reply-to name** and **Reply-to email** fields control where participant replies are directed. Set these so that when a participant replies to your email, the message comes to you — not to a Let's Do This inbox.
The reply-to address must be on a verified sending domain, the same as the from address. You set it the same way too: type the part before the @, then choose a verified domain from the dropdown. If you have no verified domain, this option is disabled — see [Custom Domains](/docs/email-communications/custom-domains).
The from and reply-to addresses are independent, so you can send from one address and have replies go to another.
# Custom Domains
Source: https://partner-help.letsdothis.com/docs/email-communications/custom-domains
Verify your own domain so campaign and transactional emails are sent from your address instead of a Let's Do This one.
You need write access to your organizer account to reach **Settings → Branding
→ Custom Domains**, and access to your domain's DNS provider to complete
verification. If you do not manage your own DNS, you can copy the records and
send them to whoever does — see [Sharing records with your DNS
administrator](#sharing-records-with-your-dns-administrator).
By default, your campaign and transactional emails are sent from a Let's Do This address. Verifying a custom domain lets you send from your own address instead, such as `events@yourdomain.com`. Participants recognize your address, so they are more likely to open the email and less likely to treat it as spam.
Verify a domain well before you plan to send. DNS changes can take up to 48 hours to take effect. You only need to do it once per domain: after that, the domain stays available for every campaign and transactional email you build.
Verification covers both the **from address** and the **reply-to address**. Both are set the same way: you type the part before the @ and choose a verified domain from a dropdown, so neither can point at a domain you have not verified. Until you have at least one verified domain, both options stay disabled and your emails send from — and receive replies at — a Let's Do This address.
Setup adds two records to your domain: a DKIM record and a Return-Path record. Neither is an MX record, so verifying a domain here does not change where email sent *to* your domain is delivered. Your existing inboxes keep working exactly as they do today.
## Adding and verifying a domain
In your dashboard, go to **Settings → Branding → Custom Domains**. The page lists every domain you have added. If you have not added one yet, it shows **No domains added yet.**
Click **Add domain** and enter the domain you want to send from, such as `example.com`.
You can paste a full email address or a website address instead — `events@example.com` or `https://www.example.com` both reduce to `example.com`. If what you enter is not a valid domain, you see **Please enter a valid domain.** and the button stays disabled.
Click **Add domain** again to save it. The domain field locks, the status shows **Pending verification**, and the **DNS records** section appears with the records you need to add.
Add the DKIM and Return-Path records exactly as shown. Each one gives you a **Host** and a **Value** you can copy directly.
Leave this page open — you can come back to it at any time from the domain's **Continue setup** button.
Once the records are in place, click **Refresh status**. When both records come back verified, the window closes and confirms that the domain can now be used for sending.
If the records have not propagated yet, the statuses stay as **Pending**. Wait and refresh again — there is no limit on how many times you can check.
## Required DNS records
| Record | Type | Example host | What it does |
| - | - | - | - |
| **DKIM** | `TXT` | `pm._domainkey.example.com` | Signs your outgoing email so mailbox providers can confirm it genuinely came from you, not from a spoofer. |
| **Return-Path** | `CNAME` | `pm-bounces.example.com` | Handles bounce reporting, which protects your sender reputation and helps your email reach the inbox. |
Copy the **Host** and **Value** exactly as shown. Some DNS providers append your domain to the host automatically — if yours does, enter the host without the `.example.com` suffix, so `pm._domainkey` rather than `pm._domainkey.example.com`. Adding the suffix twice is the most common reason a record never verifies.
## Sharing records with your DNS administrator
Rather than retyping the values or screenshotting the page, click **Copy all instructions** at the bottom of the DNS records section. This copies a plain-text version of everything — both records with their host, value, and current status, plus notes on the host suffix and how long DNS changes take — ready to paste into an email or a support ticket.
The copied instructions are written for whoever administers your DNS, so they make sense to someone who has never seen your dashboard. You can re-copy them at any time; the statuses update to reflect how far verification has progressed.
If your browser blocks clipboard access, you see **Could not copy the instructions**. Copy the **Host** and **Value** fields individually instead — each one has its own copy control.
## Tracking verification status
Each domain appears as a card on the Custom Domains page showing its overall status and the status of each record:
* **Verified** — both records have verified. The domain is ready to send from.
* **Pending** — one or both records are still outstanding. The card shows which, as `DKIM: Verified · Return-Path: Pending`.
Pending domains have a **Continue setup** button that reopens the records. Verified domains do not — there is nothing left to do on them.
Opening a pending domain automatically re-checks its records once, so the status you see when the window opens is current. You do not need to click **Refresh status** immediately after opening it.
## Partial verification
A domain counts as verified only when **both** the DKIM and Return-Path records have verified. If one has verified and the other has not, the domain still shows as **Pending** and cannot be selected as a from address.
This often happens when a DNS provider publishes one record faster than the other. It is not an error — keep waiting and refreshing until both records show **Verified**.
## Using a verified domain to send
Once a domain is verified, it becomes available on the **Overview** step of both campaigns and transactional emails, for two separate settings:
* **From address** — the address participants see the email came from. Type the part before the @ (such as `events`) and choose your verified domain from the dropdown.
* **Reply-to address** — where participant replies are delivered. Set the same way, and also limited to your verified domains.
You can point the two at different addresses on the same verified domain — sending from `events@yourdomain.com` while replies go to `support@yourdomain.com`, for example.
See [Branding & Custom Domains](/docs/email-communications/branding) and [Transactional emails](/docs/email-communications/transactional-emails) for where these sit in the campaign flow.
## Troubleshooting verification
DNS changes can take up to 48 hours to take effect, so give it time before assuming something is wrong. If a record is still **Pending** after that, check the following at your DNS provider:
* The **Host** and **Value** match what the dashboard shows, character for character.
* The host suffix is handled correctly for your provider — see [Required DNS records](#required-dns-records).
* The record was added to the right domain, not to a different one you also manage.
* The record type matches: DKIM is a `TXT` record, Return-Path is a `CNAME`.
If the records look correct and the domain still has not verified after 48 hours, contact LDT support with the domain name and a screenshot of the records as they appear at your DNS provider.
## Changing or removing a domain
The domain field locks as soon as you save it, so you cannot edit a domain after adding it. If you entered the wrong one, or you want to move to a different domain, add the correct one as a new domain — you can have as many as you need, and each is verified independently.
There is no option to remove a domain from this page. If you need one taken off your account, contact LDT support.
# Customer Experience email setup
Source: https://partner-help.letsdothis.com/docs/email-communications/customer-experience-email-setup
Set up an email address so participants can contact your Customer Experience agent directly.
You need edit access to your Customer Experience configuration and access to
your domain's DNS provider before you start. If you do not manage your DNS,
share this page with the person or team that does.
Use Customer Experience email when you want participants to send questions to a dedicated support address and receive replies from your Customer Experience agent. Decide which domain the agent will use before you start, because the DNS records you add affect where mail for that domain is delivered.
## Agent address domain
Setup adds an MX record to the **whole domain** of the address you enter. An
MX record decides where messages for that domain are delivered, so adding it
to a domain your team already receives mail on may send that mail to the
Customer Experience agent instead of your own inbox. Give the agent its own
subdomain.
We recommend keeping your existing help and support address as your escalation inbox and establishing a separate subdomain as the agent's email inbox, which you share as your public contact email.
| **Type** | Example Address | What it is | What changes in DNS |
| - | - | - | - |
| **Escalation Inbox** | `support@example.com` | Your existing help and support address, on your current mail provider or help desk. It stays the address you publish and the address the agent escalates to. | Nothing. Your team's inboxes on `example.com` keep working exactly as they do today. |
| **Agent Inbox** | `support@help.example.com` | A new address on a subdomain, used only by the Customer Experience agent. This is the address you enter in **Email setup**.
This is the address you publish on your website and contact us pages. | The DKIM, Return-Path, and MX records apply to `help.example.com` only, so they cannot affect your main domain mail. |
Keeping the two apart protects escalations as well as your team's day-to-day mail. If the MX record lands on `example.com`, messages sent to your escalation inbox are routed to the Customer Experience agent, so the queries the agent hands over never reach your team.
Use whichever subdomain suits you, such as `help.example.com`, `cs.example.com`, or `mail.example.com`. Pick one that no mailbox, help desk, or mail provider is already using, so no existing routing is affected.
## Sender address setup
In your dashboard, go to **Customer Experience** and open the configuration you want participants to email. In the **Install** area, find **Email setup**.
Add the **Email address** the Customer Experience agent will use, such as `support@help.example.com`.
Enter the subdomain address you chose above, not your main support address. The domain part of this address decides which DNS records you need to add and where the MX record goes.
Select **Continue to DNS**. The setup panel generates the DNS records for your sender address.
## DNS record setup
Add every record shown in the **DNS records** section at your DNS provider. The records verify that Postmark can send from your domain and route participant replies back to the Customer Experience agent.
The setup can include:
* **DKIM** - verifies outgoing email from your domain.
* **Return-Path** - improves delivery tracking and sender reputation.
* **Inbound** - the MX record that routes participant replies through Postmark.
Each record shows a **Type**, optional **Priority**, **Host**, and **Value**. Copy the values exactly as shown. DNS providers format host names differently, so use Postmark's domain verification guide from the setup panel if your DNS host asks for a shortened or full host name.
Check the **Host** on the MX record before you save it. It should name the subdomain you chose, such as `help.example.com`. If your DNS provider shortens host names, it should read `help` rather than `@` — an `@` host applies the record to your whole domain.
DNS changes can take up to 48 hours to verify. After adding the records, return to **Email setup** and select **Refresh status**. The channel is ready when **DKIM**, **Return-Path**, and **Inbound** all show as **Verified**.
## Email settings
After verification completes, open **Email settings** to manage the day-to-day sender details.
You can update:
* **From name** - the sender name participants see in their inbox.
* **Email signature** - the sign-off added to replies.
* **Enable email channel** - whether participants can email this agent.
Select **Save settings** after changing these values.
## Changing the email address later
Changing the sender address restarts DNS verification for the new domain. The email channel will not be ready for that address until the required DNS records are verified again.
Before changing the address, make sure you can update DNS for the new domain or subdomain. If participants already use the old address, plan the switch so you do not miss new messages during verification.
## Pending verification
If a status remains **Pending** after you refresh, check the record in your DNS provider:
* The **Host** and **Value** match the setup panel.
* The **Priority** is added for records that show one.
* The record was added to the correct domain or subdomain.
* Your DNS provider has had enough time to publish the change.
If the records look correct but the status still does not verify after 48 hours, contact LDT support with the sender address and a screenshot of the DNS records you added.
# Email personalization
Source: https://partner-help.letsdothis.com/docs/email-communications/email-personalisation
Insert participant-specific data into your emails using dynamic content variables.
Email personalization lets you include data about each recipient directly in the email body — for example, addressing every participant by first name, or referencing the event they registered for. Each recipient sees a version of the email tailored to them, even though you only compose it once.
Personalization is available in both marketing and transactional email campaigns. The specific variables available to you depend on the campaign type: marketing campaigns draw from your customer data, while transactional campaigns include event-specific attributes such as bib number or race category.
## Personalization variables
Variables use a double-curly-brace syntax: `{{ variable_name }}`. When the email is delivered, the platform replaces each variable with the actual value for that recipient. If no value is available for a recipient, the variable renders as blank — or as a fallback you specify.
A variable with a fallback looks like this:
```
{{ first_name | default: "there" }}
```
If a participant's first name is not recorded, the email renders "there" instead — so "Hi \{\{ first\_name | default: "there" }}" becomes "Hi Sarah" or "Hi there" depending on the data available.
## Using the snippet builder
The snippet builder is the easiest way to insert a variable without typing it by hand. It is available in the Builder step of any campaign, in both the Basic Builder and the Advanced Builder.
In the Builder step, look for the **Personalization** or **Dynamic variables** panel. In the Basic Builder this appears in a sidebar or below the section controls. In the Advanced Builder, open it from within a text block.
Choose the piece of data you want to insert from the attribute list. Available options include things like participant name, email address, event name, and registration-specific fields.
In the **Fallback** field, enter the text that should appear when the attribute has no value for a particular recipient. Providing a fallback is recommended — it prevents blank spots in your email.
The generated snippet appears in the output box. Click **Copy** to copy it to your clipboard, then paste it into the text or HTML section of your email where you want it to appear.
For conditional logic — showing or hiding content based on whether a value exists — click **Copy for logic** to get the variable identifier without the full snippet wrapper. You can then build `{% if %}` conditions around it in an HTML section.
## Validation
The platform checks your personalization syntax when you save or advance past the Builder step. If a variable name is not recognized, or the syntax is malformed, you'll see a validation warning highlighting the problem. Fix the variable before continuing to avoid delivery errors.
## Tips for reliable personalization
**Always set a fallback for names.** Not every participant's profile includes a first name. A fallback like "there" or "participant" keeps the email readable.
**Test before sending.** Use **Send Test** on the Launch step to see a rendered version of the email in your own inbox. The preview uses placeholder values; the test send uses real data.
**Check your data source.** Variables only contain values that exist in your participant records. If a field such as bib number is not filled in yet, wait until data is available before sending an email that references it.
**Keep conditions simple.** Conditional blocks (`{% if %}`) are powerful but harder to debug. If you need conditional content, test it thoroughly with the **Send Test** feature before sending to your full audience.
# Avoiding Gmail rate limits
Source: https://partner-help.letsdothis.com/docs/email-communications/gmail-rate-limits
Understand Gmail's bulk email receiving limits and how to keep your campaigns landing in inboxes.
Gmail and Google Workspace limit how many bulk emails they accept from a single sender each day. If a large share of your audience uses Gmail addresses and you send a very large campaign, Gmail may defer or reject some messages — meaning some participants never receive the email, without any obvious error on your end.
This is not a problem with the platform. It is a constraint imposed by Gmail on receiving bulk email, and it affects all bulk senders. Understanding it helps you plan campaigns that reach everyone you intend to reach.
## Gmail's bulk-receiving limits
Gmail treats high volumes of email from a single sending source as a potential spam signal. When too many emails arrive from one sender in a short window, Gmail starts deferring them — accepting some immediately, queuing others for later delivery, and in some cases silently dropping messages that look like spam.
The threshold is not published by Google and changes over time, but it is most likely to affect you when:
* Your campaign is very large (thousands of recipients).
* A high proportion of your audience uses Gmail or Google Workspace addresses.
* Your sending domain or IP reputation is not well established.
* You send infrequently, so there is no warm sending history.
## Avoiding the limit
**Send to your actual subscribers, not everyone.** Use the Audience step to target only participants who have opted in and are likely to engage. A smaller, more engaged list is treated more favourably by Gmail than a large list of cold addresses. See [Audiences](/docs/email-communications/audiences).
**Keep your list clean.** Remove addresses that have bounced, unsubscribed, or are clearly inactive before sending. High bounce rates and low engagement rates damage your sender reputation over time and make Gmail more likely to rate-limit future sends.
**Use a verified custom sending domain.** Campaigns sent from a recognised, verified domain build a sending reputation faster than shared or generic addresses. If you regularly send to a large audience, set up a custom sending domain — see [Branding](/docs/email-communications/branding).
**Send consistently, not in large irregular bursts.** Gmail is more tolerant of senders with a steady history of regular sends. If you send only once or twice a year but to a very large list, consider smaller, more frequent campaigns to build a sending pattern.
**Stagger very large campaigns.** If you need to reach tens of thousands of participants in a single campaign, consider splitting the audience into segments and sending to each over consecutive days rather than all at once.
## Undelivered emails
If a participant reports not receiving an email, ask them to:
1. Check their Spam or Junk folder — Gmail sometimes misroutes bulk email there.
2. Check their Promotions tab if they use Gmail's tabbed inbox.
3. Look for an email from `hello@letsdothis.com` (or your custom from address if set up) and add it to their contacts, which helps future delivery.
If multiple participants report the same issue after a large send, it is likely that Gmail rate-limited part of the campaign. Deferred emails are typically retried and delivered within a few hours. If messages were rejected outright, they will not be retried — contact Let's Do This support and we can investigate the delivery logs.
## Ongoing list hygiene
The best long-term protection against Gmail limits is a healthy, engaged list:
* Remove hard bounces promptly — addresses that permanently fail are a signal to Gmail that your list is not well maintained.
* Watch your unsubscribe rate. A spike after a campaign suggests the content did not match participant expectations.
* Do not import old, unverified lists. Addresses that have not engaged in years are likely to bounce or be flagged as spam traps.
# Marketing emails
Source: https://partner-help.letsdothis.com/docs/email-communications/marketing-emails
Create and send promotional email campaigns to your participants across all your events.
Marketing emails are campaigns you send to your broader audience — people who have registered for one or more of your events and opted in to receive marketing communications from you. Use them for announcements, newsletters, race series updates, early-bird offers, and anything that is not specific to a single event.
Unlike transactional emails, marketing emails are only delivered to participants who have given their marketing consent. Always keep this in mind when estimating reach: your total participant count will be higher than your reachable marketing audience.
## The campaigns dashboard
Your marketing email campaigns live under **Email campaigns → Marketing** in your dashboard. The list shows every campaign you have created, along with its current status, subject line, and (once sent) headline performance figures.
Use the search bar to find a campaign by name. The status tabs — **All**, **Draft**, **Scheduled**, **Sent**, and **Error** — let you filter to what you need.
Each campaign card has a menu (the three-dot icon) where you can edit, duplicate, or archive the campaign.
## Creating a campaign
Marketing campaigns follow a five-step wizard. You can save a draft at any step and return later.
Click **Create** on the marketing campaigns list to open the campaign wizard.
On the **Overview** step, fill in:
* **Campaign name** — internal label only; participants never see this.
* **Subject** — the subject line participants see in their inbox.
* **Preheader** — the short preview text shown after the subject in most email clients. A good preheader adds context and improves open rates.
* **From name** — how your name appears in the sender field. Defaults to your organizer name.
* **From email** — if your account has a custom sending domain set up, enable **Use a custom from email** and enter the address. Otherwise emails send from Let's Do This by default. Contact your account manager to configure a custom sending domain.
* **Reply-to name** and **Reply-to email** — where replies from participants are directed. Set these to your own contact details.
* **Brand theme** — pick a theme to apply your visual branding to the email. See [Branding](/docs/email-communications/branding).
On the **Builder** step, compose your email body. When you first open it, choose your editing experience:
**Basic Builder** — add content blocks in sequence:
| Block | Use for |
| - | - |
| Heading | Section titles or the main heading of the email |
| Text | Body copy, paragraphs, and prose |
| Button | A call-to-action with a label and link URL |
| Image | A photo, banner, or illustration |
| HTML | Custom HTML for layouts the block builder cannot produce |
Drag blocks to reorder them.
**Advanced Builder** — a full drag-and-drop visual editor. Build multi-column layouts, customize spacing, and create more complex email designs with greater visual control.
Both builders support **personalization variables** so each recipient sees their own data — for example, addressing each recipient by first name. See [Email personalization](/docs/email-communications/email-personalisation) for full detail.
Click **Preview** to see how the finished email will look before you continue. Click **Save Draft** to save without advancing.
On the **Audience** step, decide who receives this campaign.
Your total opted-in subscriber count is shown at the top of the step — this is the maximum reach for any marketing campaign you send.
You can narrow the audience further using an imported segment or a filter. Leave the audience empty to send to all your marketing subscribers. See [Audiences](/docs/email-communications/audiences) for all options.
Choose how the campaign is sent:
* **Send now** — delivers immediately after you confirm on the final step.
* **Schedule** — pick a specific date and time for delivery.
* **Triggered** — the email sends automatically when a participant action occurs. See [Triggered sends](#triggered-sends) below.
If you return to edit a campaign that is already scheduled, you'll see a notice. To change the delivery type (for example, from scheduled to send now), cancel the scheduled campaign first — this returns it to drafts — then re-set the delivery option.
The **Launch** step shows a read-only summary of your campaign settings alongside the expected recipient count for your chosen audience.
You can still update the campaign name, subject, preheader, from address, reply-to, and brand theme from this step before sending.
* **Send Test** — sends the email to yourself so you can check formatting and content in a real inbox.
* **Save Draft** — saves your changes without sending.
* **Send** (or **Schedule**) — confirms and delivers or queues the campaign.
A confirmation prompt summarises who the email will go to and when. Confirm to complete the send.
## Triggered sends
A triggered campaign sends automatically when a participant action occurs — without you needing to schedule or manually press send each time. Use triggered sends for welcome emails, follow-ups, or time-sensitive messages that should go out relative to a specific moment for each individual participant.
When creating a campaign, select **Triggered** as the send type. On the Triggers step, configure:
**Trigger type** — the participant action that starts the send:
| Trigger | What activates it |
| - | - |
| Participant Registered | A participant completes registration for the event |
| Participant Checked-In | A participant is checked in at the event |
| Membership Created | A participant's membership is created |
**Timing** — send immediately when the trigger fires, or after a delay you specify in hours, days, weeks, or months.
Only participants who have opted in to marketing emails from you will receive
a triggered marketing campaign, even if they meet the trigger condition. To
send to all participants of an event regardless of marketing preferences, use
a transactional campaign instead.
## Duplicating a campaign
To reuse a campaign — for example, a seasonal announcement you send every year — open its card menu and select **Duplicate**. The copy starts as a draft with all settings and content copied. Update what you need, then send as normal.
## Archiving a campaign
To keep your list tidy, archive campaigns you no longer need. Archived campaigns do not appear in the default list view. Open the card menu and select **Archive** to archive, or filter by status to find and restore archived campaigns.
## Marketing email unsubscribes
Every marketing email includes an unsubscribe link. When a participant clicks it, they opt out of future marketing emails from you. Their preference is stored and respected on all subsequent campaigns — they will not receive marketing emails until they opt back in.
You can see a participant's marketing email preference on their profile in the Customers section of your dashboard.
## Campaign errors
If a send fails, the campaign card shows an error status. Open the card to see details. Common causes:
* **Missing required fields** — the subject line or email body is blank.
* **Custom from email not authorised** — the from address is not on an approved sending domain. Contact your account manager.
* **Audience issue** — the selected segment returned no valid recipients.
Correct the issue and resend. If the error persists, contact Let's Do This support with the campaign name and error detail.
# Transactional emails
Source: https://partner-help.letsdothis.com/docs/email-communications/transactional-emails
Create and send event-specific emails to participants of a particular event.
Transactional emails are event-scoped messages about a specific event — race-day logistics, kit collection details, pre-event briefings, and anything else that only makes sense in the context of a participant's registration.
There are two types of transactional email:
* **Automatic emails** — sent by Let's Do This on your behalf when a booking event occurs. You do not need to create or schedule these.
* **Campaigns** — emails you compose and send yourself, either on a schedule you set or triggered automatically when a participant action occurs.
## Emails Let's Do This sends automatically
Let's Do This sends the following emails automatically on your behalf. These use LDT-managed templates and do not require any action from you.
| Email | When it sends |
| - | - |
| Booking confirmation | Immediately after a participant completes their registration |
| Booking receipt | After payment is processed |
| Abandoned cart | Up to three reminders, 1 hour, 1 day, and 3 days after a participant starts checkout without completing it |
| Entry withdrawn | When a booking is cancelled |
| Upcoming payment reminder | Before a payment plan instalment is due |
These emails are sent from a Let's Do This address, and their content cannot be edited. If you have questions about their content or need to report a delivery issue, contact Let's Do This support.
The abandoned cart reminders are the one exception: you can turn them off for an event and send your own instead. See [Replacing the Let's Do This abandoned cart emails](#replacing-the-lets-do-this-abandoned-cart-emails).
## Finding your campaigns
Organiser-created campaigns live in your dashboard under **Email campaigns**. Select the **Transactional** tab to see campaigns for all your events, or open a specific event and navigate to its email section to see only that event's campaigns.
Each campaign card shows its current status:
| Status | What it means |
| - | - |
| Draft | Saved but not yet sent or scheduled |
| Scheduled | Set to send at a future date and time |
| Sending | Currently delivering to recipients |
| Sent | Delivered successfully |
| Error | Something went wrong — check the card for details |
## Creating a transactional email campaign
On the transactional emails list, click **Create**. If prompted, confirm you want to create a campaign for a specific event, then click **Apply**.
The wizard opens at the **Overview** step.
On the Overview step, complete the send configuration:
* **Campaign name** — an internal label, not visible to participants.
* **Subject** — the subject line participants see in their inbox.
* **Preheader** — the short preview text that appears after the subject in most email clients. Use it to complement the subject line.
* **From name** — the display name in the sender field. Defaults to your organizer name if left blank.
* **From email** — enable **Use a custom from email** if your account has a verified sending domain; otherwise the email comes from Let's Do This by default. See [Custom Domains](/docs/email-communications/custom-domains) to set one up.
* **Reply-to name** and **Reply-to email** — where replies are directed, so participants can reach you directly. Like the from address, the reply-to address must be on a verified sending domain; see [Custom Domains](/docs/email-communications/custom-domains).
* **Brand theme** — select a theme to apply your branding to the email layout. See [Branding & Custom Domains](/docs/email-communications/branding) for how to set up themes.
Click **Save Draft** to preserve your settings, or **Save and continue** to move to the next step.
The Builder step is where you compose the email body. When you first open it, choose your editing experience:
**Basic Builder** — add content blocks in sequence. Available block types:
| Block | Use for |
| - | - |
| Heading | A large title at the top of a section |
| Text | Body copy and paragraphs |
| Button | A call-to-action with a label and URL |
| Image | A photo, banner, or illustration |
| HTML | Custom HTML for layouts the block builder cannot produce |
Drag blocks to reorder them.
**Advanced Builder** — a full drag-and-drop visual editor. Build multi-column layouts, customize spacing, and design more complex email templates with greater visual control.
Both builders support personalization variables so each recipient sees their own data — for example, their first name or the event they registered for. See [Email personalization](/docs/email-communications/email-personalisation).
Click **Preview** to see how the email will look before continuing.
On the Audience step, choose which participants receive this email. You can target the entire event participant list or narrow it down by imported segment or filter criteria. See [Audiences](/docs/email-communications/audiences) for detail on each option.
Choose how the campaign is sent:
* **Send now** — delivers immediately after you confirm on the Launch step.
* **Schedule** — pick a specific date and time.
* **Triggered** — the email sends automatically when a participant action occurs. See [Triggered sends](#triggered-sends) below.
If you are editing a campaign that is already scheduled, you'll see a warning. To change the delivery type you must cancel the campaign first, which returns it to drafts.
The Launch step shows a summary of your send configuration and the estimated recipient count. You can still edit any field before sending.
Click **Send Test** to send a preview to yourself. When you are happy, click **Send** (or **Schedule**) and confirm.
## Triggered sends
A triggered campaign sends automatically when a participant action occurs — without you needing to schedule or manually press send each time. Use triggered sends for follow-up messages, welcome emails, or reminders that should go out relative to a specific moment for each individual participant.
On the Schedule step, select **Triggered** to configure the trigger:
**Trigger type** — the participant action that starts the send:
| Trigger | What activates it |
| - | - |
| Participant Registered | A participant completes registration for the event |
| Participant Checked-In | A participant is checked in at the event |
| Membership Created | A participant's membership is created |
| Abandoned Cart | A participant starts checkout for the event but does not complete it |
**Timing** — choose whether to send immediately when the trigger fires, or after a delay. Delays can be set in hours, days, weeks, or months — for example, send a follow-up 2 days after a participant registers.
A triggered campaign begins sending once it is set to Scheduled status. It
sends to participants who meet the trigger condition from that point forward —
it does not backfill participants who met the condition before the campaign
was activated.
## Replacing the Let's Do This abandoned cart emails
An abandoned cart email goes to someone who started checkout for your event but never finished it, prompting them to come back and complete their registration. Let's Do This sends a set of three of these for every event by default. If they don't suit your event — you want your own copy and branding, or a different message from the standard one — you can turn them off and send your own with the **Abandoned Cart** trigger.
Build your own campaign first and turn the Let's Do This reminders off only once it is live. An event with the automatic reminders off and no campaign of your own sends nothing at all when someone abandons checkout, so doing it in this order avoids a gap.
Whether you build the campaign as transactional or marketing decides who is
able to receive it. A transactional campaign sends regardless of a
participant's marketing preferences. A marketing campaign only reaches people
who have given marketing consent, and someone who abandoned checkout usually
never got far enough to give it — so the same campaign built as marketing
typically reaches very few of them, and often none.
Sending an abandoned cart email as a transactional message is not permitted
everywhere. Some countries and some US states treat it as marketing, which
means you would need the recipient's consent before sending it. You are
responsible for making sure your abandoned cart emails comply with the laws
and regulations that apply to you and to your participants — take your own
legal advice if you are unsure.
Create a transactional campaign for the event as described above. On the Schedule step, select **Triggered**, then choose **Abandoned Cart** as the action and pick the event.
The trigger fires about an hour after the checkout is abandoned. Selecting **Immediately** sends your email at that point; adding a delay counts from there, so a 2-day delay arrives roughly 2 days and 1 hour after the checkout was abandoned.
The trigger fires once per abandoned checkout. To send a series like the Let's Do This one, create a separate campaign for each message with a different delay.
Open the event, go to **Automated emails** in the event settings, and turn off **Enable Let's Do This abandoned cart emails**. Click **Save changes** — you'll see `Abandoned cart email setting saved.` once it applies.
The setting is per event and is on by default, so you need to turn it off for each event you want it off for. It stops all three Let's Do This reminders for that event and nothing else — your own campaigns still send.
## Skipped abandoned cart emails
**What happens:** some abandoned checkouts never produce an email, from Let's Do This or from your own campaign.
**Why:** the reminder only makes sense when there is a checkout to return to and the person hasn't already registered. It is skipped when the entry was a ballot, application, or volunteer registration rather than a normal purchase; when the participant was editing an existing booking rather than making a new one; and when the person has since booked anything with you, so they are no longer an abandoned cart.
**What to tell the participant:** if someone expected a reminder and never got one, check whether they completed a booking with you after the abandoned attempt — that suppresses it. They can always return to your event page and register directly.
## Abandoned cart campaign recipients
**What happens:** the Audience step does not apply to a triggered campaign. Your abandoned cart email goes to whoever matches the trigger, regardless of what you selected as the audience.
**Why:** someone who abandoned checkout is not yet on your participant list, so there is no audience segment they could belong to. The trigger configuration alone decides who gets the email, and the dashboard shows a warning to this effect on the trigger step.
**What to tell the participant:** the email goes to the address entered during the abandoned checkout — the lead booker's, or the first participant's if no booker address was given. If a participant says a reminder went to the wrong inbox, that is the address to check.
## Unsubscribes and opt-outs
Transactional emails are sent to participants regardless of their marketing email preferences, because the content is event-specific and not promotional. Transactional emails do not include an unsubscribe link — participants cannot opt out of them through the email itself.
If a participant asks not to receive further emails for an event, you can exclude them manually by removing them from the audience before sending.
## Editing and duplicating campaigns
You can edit a **Draft** or **Scheduled** campaign at any point before it sends. Open the campaign card's menu and select **Edit**.
To reuse a campaign for another event or send a similar message again, select **Duplicate** from the campaign card menu. The duplicate starts as a draft and is not tied to any schedule from the original.
## Send errors
If a campaign ends in an error state, the card shows the error type. Common causes include missing required fields (subject line or email body) and configuration issues with a custom from address. Correct the issue and resend. If the error persists, contact Let's Do This support with the campaign name and the error message you see.
# Bib assignment
Source: https://partner-help.letsdothis.com/docs/event-day/bib-assignment
Assign bibs to participants in advance, or hand them out at the desk on the day, and the settings each approach needs.
A **bib** is the number a participant wears to identify them during your event. There are two ways to get bibs onto participants, and the check-in app supports both.
* **Assign in advance.** You decide who has which bib before event day, using **Bibs & waves** in your dashboard. Participants can be told their number ahead of time, and check-in is a matter of confirming it.
* **Assign at the desk.** Participants arrive without a bib. Your team gives out a bib and records it at check-in.
## Assigning bibs in advance
A **wave** is a start group with its own range of bib numbers — a first and a last bib number. Events that set off in stages use waves to keep each group's numbers together.
In your dashboard, **Bibs & waves** takes a CSV of your waves and their bib numbers. You then filter the participants on your Startlist — the list of everyone registered — pick the wave to put them in, and assign in bulk. You'll see a preview of the changes before anything is applied, and a warning if the wave doesn't hold enough bibs for everyone you selected.
If you assign in advance, these check-in app settings matter:
* **Require a bib to check in** is on by default, and works well here — everyone already has a number, so nobody should take part without one.
* **Enforce bib validation rules** holds your team to the numbers you've set as valid for each race or wave, so a mistyped bib is caught at the desk.
* **Allow bib reassignment** decides whether your team can move a bib to a different participant when something has gone wrong.
## Assigning bibs at the desk
If participants arrive without a bib, your team assigns one during check-in. They can scan the bib with the device camera or with a handheld barcode scanner, or type the bib number in.
For this to work, turn on:
* **Allow manual bib entry**, so your team can type a number rather than only scanning one.
* **Prevent duplicate bibs**, so the same number can't be given to two participants.
Leave **Enforce bib validation rules** off unless you've set up valid ranges — with no rules to check against, it will only get in your team's way.
If your bib numbers contain letters, turn on **Alphanumeric bibs**. **Advanced bib setup** then lets you allow specific characters — hyphen, square brackets, space and comma — if your bib numbers use them.
## Using both
Nothing stops you doing both: assign most participants in advance and let your team hand out spare bibs at the desk for on-the-day entries or replacements. Set the app up as though you were assigning at the desk — **Allow manual bib entry** and **Prevent duplicate bibs** on — so your team can still record a number that wasn't planned.
All of these settings live on the **Check-in** role. See [Bib rules](/docs/event-day/setting-up-the-check-in-app#bib-rules).
# Check-in app overview
Source: https://partner-help.letsdothis.com/docs/event-day/check-in-app-overview
The check-in app is what you and your team use to check participants in on event day. It runs on iOS and Android phones/tablets, and works just as well for a 100-person event as it does for one with 60,000 participants and 20 volunteers.
Beyond checking participants in, your team can use the same app to:
* Assign bibs at the desk
* Hand out add-ons like t-shirts and medals
* Get last-minute waivers signed
* Control access to different zones
* Give medical staff one system to capture the details of participants they treat
## Check-in process
On the day, a check-in is quick:
1. **Find the participant** — scan the QR code on their booking, or search by name or bib number.
2. **Step through your check-in steps** — signing a waiver, assigning or confirming a bib, handing over add-ons. You choose which of these appear.
3. **Check them in** — they're marked in, and everyone on your team sees it instantly.
Everything your team does in the app is organised into **roles** — one for each kind of job on the day.
## Team roles
| Role | What it's for |
| - | - |
| **Check-in** | Your staff and volunteers checking participants in and checking their bibs. This is the main role most events use. |
| **Add-on fulfillment** | Volunteers handing out t-shirts, medals and other add-ons. Use this when collection happens somewhere separate from the main check-in desk. |
| **Zone management** | Staff on the gate of a zone — a festival village, an after-party, a bag drop, or any area where you want to control entry. |
| **Medical** | Your medical team, who need quick access to emergency contacts, date of birth and other medical details. |
| **Solutions** | Your solutions desk — the experienced staff who handle anything the other roles can't. Sees every participant and can override the rest. |
## Next steps
Get everything ready before event day — check-in dates, your staff, and the
app on your devices. Roles, passcodes and the rest are optional.
## Related guides
* **[Bib assignment](/docs/event-day/bib-assignment)** — assigning bibs in advance or at the desk, and the settings each needs.
* **[FAQs](/docs/event-day/faqs)** — answers to what comes up while you're setting the app up.
# FAQs
Source: https://partner-help.letsdothis.com/docs/event-day/faqs
Answers to the questions that come up while setting up the check-in app.
For the set-up itself, see [Setting up the Check-in app](/docs/event-day/setting-up-the-check-in-app).
## Role setup readiness
**What happens:** the **Role setup** tab shows **Not ready yet**, telling you the event hasn't reached the check-in app yet.
**Why:** your event details have to reach the app before there's anything to configure against. This clears on its own shortly after your event is set up.
**What to do:** wait and check again. If the tab is still showing this a day later, contact your account manager.
## Staff setup prerequisites
**What happens:** on an event where you haven't added anyone yet, the **Staff & volunteers** tab shows **Set your check-in dates first** instead of the add button.
**Why:** we use your check-in days to have the app ready and running well for your event, so we ask for them before you build your team.
**What to do:** select **Select check-in dates**, choose your days, and the tab becomes available. An event that already has staff on it keeps its list and its add button, so this only affects a fresh event.
## Dependent settings
**What happens:** turning **Hand out add-ons during check-in** on also switches on add-on allocation. Turning **Sign waivers during check-in** off also clears **Require every waiver to be signed**.
**Why:** these settings depend on each other. The app can't show add-ons during check-in unless it's showing add-ons at all, and a waiver can't be required once the waiver step has left the flow.
**What to do:** nothing — but check the section after you change either setting, so you know what your team will actually see.
## Medical field visibility
**What happens:** once you mark a registration form field as medical, you can't turn its **Visible in app** setting off.
**Why:** your medical team reads that field, so hiding it would take it away from the people who need it.
**What to do:** if you no longer want the field in the app, unmark it as medical first, then hide it.
## Solutions role permissions
**What happens:** someone using the **Solutions** role sees every participant, can reassign bibs, and can skip waivers you've marked as required.
**Why:** Solutions is your problem-solving desk. It has no restrictions, so the person on it can fix whatever the other roles get stuck on without you having to change a setting mid-event.
**What to do:** give it to your most experienced staff rather than to general volunteers, and keep its passcode on so it isn't picked up by mistake. One thing still shapes what Solutions sees: the fields on its check-in screen follow the **Participant details** list you set on the **Check-in** role, so changing that list changes what Solutions sees too.
## Saving changes
**What happens:** toggles save the moment you change them. Passcodes and the minimum signing age have their own save button, and only become saveable once you've entered a valid value.
**Why:** most settings are single switches, so waiting for a save step would only slow you down. The typed values need a deliberate save so a half-entered code is never stored.
**What to do:** watch for the confirmation after each change. If a save fails you'll see a message saying so — try again, and refresh the page if it keeps failing.
# Setting up the Check-in app
Source: https://partner-help.letsdothis.com/docs/event-day/setting-up-the-check-in-app
What you have to set up before event day, and what is optional.
To open these settings, go to your event in the dashboard and select
**Check-in app** under **⚡ Event day** in the left sidebar. You need edit
access to the event to change these settings — with view-only access you can
see how everything is set up, but the toggles and buttons won't be available
to you.
Set the app up before event day. There are two parts:
* **[Mandatory set up](#mandatory-set-up)** — check-in dates, staff, and the app on your devices.
* **[Optional set up](#optional-set-up)** — roles, passcodes, check-in flow, bib rules, zones and participant data. Each already has a working default.
New to the app? Start with [what it does and the roles your team uses it in](/docs/event-day/check-in-app-overview).
## Mandatory set up
There are three steps you have to complete. Everything else has a working default, so you can run a check-in without making further changes.
At the top of the **Check-in app** page you'll be asked **When are you going to be using the check-in app?** Choose the days you'll have the app in use and click **Add dates**.
This matters for more than your own planning — sharing your check-in days lets us keep the app fast and stable right through your event.
If your event runs across more than one day, or you run registration the day before, include every one of those days — not just event day.
On the **Staff & volunteers** tab, select **Add**, enter the person's email address and add them — they'll then be able to check participants in for this event from the app.
Each person needs a Let's Do This account. If they don't have one yet, they'll be prompted to create one when they're invited.
Add yourself too. If you're not already on the list you'll see a row offering to add you in one step, so you can check participants in on the day.
To take someone off, remove them from the list.
The **Overview** tab shows a QR code. Scan it with each phone or tablet you'll use on event day, or use the App Store and Google Play links next to it.
Make sure every device is signed in, charged, and running the latest version before event day. Walk through a check-in on one of the devices to confirm your set-up.
Without changing anything else, your team gets the **Check-in** role, a bib is required before anyone can be marked as checked in, and the app shows a standard set of participant details.
**Solutions** and **Medical** are passcode-protected by default, and every
passcode has the same default value that you should change before event day.
You can optionally add a passcode to any other role too — see
[Passcodes](#passcodes).
## Optional set up
Everything here is optional. Each setting already has a working default, so change only what your event needs.
### Roles
Each role has a switch to make it available in the app. Turn on the ones your event needs and leave the rest off — a role that's off doesn't appear as an option when your team opens the app. For what each role does, see [Team roles](/docs/event-day/check-in-app-overview#team-roles).
Select **Configure** on a role to open its settings.
### Passcodes
Each role has a **Passcode** section with an **Ask for a passcode** switch. Turn it on and your team has to enter a 4-digit code before they can use that role; leave it off and the role opens straight into the app.
Every role has its own code. Until you set a code for a role, it uses the same default code as every other role. Set a different code for each role you protect to gate access to different areas of the app.
Codes are 4 digits, numbers only. Enter the code and select **Save passcode**.
### Check-in flow
On the **Check-in** role, the **Check-in flow** section decides the steps your team works through when they check someone in.
* **Hand out add-ons during check-in** adds an add-on step to the flow, so the same person who checks a participant in also gives them their t-shirt or medal. Turning this on also turns on add-on allocation, so the app shows each participant's add-ons.
* **Sign waivers during check-in** adds a waiver step before the bib step. A **waiver** is the agreement a participant signs to take part.
* **Require every waiver to be signed** blocks check-in until all of a participant's waivers are signed. This is only available once you've turned the waiver step on.
* **Show the leaderboard** adds a **Leaderboard** tab to the app for every role, ranking your team by how many participants they've checked in. It doesn't change the check-in flow itself.
* **Signature type** is either **Typed** or **Drawn** — whether participants type their name or sign with a finger.
* **Minimum signing age** is the age below which a participant can't sign for themselves. Enter an age and select **Save age**.
Signature type and minimum signing age only apply when the waiver step is on.
### Check-in screen
On the **Check-in** role, **Participant details** decides which fields appear on a participant's check-in screen — standard fields, registration fields and any custom participant data. Which fields there are to choose from is set on the **Participant data** tab — see [Participant data](#participant-data).
This applies to the check-in flow, so **Solutions** sees the same list when it checks someone in from the **Start List**. It doesn't change the Start List entry screen itself.
### Bib rules
On the **Check-in** role, the **Bib management** section decides whether a bib is needed at check-in and how bib numbers are entered. A **bib** is the number a participant wears to identify them during your event. For how bibs get assigned — in advance or at the desk — see [Bib assignment](/docs/event-day/bib-assignment).
* **Require a bib to check in** stops anyone being marked as checked in until they have a bib. This setting is turned on by default.
* **Allow bib reassignment** lets your team move a bib from one participant to another.
* **Allow manual bib entry** lets your team type a bib number instead of scanning it.
* **Alphanumeric bibs** allows letters as well as numbers.
* **Prevent duplicate bibs** stops the same bib number being given to two participants.
* **Enforce bib validation rules** holds your team to the bib numbers you've set as valid for each race, or each start wave within a race.
**Advanced bib setup** adds specific characters — hyphen, square brackets, space and comma — to what a bib number may contain. These are only available once **Alphanumeric bibs** is on.
**Advanced bib setup** also holds three scan patterns: one for camera scans, and one each for turning a hand scanner's reads into a bib number or a booking. Most events never need them. Set one only when your bibs or badges encode something around the number and the app is picking up the wrong part of a scan — each takes a regular expression of up to 64 characters, and the app falls back to the scan as it reads it whenever a pattern doesn't match.
### Zones
If you turned on **Zone management** or **Medical**, open the role and add your zones. A **zone** is any area you control entry to — a festival village, an after-party, a bag drop, or for the medical role, a medical tent.
Give each zone a name. **Capacity** is optional: leave it blank unless you need to cap how many people can be in a zone at once.
Zones you add under **Zone management** are separate from the ones you add under **Medical**.
Deleting a zone can't be undone.
### Participant data
The **Participant data** tab controls what the app shows about each person.
**Special fields** point the app at the registration form fields that carry a participant's gender and their emergency contact relationship. Pick the field for each. Once a field is assigned, it's always visible in the app.
**Registration form fields** lists the questions from your registration form. Use **Visible in app** to choose which ones your team can see, and the medical marker to flag the ones your medical team needs — a field marked as medical moves into the medical part of the app rather than staying in the general list.
**Add-ons** lists what participants have purchased in addition to their race entry. Choose which appear in the app, and set how each one is handed over under **Fulfilment**.
If something doesn't behave the way you expect, see [FAQs](/docs/event-day/faqs).
# Add-ons
Source: https://partner-help.letsdothis.com/docs/event-setup/adding-merchandise
Create add-on products that participants can purchase alongside their ticket — including clothing, services, accessories, and more.
Add-ons are products participants can buy when they register for your event. You create and manage them from the **Add-ons** section of your organizer dashboard — a separate catalog from your tickets, with its own inventory, variants, and fulfillment settings.
Use add-ons to sell items like event clothing, finisher medals, race pack services, or nutrition products. Anything that has a price, optional variants (such as size or color), and needs to be tracked and fulfilled alongside a registration is a good candidate.
## Adding a product
In your organizer dashboard, go to **Merch** → **Products**. Click **Add product** to open the product creation flow.
Give the product a clear name and a description that helps participants understand what they're getting. Upload at least one photo — participants see it in checkout before deciding to add the item. See [Image specifications](/docs/creating-managing-events/image-specs) for the recommended size and aspect ratio.
Choose the category that best fits your product. The category determines how the item is taxed.
| Category | Common uses |
| - | - |
| Clothing | T-shirts, hoodies, socks, hats |
| Medals | Finisher medals, trophies |
| Photos | Event photos, digital downloads |
| Services | Race pack collection or postage, parking, camping, coaching, ticket upgrades |
| Accessories | Hydration packs, race belts, goggles, helmets, GPS devices |
| Transport | Shuttle buses, transfers |
| Nutrition | Gels, bars, drinks |
| Swimwear | Wetsuits, swim caps, goggles, swimsuits |
| Other | Anything that doesn't fit the above |
Some categories — particularly Clothing and Swimwear — ask you to pick a sub-category (for example, Tops / Bottoms or Wetsuit) so the tax treatment is accurate.
Choose how participants receive the item:
* **Ship to buyer** — participants provide a shipping address during checkout and the item is sent to them. See [Shipping addresses for add-ons](/docs/event-setup/shipping-addresses-for-add-ons) for how to collect and manage addresses.
* **Pick up on race day** — participants collect the item at the event.
If neither applies, you can leave this unset.
Enter a price. The maximum is \$999.99 per variant (or the equivalent in your event currency).
For stock, enter how many units you have available or turn on **Unlimited stock** if you don't want to cap purchases. When a limited-stock product runs out, it becomes unavailable in checkout automatically.
If your product comes in different options — such as size, color, or fit — define those options and the system generates a variant for each combination. Each variant can have its own price and stock level.
For example, a hoodie might have Small, Medium, Large, and XL variants, each tracking its own inventory.
* **Purchase limit** — the maximum number of units a single participant can add to their order.
* **Mandatory** — if turned on, the product is automatically included in checkout for eligible participants and they must take a minimum quantity you specify. Use this for items every participant receives, such as an included finisher T-shirt.
By default, a product appears for all participants across all your events. You can restrict it to specific events, race categories, or ticket types — for example, to offer a product only to participants in a particular race or on a specific ticket.
## Participant experience
After filling in their details, participants reach a dedicated **Add-ons** step in checkout. Each available product appears as a card. Participants click a card to view the description, select a variant if the product has one, and add it to their basket.
Once added, the item appears in the basket. Participants can increase or decrease the quantity before continuing to payment. The final order summary and success page show every add-on they purchased.
## Tracking sales and managing entries
To see add-on sales data, use the **Reports** section of your dashboard. To make changes to a participant's add-ons after registration — such as swapping a variant or removing an item — use the **Startlist**.
## Limits and edge cases
**Quantity per order.** If you don't set a purchase limit on a product, the system caps each participant at 100 units of that product per checkout session.
**Out-of-stock items.** When a product with limited stock sells out, it stops appearing in checkout. It reappears automatically if stock is restored — for example, if a booking is refunded and the inventory is returned.
**Mandatory products and group bookings.** Mandatory add-ons apply per individual participant, not per group booking. Participants claiming entries from a group booking do not see mandatory add-ons in their checkout flow.
**Payment plans.** When a participant is on a payment plan, the cost of add-ons is spread across installments alongside the ticket — unless the add-on pays a third party directly, in which case it is charged in full as part of the first installment. See [Payment Plans](/docs/event-setup/payment-plans) for more detail.
# Bulk Buy Discount
Source: https://partner-help.letsdothis.com/docs/event-setup/bulk-buy-discount
Reward participants who buy several tickets in one order with an automatic group discount, set up as quantity tiers.
Bulk buy discount lets you reward participants who book several tickets in a
single order. You set up one or more **tiers** — for example, "5 or more
tickets = 10% off" — and the discount is applied automatically at checkout
once a participant's basket reaches a tier. There's no code for them to enter.
The discount is set up once at the organizer level and applies across your
events. It's a good way to encourage group bookings — friends, clubs, teams,
and families buying together.
You can turn it off for any event you don't want it on, using the **Enable Bulk
Buy discounts** toggle in that event's **Sales options**. When it's on for an
event, it applies to **all tickets** in that event — you can't limit it to
specific tickets.
For the discount to reward a basket that spans several of your events,
participants need to be able to add tickets from different events to one
basket. That requires **Multibuy** in each event's **Sales options** to allow
tickets from your other events. If you keep Multibuy to a single event only,
the discount still works within that event's basket — it just won't combine
tickets across events.
Take a percentage off the qualifying tickets — for example, 10% off once the
basket reaches 5 tickets.
Take a fixed amount off the order once the basket reaches a tier.
## Discount eligibility
The discount is automatic. As a participant adds tickets to their basket, the
checkout tracks how many they've selected and applies the best tier they
qualify for:
* The discount only applies to **paid** tickets. Free tickets don't count
toward a tier and never get a discount.
* A **percentage** discount comes off the total price of the qualifying paid
tickets in the order.
* A **fixed amount** discount comes off the order once the tier is reached.
* The participant always gets the **best tier their basket qualifies for** —
if they reach a higher tier, the larger discount applies.
* When a basket spans multiple events, your organizer-level tiers determine the
group discount — adding more tickets automatically upgrades the participant to
the larger discount.
When the discount is active, the participant sees a line on their order summary
reading **"Bulk buy discount"** with the amount deducted.
## Setting up your discount tiers
You configure bulk buy discount from your dashboard, under **Growth** →
**Bulk buy discount**. You need an **Editor** or **Admin** role on the organizer
account to change these settings — a **Viewer** can't. If the controls are
grayed out, ask your account owner to grant you the right role.
Switch **Enable bulk buy discount** on. While this is off, no discounts
are offered and any tiers you've entered won't apply.
Under **Add new discount**, fill in the tier:
* **Number of tickets** — the quantity a participant must reach to unlock
this tier. The minimum is **2** tickets.
* **Discount Type** — choose **Percentage (%)** or **Minus (-)** for a
fixed amount.
* **Discount %** or **Discount** (shown with your currency symbol) — the
size of the discount. A percentage must be between **0 and 100**. A
fixed amount must be **0 or more**.
Click **Add** to add the tier to your list. If you use a ticket count that
already exists, the new entry replaces the old one when you save — check
**Current discounts** after saving to confirm each tier reads the way you
intended.
Repeat to build a ladder of discounts that grows with basket size — for
example, 2+ tickets = 5% off, then 5+ tickets = 10% off. Your tiers are
listed under **Current discounts**, sorted by ticket count. To remove a
tier, use the delete button next to it in the list.
Click **Save Changes** to publish. The button stays disabled until you've
made a change, so if it's grayed out there's nothing new to save. To remove
every discount, switch **Enable bulk buy discount** off and save.
## Participant checkout experience
As participants choose tickets, a banner highlights the discount and nudges
them toward the next tier. The exact message depends on where they are:
| Situation | What the banner says |
| - | - |
| They haven't reached a tier yet | "Add 2 more tickets to save 10%" |
| They've earned one tier and a bigger one is available | Confirms their current saving and nudges them toward the next tier |
| They've reached your top tier | "Save up to 10% with group booking" |
| The discount is applied to their order | "10% group discount applied" |
If you've set up more than one tier, the banner also shows the full ladder so
participants can see what's on offer — for example, "2 or more = save 5%" and
"5 or more = save 10%".
# Bundles
Source: https://partner-help.letsdothis.com/docs/event-setup/bundles
Package tickets from multiple events into a single discounted purchase, as a fixed set or a flexible pick-and-mix, to increase bookings and grow participants per transaction.
Bundles let you group tickets from any events in your portfolio into one
purchase. A participant adds the bundle to their basket, fills in their details
once per ticket, and gets a discount for booking together, with no promo code
needed.
Bundles are set up at the organizer level, not per event, so one bundle can span
any combination of events you run. Bundles are limited to ticket entries;
add-ons cannot be included in a bundle.
Bundles are designed for a single participant booking several entries for
themselves, not for buying on behalf of a group. They are not built for
multi-participant purchasing flows where one booker enters many different
people, so don't use a bundle to sell team or group entries.
## Fixed and flexible bundles
Every bundle uses one of two buyer-choice rules, set under **Bundled tickets**:
| Rule | Setting in the dashboard | What the buyer does |
| - | - | - |
| **Fixed** | **Every ticket required** | Buys every ticket in the bundle (all or nothing). |
| **Flexible** | **Let buyers choose a selection** | Buys a number of tickets you allow, within a minimum and maximum you set. The discount can scale up as they add more. |
A flexible bundle lets buyers build their own selection from the tickets you
include, and lets you reward larger selections with a bigger discount through
**tiers**. For example:
Offer three events and let buyers pick any two or more. Give 10% off for
two, rising to 15% off if they take all three.
One ticket group per event, each holding a choice of distances. Buyers enter
every event for a discount, picking Sprint or Olympic at each.
Bundle a Saturday race with a Sunday one (for example a 5K shake-out and a
Sunday half or full) so participants commit to both at a saving.
Pair a high-demand event with a smaller one to lift entries for both and
bring in participants who wouldn't have found the newer event on its own.
## Creating a bundle
Bundles are managed from the **Bundles** area of your organizer dashboard. Click
**Create bundle**, then work down the page.
Under **Bundle setup**, enter a **Basket label**, the label that appears in
the basket and identifies the bundle in your dashboard. You can also add the
details shown on the checkout card here:
* **Title**: a short heading shown on the bundle card in checkout.
* **Body**: body copy shown on the bundle card.
* **Banner copy**: a short promotional line displayed on the card.
* **Image**: a photo shown in the bundle card.
Under **Bundled tickets**, build the bundle out of **ticket groups**. Each
group is one slot in the bundle. Click **Select tickets** to add tickets
from any of your events. Different dates, locations, or categories all work.
A group can hold a single ticket, or several **options**. Click **Add
options** to give a group more than one ticket. When a group has multiple
options, the buyer chooses only one of them (for example a choice of
distances at the same event). Every group must have at least one ticket
before the bundle can go live.
Once the bundle has two or more ticket groups, choose how many the buyer must
take under **Buyer choice**:
* **Every ticket required**: a fixed bundle. The buyer purchases every
ticket group.
* **Let buyers choose a selection**: a flexible bundle. Set the
**Minimum** number of tickets the buyer must take and, optionally, a
**Maximum**. Leave the maximum as **No limit** to let them take as many as
you offer. The dashboard reads this back as, for example, "Buyers pick
between 2 and 3 events."
Under **Discount**, choose the **Discount type** and enter a **Discount
value**. The type controls how the saving is applied to the tickets:
| Discount type | What it does |
| - | - |
| **Percent off** | Takes a percentage off the qualifying tickets |
| **Money off** | Takes a fixed amount off the qualifying tickets |
| **Bundle price** | Sets a specific total price for the qualifying tickets |
To also discount the booking fee, click **Add booking fee discount** and
configure a second discount in the same way.
A bundle without a configured discount is still valid. You can use bundles
purely to let participants book multiple events in one checkout.
On a flexible bundle you can reward larger selections with a bigger saving.
Click **Add tier** and set **Unlocks at** to the number of events that
unlocks the better discount, for example a base discount at 2 events and a
higher tier that unlocks at 3.
Buyers get the single best tier they qualify for; tiers never stack.
Under **Visibility**, click **Choose events** and select the event
occurrences whose checkout pages should advertise this bundle. A bundle with
no events selected is saved but not shown anywhere in checkout.
Under **Usage limits**, set **Limit per booking** to cap how many times this
bundle can be added in a single checkout. Leave it as **Unlimited** for no
cap.
Under **Enable bundle**, switch the toggle on when the bundle is ready to go
live. The toggle stays locked until the bundle has tickets, a discount, and
at least one event selected. The readiness callout, "A few more steps before
you can enable this bundle," tells you what's still missing.
Click **Save** to publish.
## Bundle statuses
Each bundle in your list shows one of three statuses:
| Status | What it means |
| - | - |
| **Enabled** | Booking is on and the bundle appears in checkout on its selected event pages |
| **Unlisted** | Booking is on, but no events are selected, so the bundle is not shown anywhere |
| **Disabled** | Booking is off, so participants cannot add the bundle to their basket |
You can turn booking on or off at any time from the Bundles list. Turning it off
removes the bundle from checkout immediately; you'll be asked to confirm first.
If a bundle isn't appearing in checkout, check that it is enabled, that the
relevant events are selected under **Visibility**, and that the readiness
requirements (tickets, discount, and at least one event) are all met. If the
**Enable bundle** toggle is locked, the readiness callout on the bundle page
shows exactly what's still needed.
## Participant checkout experience
When a bundle is enabled and linked to an event, participants see a bundle card
alongside the individual ticket options on that event's checkout page. The card
shows:
* The basket label and (if set) title and body.
* The tickets included in the bundle.
* The saving, for example "You save 10%".
For a **fixed** bundle, adding the card adds every ticket. For a **flexible**
bundle, the buyer picks their selection. Checkout prompts them to "Select at
least 2 of 3 tickets" (using your minimum and the number of tickets on offer),
and the discount that applies reflects the tier their selection reaches.
The discount applies automatically, with no promo code needed. It does not
affect a ticket's individual price; the discount only applies when the tickets
are booked as part of the bundle. Participants can also add individual tickets
alongside a bundle in the same checkout, and can add the same bundle more than
once unless you set a **Limit per booking**.
In the basket and order summary, each bundle appears as a grouped section
listing its tickets and a **Bundle discount** line showing the amount saved.
Once a bundle booking is confirmed it cannot be changed through self-service.
Contact your Let's Do This account manager or LDT support to discuss options for
that booking.
## Booking forms
Participants complete the information relevant to each event in the bundle,
filling in one booking form per ticket they take. Where a field is the same
across those tickets, we consolidate it and ask for it only once, so the
participant doesn't repeat themselves. Fields that are unique to a particular
ticket appear on that ticket's form.
# Corporate Teams
Source: https://partner-help.letsdothis.com/docs/event-setup/corporate-teams
Let a team captain purchase and manage entries on behalf of their organization.
Corporate teams is a specialized feature for workplace and corporate event
programs. This page describes how it works. If you're interested in using it
for your event, contact your account manager.
Corporate teams work differently from standard teams. A corporate team has a designated captain who manages the team on behalf of their organization — typically purchasing entries for participants rather than participants booking independently.
## Setting up a corporate team program
Corporate teams are configured under the **Teams** tab in event setup, the same place as standard teams.
In your event setup, go to the **Teams** tab and click **Create team setup**.
Give the setup a name for your internal use, then select **Corporate** as the team type.
Corporate teams do not use ticket restrictions or team roles — those options are not available for this type.
Enter a **Minimum team size** and a **Maximum team size** if needed. Leave either blank to set no limit on that end.
Toggle on **Prevent new corporate teams** if you want to stop participants from creating their own corporate teams at checkout. With this on, participants can only join an existing team — useful when all teams are created centrally by captains.
Click **Save**. The corporate team setup is now active.
## Captains and co-captains
Corporate teams display a **Captains** section at the top of the Members tab, separate from the general member list. A team can have one main captain and one or more co-captains.
To add a co-captain from the team page:
On the team page, open **Manage team** and select **Add Team Captain**.
Type in their email address and click **Generate login**. A unique, single-use login link is created.
Copy the link and send it to the co-captain. When they follow it, they sign in (or create an account) and are given captain-level access to the team page, where they can view and purchase entries and add-ons.
The link can only be used once. If it expires or is lost, generate a new one.
## Buying tickets for team members
Corporate team captains can purchase entries on behalf of participants directly from the team page.
From the Members tab, click **Add tickets** to open the ticket purchasing flow:
Choose the ticket type and the number of entries to purchase.
Decide whether you want to cover part or all of the ticket cost for each participant (a subsidy). If you choose not to contribute, participants pay the full price themselves.
If you're contributing, enter the amount or percentage you'll cover per ticket. The remaining balance is what each participant pays.
Review the total cost and what each participant will pay, then confirm.
After confirming, you receive an invite URL. Share it with participants so they can follow the link, complete their registration details, and claim their reserved spot.
## Payments
Corporate teams have a **Payments** tab, visible to captains and organizers, showing:
* **Outstanding balance** — the total amount currently owed for subsidized entries. Click the balance to open a breakdown, then click **Settle up with Stripe** to generate an invoice and pay via Stripe.
* **Invoice history** — a list of past invoices, each showing the date, amount, and status (pending or paid).
If there is any tax on the outstanding balance, it will be included when you
generate an invoice.
# Credits
Source: https://partner-help.letsdothis.com/docs/event-setup/credits
Issue and manage account credit that participants can redeem toward a future booking.
Account credit is a balance held against a participant's Let's Do This account that they can put toward a future booking with you. Credit is created two ways: automatically, when you convert an existing booking — see [Transfer to credit](/docs/managing-participants/transfers#transfer-to-credit) and [Refund to account credit](/docs/managing-participants/refunding#refund-to-account-credit) — or directly, by issuing credit to a participant's email address without touching an existing booking. This page covers issuing and managing credit directly; the two linked pages above cover converting a booking into credit.
## Issuing credit directly
Use this when you want to give a participant credit that isn't tied to canceling one of their bookings — for example, as a goodwill gesture or to resolve a support issue.
From your organizer dashboard sidebar, select **Growth**, then **Credit**. Click **Create**.
Enter the participant's **email address** and the **credit amount**. The credit applies automatically the next time that email address is used to book with you — the participant doesn't need to redeem a code.
Under **Applies to**, choose what the credit can be spent on: the **whole basket**, **tickets** only, the **booking fee**, **merch and add-ons**, or **form items**. You can select more than one. Donations can never be covered by credit.
Turn on **Add expiry date** and choose a date. Credit must be used before this date, shown to the participant as the end of that day (UTC). Leave it off and the credit never expires.
By default the credit can be used on **all events, races and tickets**. Click **Choose selection** to restrict it to specific events, races, or ticket types instead.
Click **Save**. A summary shows the recipient, what the credit applies to, and the total amount. Choose whether to **send an email to notify the participant**, then confirm.
Whether or not you send the notification, the participant can always see the credit in their Let's Do This account.
## Managing issued credit
The Credit page lists every credit issued to your participants, whether you created it directly or it was generated by a transfer or refund to credit. Above the table you'll see the total number of transfers and the total unused credit value.
Use **Hide Expired** and **Hide Used** to narrow the list, or search by the participant's **email address** or by **event**.
Each row shows:
* **Email Address** — the recipient.
* **Credit Remaining** — the unused balance.
* **Expires on** — the expiry date, if one was set.
* **Applies to events** — which events, races, or tickets the credit is restricted to, or all of them.
* **Applies to items** — which basket items the credit covers.
* **Origin** — how the credit was created: created by you directly, or generated from a transfer or refund to credit, naming the event it came from.
To change a credit, select its row and click **Modify**. You can update everything except the recipient's email address, which is fixed once the credit is created.
## Viewing a participant's credit
Open a participant's profile from **Customers** to see any credit on their account. Their card shows the amount and links through to the same edit view as the Credit page.
## Participant experience
Participants view their credit from their Let's Do This account. It shows the total credit remaining and, if one was set, when it expires.
Below that, they see which of your events the credit can be used on. If you didn't restrict the credit, every one of your upcoming events is listed; if you did, only the eligible events, races, or tickets appear. Selecting an event lets them view its event page or go straight to booking a race.
The credit itself is applied automatically at checkout — as long as the participant checks out using the email address the credit was issued to, they don't need to do anything else to redeem it.
# Discount Codes
Source: https://partner-help.letsdothis.com/docs/event-setup/discount-codes
Create single or bulk promo codes that participants enter at checkout to receive a percentage or fixed-amount discount.
Discount codes let you offer promotions, reward communities, or run partner campaigns. You create the codes in your dashboard and participants enter them at the payment step of checkout. Each code can be as broad or specific as you need — all events, a single ticket type, or anything in between.
## Creating a discount code
Go to **Marketing** → **Discount codes** and click **Create discount code**. The form is split into sections; fill them in from top to bottom.
### Code setup
You can create one code at a time or import many codes at once from a CSV file.
Select the **Single code** tab to create one code, or the **Import bulk** tab to upload a list.
**For a single code:**
* **Code** — the text a participant types at checkout. Spaces are removed automatically and the code is stored uppercase. Make it memorable but not guessable.
* **Internal code name** — an optional label visible only to you, useful for grouping codes by campaign.
* **Internal description** — a short note to remind you what this code is for.
**For bulk import:**
Download the CSV template using the **Download template** link, fill in your codes in the `Codes` column (one per row), then drag the file into the upload area. The platform checks for duplicates against existing codes before you save. Any duplicates are flagged so you can remove them from the file and re-upload.
### Discount calculation
Choose how the discount is calculated:
* **Transaction discount** — the code reduces the total order once at checkout.
* **Entry discount** — the code reduces the price of each qualifying ticket in the order. You can optionally cap how many entries it applies to per transaction using **Limit per transaction**.
Choose **%** for a percentage off or the currency symbol for a fixed amount off.
* **Percentage:** enter the percentage and, optionally, a maximum discount cap (the most the code can take off a single transaction).
* **Fixed amount:** enter the exact amount to deduct.
Tick at least one item type:
* **Tickets**
* **Booking fee**
* **Merch & add-ons**
* **Booking form items**
If your organizer account has a membership scheme, a **Memberships** option also appears. Membership discounts cannot be restricted to specific events, races, or tickets — the event restriction section is disabled when you select this option.
### Usage limits
Both limits are optional. Leave them blank for unlimited use.
| Setting | What it controls |
| - | - |
| **Limit total redemptions** | Maximum number of times the code can be used in total. Must be 1 or more if set. |
| **Limit per customer** | Maximum uses per email address across the customer's lifetime. |
### Availability
By default a code works across all your events. Click **Choose selection** to restrict it to specific events, occurrences, races, or ticket types. Once saved, the selection is shown as **View selection**.
Tick **Add a start date**, then pick a date and time. The code won't be accepted at checkout before this point.
Tick **Add an expiry date**, then pick a date and time. The code stops working at the end of that day in your local timezone.
### Affiliate commission (optional)
If you want to track and reward a partner for driving sales, turn on **Link code to affiliate**. You'll be asked for:
* **Affiliate name** — a display name for the partner.
* **Affiliate email address** — where commission notifications go.
* **Commission** — either a percentage of the booking value or a fixed amount per redemption.
Affiliate name, email, and commission type cannot be changed after you save
the code. Double-check these before creating.
### Saving
Click **Create** to publish the code. It becomes active immediately (or on the start date if you set one).
## Participant experience
Participants enter the code on the payment page during checkout. The field sits below the order summary. If the code is valid, the discount is deducted and the updated total is shown before they pay. If the code is invalid or not applicable to their order, they see an inline error such as:
> "Discount not applied: Sorry, this code cannot be used towards this event"
A participant can remove the code and try a different one before completing payment.
## Managing existing codes
From **Marketing** → **Discount codes** you can:
* **Search and filter** codes by name or group.
* **Edit** usage limits, expiry dates, event restrictions, percentage, and description.
* **Delete** one or more codes.
* **View usage** — click a code to see which bookings used it and a total usage count.
The code text itself and any affiliate settings cannot be edited after creation.
## Bulk import errors
If the duplicate check flags codes after a CSV upload, the upload area shows how many duplicates were found. Remove those rows from your CSV file and upload the corrected file. The rest of your codes are not affected — only the duplicated entries are rejected.
# Early Bird Pricing
Source: https://partner-help.letsdothis.com/docs/event-setup/early-bird-pricing
Why an Early Bird price drives early sign-ups, and what we recommend — then set one up using price changes.
An Early Bird price is a discount for booking early — for a limited time, or for a limited number of places — before the price rises to your standard rate. It's one of the most effective ways to get bookings in early and build momentum from the moment your event goes live.
This page covers why to use it and what we recommend. When you're ready to set one up, you do it with [price changes](/docs/event-setup/ticket-price-changes) — an Early Bird offer is simply a price change with a lower price and an Early Bird label.
## Early Bird pricing benefits
Early revenue and entry numbers give you a clearer picture sooner, and help
fund your event's setup costs up front.
The people most likely to commit early get a better price for doing so — a
fair trade that builds goodwill.
A price that ends on a date or after a set number of places gives people a
concrete reason to book now rather than wait.
Early sign-ups create social proof and word of mouth that carry into the
rest of your sales window.
## Pricing recommendations
* **Set the Early Bird price meaningfully below your standard price.** The gap needs to be big enough to feel like a genuine reward for booking early.
* **Give it a clear end.** Decide whether it ends on a date, after a set number of places, or both — ending on a date is predictable for your marketing, while ending on quantity caps how many discounted places you sell. You can use both, and whichever comes first ends the offer.
* **Build a price ladder.** Step up from Super Early Bird to Early Bird to your standard price, so the price rises as the event fills and there's always a reason to act now.
* **Always set a price label.** The label drives the urgency banner participants see — it's the part that turns a lower price into a reason to book today. Use Super Early Bird for your first tier and Early Bird for the next.
* **Avoid a gap between tiers.** Schedule each price to begin immediately after the previous one ends, so the ticket doesn't drop back to its standard price in between.
Plan your full ladder — prices, end conditions, and labels — before the first
tier goes live. An active price can't be edited directly, so a little planning
up front saves you unpicking a live price later.
## Participant experience
While the Early Bird is active, participants see the lower price and an urgency banner on the ticket — for example "Early Bird — only 5 days left!" or "Early Bird — only 3 left at this price!". When it ends, the price moves to your next tier (or standard price) automatically, and the sold-out Early Bird is shown as an earlier offer that's no longer available.
## Setting it up
Early Bird pricing is configured with price changes, on the ticket itself. For the full step-by-step — start and end conditions, labels, building a ladder, and managing the schedule — see [Ticket Price Changes](/docs/event-setup/ticket-price-changes).
# Fast Checkout
Source: https://partner-help.letsdothis.com/docs/event-setup/fast-checkout
Speed up large group bookings by collecting only the booker’s contact and payment details at checkout, with participant details completed after purchase.
Fast Checkout shortens checkout for group bookings. When a participant buys at or above a minimum number of tickets you set, they pay with just their **contact and payment details** instead of completing a form for every participant — the per-participant race-day details are filled in after purchase. This removes the biggest drop-off point for groups: filling in many forms before paying, which is why it lifts conversion on larger bookings.
## Fast Checkout use cases
Fast Checkout helps most where someone books several entries at once — a running club captain entering their members, a company booking a team, a group of friends signing up together.
* **Set the minimum where a booking becomes a "group."** Five tickets is the common threshold, but choose what fits your event.
* **Use it on tickets people buy in bulk.** There's little benefit on a ticket almost always bought one at a time.
* **Have a plan to collect participant details later** (see [Collecting participant details after purchase](#collecting-participant-details-after-purchase)).
## Setting up Fast Checkout
Fast Checkout is configured per ticket, in the ticket's **Fast checkout** section.
Edit the ticket and find the **Fast checkout** section.
Switch on **Enable Fast Checkout** for this ticket.
Set the **Minimum ticket quantity** — the number of this ticket a participant must select to use Fast Checkout.
Save the ticket.
## Participant experience
When a booking meets the minimum, the booker enters their own contact and payment details, pays, and the booking is confirmed — with no per-participant form first. Below the minimum, the same ticket falls back to normal checkout, with a details form for each entry. So how a ticket behaves depends on how many a person buys.
## Collecting participant details after purchase
Because participant details are gathered after purchase, plan how you'll collect them. Entries are paid and confirmed, but race-day details may be blank until someone completes them.
Let bookers know they (or their participants) need to finish each entry's details, and set a deadline that leaves you time before the event. If you rely on those details for fulfillment — start lists, waves, merchandise sizing — chase any that are still incomplete as the event approaches.
# Payment Plans
Source: https://partner-help.letsdothis.com/docs/event-setup/payment-plans
Let participants spread the cost of an event across monthly installments instead of paying in full at checkout.
Payment Plans let participants split the cost of an event into interest-free **monthly installments** — fixed payments spread evenly across time — rather than paying the full amount at checkout. You turn the feature on for an event, participants choose it at checkout, and each installment is charged automatically to the same card once a month until the plan is complete.
## Payment Plan use cases
Payment Plans work best when ticket price is a genuine barrier to entry. We recommend enabling them for events where tickets cost **£100 / \$100 or more** — at that price point, spreading the cost meaningfully increases the likelihood of conversion. Common examples include multi-day events, overseas destination races, and premium endurance experiences.
Registration timing matters too. The more months between registration opening and the event, the more installments participants can take — and the more attractive the option becomes. Events with a short selling window (less than two months before the Last possible payment date) will see limited uptake, as the feature stops appearing in checkout once fewer than two installments can fit.
There are some limitations to be aware of — these are covered in detail further down this page. If you are unsure whether Payment Plans are a good fit for your event, contact your account manager.
**Getting the most from Payment Plans:**
* Set the **Last possible payment date** a few weeks before the event itself, so every plan completes before participants arrive.
* Use the **Payment Plans report** (Data & Insights → Reports) to monitor paid vs. total installments across all participants and reconcile against fulfillment lists.
* Commission is spread evenly across installments, so splitting a payment does not change what you net overall.
## Installment calculation
When a participant chooses a plan, the number of installments they receive is whichever is smaller:
* The **maximum number of monthly payments** you set (between 2 and 30), or
* The number of **whole months remaining** between their purchase date and the event's Last possible payment date.
For example: if you set a maximum of 8 installments and a participant buys 3 months before the Last possible payment date, they get 3 installments — not 8. As the event approaches and time shrinks, the installment count drops automatically. An event that offered 8 monthly payments in January might only offer 3 by May, with no change from you.
Once there is less than 1 month until the Last possible payment date, Payment Plans stop appearing in checkout entirely — there is not enough time to fit two installments.
The first installment is taken at checkout. Subsequent installments are charged automatically on the same day each month. The first payment may be a penny or two higher than later ones to absorb rounding, and it also covers any items that must be paid in full upfront (see [Items charged in full on the first payment](#items-charged-in-full-on-the-first-payment) below).
## Setting up Payment Plans
Payment Plans are configured at the event level, with an optional per-ticket opt-out.
On the event setup screen, toggle **Payment Plans** on.
![Enable Payment Plans setting with 0% interest, up to 4 retries, and Terms & Conditions notes]()
The feature is recommended for high-cost events. By enabling it, you agree to LDT's Payment Plans terms. The setup panel also recommends updating your own sales terms for participants.
Choose **Maximum number of monthly payments**. The allowed range is **2–30**, and the default is **4**.
This is a cap, not a fixed number. The actual installment count a participant sees is calculated live at checkout based on how much time remains before the Last possible payment date — it may be lower than your maximum.
Choose **Last possible payment date** — the latest date you are willing to accept the final installment.
As this date approaches, the number of available monthly payments reduces automatically to fit the remaining time. Once fewer than two installments can fit, the option disappears from checkout.
Set the Last possible payment date a couple of weeks before the event itself, so every plan finishes collecting before participants arrive.
On the **Tickets** tab, edit any ticket and turn its **Enable Payment Plans** toggle off. That ticket will only show "Pay in full" in checkout, even though the event allows plans on other tickets.
All tickets are opted in by default once you enable Payment Plans at the event level — opting out is per-ticket.
## Updating your Terms & Conditions
When you enable Payment Plans, you should update your event's Terms & Conditions to reflect how installment payments work. Clear T\&Cs protect both you and your participants by setting expectations upfront around payment schedules, participant obligations, and what happens if a plan is canceled or a payment fails.
The setup panel includes a reminder to do this. Contact your account manager or LDT support for suggested T\&C language you can add to your event.
## Payment Plan visibility
A participant only sees the Payment Plans option when **all** of the following are true:
* You have turned Payment Plans on for the event.
* There is enough time for at least two monthly payments before the Last possible payment date.
* The specific ticket they are buying has not been opted out.
* The ticket is paid (free tickets never show the option).
If any condition is not met, checkout silently falls back to Pay in full and no monthly option appears.
## Participant experience
### On the event page
When the event qualifies and the ticket is not opted out, a **"Payment plans available — Spread your payments with Let's Do This"** callout appears against the ticket listing.
### In checkout
After filling in their details and reaching the Review step, participants see two stacked options under **Select payment method**:
* **Pay over *N* installments** — where *N* is calculated live from your maximum payments setting and the time remaining before the Last possible payment date.
* **Pay in full**
![Checkout payment method selection showing Pay over 4 months, a dated installment schedule, 0% interest, and an order summary with upcoming payments and balance due]()
Selecting "Pay over *N* installments" reveals a **How it works** callout showing:
* The amount to pay today (the first installment).
* A dated list of upcoming installments. Dates are always shown in US format (e.g. "November 11, 2026"), regardless of the participant's locale.
* 0% interest confirmation and the total cost.
* A link to LDT's payment and cancellation terms.
The order summary on the right also updates to show the ticket as "Pay over *N* months", the full subtotal and total, and a "To pay today" line with the first installment amount.
### After checkout
The success page shows the full total, what was charged today, an Upcoming payments section listing each scheduled installment with its date and amount, and the balance remaining.
From their account, a participant can:
* See the current status of their plan: **Active**, **Canceled**, or **Completed**.
* Update the card on file used to charge future installments.
* Cancel the plan. The in-product warning is explicit: canceling the plan also cancels the registration, and a refund is not guaranteed. If they only want to update card details, they should use **Update payment details** instead.
## Managing plans
### Checking a single booking
Open the event's bookings list and click **Expand** on the booking you want to inspect.
![Event bookings list with the Expand button highlighted on a confirmed booking]()
The booking's **Payments** section lists every installment with its status — **Complete** for payments already taken and **Upcoming** for those still scheduled, each with its date and amount.
![Booking Payments section showing a Complete payment and three Upcoming payments with dates and amounts, plus a View Stripe Subscription link]()
A **View Stripe Subscription** link opens the underlying subscription if you need more detail.
In the bookings list, each booking on a plan has a **Payment Plan Status** column showing one of: **Active**, **Canceled**, **Completed**, or **Unknown**. If you see **Unknown**, contact LDT support with the booking ID.
### The Payment Plans report
For a view across all participants on a plan, use the **Payment Plans** report under **Data & Insights → Reports**.
![Dashboard Reports page under the Data & Insights menu]()
![Payment Plans report grid showing total and paid installments, total and paid amounts, currency, start date and next installment per plan]()
The report gives one row per plan, with columns for Total Installments, Paid Installments, Total Amount, Paid Amount, Currency, Start Date, Next Installment, and the event. You can filter, choose columns, and export — useful for reconciling who has paid what and cross-referencing against fulfillment lists.
## Good to know
### Items charged in full on the first payment
Even on a plan, some items are not spread across installments — their full cost is collected as part of today's first payment. Everything else (the ticket and most add-ons) is split evenly.
Items always charged in full upfront:
* **Refund Protect** (refundable booking) purchases.
* **Memberships** (e.g. a federation membership such as a British Triathlon license).
* Anything that pays a **third party** directly — charity donations, external registration or license providers, insurance, or third-party merchandise.
This is why the first payment is sometimes larger than a straight total ÷ number of months. It is expected behavior, not an error.
You cannot currently exclude add-ons from plans. When a plan is enabled, paid add-ons are included and split across installments along with the ticket.
### Refunds
The organizer-facing refund tool **cannot** process refunds on payment-plan bookings. This applies to both full and partial refunds.
To refund a participant on a payment plan, contact LDT support with the booking ID and the amount to be refunded. LDT will process it on your behalf. Only money already collected can be refunded — future installments have not been charged. Processing the refund also cancels the plan and the registration.
Refunding an add-on on a payment-plan booking does **not** re-price the remaining installments. The participant continues paying the original monthly amount. The subscription is only canceled on a full refund or when the final installment is taken. Removing an add-on from a booking without issuing a refund leaves both the total and the installment schedule unchanged.
### Transfers and deferrals
Transferring an entry with an active payment plan is blocked by the system. The transfer flow displays:
> Entries with active payment plans cannot be transferred.
Deferrals are not blocked in the same way, but an active plan should be resolved before deferring — the plan cannot carry over to a new entry.
Your options in both cases:
1. Have the booking refunded (via LDT support — see [Refunds](#refunds) above) and ask the participant to re-enter the new event, starting a fresh plan.
2. Note the booking and process the transfer or deferral once the plan is complete.
### Missed payments and cancellations
If a scheduled installment fails (expired card, insufficient funds, bank decline), LDT retries automatically — up to 4 retries. The participant is notified of each failed attempt and can update their card from the booking management page.
If every retry fails, the plan and the booking are canceled and **cannot be reinstated**. The participant must re-book. Common ways to handle this:
* Issue account credit for the amount already paid, so the participant only owes the remaining balance on re-booking. LDT can help apply credits.
* Reserve an entry and arrange payment separately.
* Process a manual re-entry and adjust accordingly.
Any refund of the amount already paid on a canceled payment-plan booking must go through LDT support — you cannot issue it directly.
### Editing and early payoff
Once a plan has started, neither you nor the participant can change its terms, and the participant cannot settle the remaining balance ahead of schedule. Installments are only taken automatically on their scheduled dates.
If a change is needed, the plan must be canceled, the participant refunded (via LDT support), and a new booking and plan started.
Some actions — such as changing race category — are only available once a plan is fully paid. Participants who want to make those changes earlier will need to wait until all installments are complete.
### Commission
Commission is applied evenly across installments. Each monthly payment carries its proportional share, so the total commission is the same as it would be on a Pay in full booking. Splitting the payment does not change what you net.
# Referral Programs
Source: https://partner-help.letsdothis.com/docs/event-setup/referral-programs
Reward participants for referring friends to your events. You set the reward structure, which events qualify, and the payout date.
Referral programs let you reward participants for bringing friends to your events. After booking, participants receive a personal referral link to share. When a friend uses that link to sign up, both earn a reward. You control the reward structure, which events qualify, whether referred friends also get a discount, and when payouts are processed.
Referrals are only available on events where the highest ticket price is more
than 10 in the event's currency. Events below this threshold don't show the
referral prompt to participants.
## Setting up a referral program
Go to **Marketing** → **Referrals** and click **Create referral program**.
Give the program a **name** (internal) and optional **description**. If you have multiple brand themes set up on your account, pick one from the **Theme** dropdown — it controls how referral emails and landing pages are styled.
Set the **status** to **Active** when you're ready for participants to start earning, or leave it as **Draft** while you configure it.
Select how referrers earn their reward:
* **Rolling** — the referrer earns a fixed reward for every qualifying referral they make. One rule, repeated per referral.
* **Milestone** — the referrer earns increasing rewards as they hit referral thresholds. You can add multiple rules to build a tiered ladder (e.g. 5 referrals earns \$25, 10 referrals earns \$60).
For each rule, enter the **reward amount**, **currency**, and **threshold** (the number of referrals needed to earn it).
For milestone programs you can add more rules with **Add another rule** to build a payout ladder. Rolling programs use a single rule applied per referral.
Toggle on **Enable discount** to give referred participants a discount when they check out. Choose either a **percentage** or a **flat rate** off their order.
This is separate from the referrer's reward — it's an incentive for the new participant to complete their booking.
Under **Refund**, pick a **refund date**. On this date, all earned rewards are processed in bulk and refunded directly to referrers' original payment methods — no action needed from you on the day.
We recommend setting this to a date after your event has taken place. This ensures all eligible referrals are counted and gives time for any cancelled or refunded entries to be resolved before payouts run — a referral is only valid once the referred participant's booking is confirmed and settled.
By default the program applies to all your events. Use the event picker under **Availability** to include only specific event occurrences.
## Participant referral experience
After checkout, the booking confirmation page shows a referral block
inviting them to share their personal referral link.
They copy the link and share it however they like — message, social media,
email. The link is tied to their account.
The friend lands on a referral page showing who referred them. If you've
configured a friend discount, it's applied automatically at checkout.
Once the friend's booking is confirmed, the referrer's reward total is
updated. They receive an email notification at each milestone or rolling
interval they reach.
On the date you set, all earned rewards are refunded to referrers in bulk.
Each referrer receives a confirmation email when their funds are sent.
## Emails participants receive
The platform sends three types of email to referrers automatically — you don't need to configure them.
| Email | When it's sent |
| - | - |
| **Milestone reached** | When a referrer hits a new milestone threshold (milestone programs only). Shows their updated reward total, the new tier, and the payout date. |
| **Referral reward earned** | When a referrer completes another qualifying interval (rolling programs only). Shows their accumulated reward total and the payout date. |
| **Funds sent** | After the bulk payout runs and their reward has been processed. Confirms the amount they received. |
All emails are branded using the theme you selected for the program.
## Program statuses
| Status | Meaning |
| - | - |
| **Draft** | Configured but not yet live. Participants don't see the referral prompt. |
| **Active** | Live. Participants earn rewards for qualifying referrals. |
| **Paused** | Temporarily suspended. No new rewards are earned while paused. |
| **Completed** | Payout has run and the program is closed. |
| **Cancelled** | Ended without payout. |
## Hidden referral prompts
The referral block is not shown to a participant if:
* The highest ticket price for the event is 10 or less in the event's currency.
* The participant is editing an existing booking rather than making a new one.
* The booking was made with a reservation code.
In these situations no error is shown — the referral block is omitted from the confirmation page.
# Sales Options
Source: https://partner-help.letsdothis.com/docs/event-setup/sales-options
The event-level settings that control how your tickets sell — combining tickets in one basket, bulk discounts, payment plans, and day-of purchases.
Sales options is the section of your event setup that controls how your tickets sell. These settings apply at the **event level** (not per ticket) and govern how participants can combine and pay for tickets. Turning each one on changes what participants can do at checkout.
This page explains what each option does and when to use it. Two of them — Bulk Buy and Payment Plans — have their own detailed pages, linked below.
## Sales option use cases
Use Sales options to set rules for the whole basket, not an individual ticket. The section groups four controls:
Let participants buy more than one ticket type — or tickets to your other
events — in a single transaction.
Automatically discount larger orders, using the tiers you set in your Bulk
Buy settings.
Let participants spread the cost across monthly installments.
Keep tickets on sale right up until the race starts.
## Multibuy
**Multibuy** controls whether a basket can hold more than one ticket *type*. Even with it off, a participant can buy several of the same ticket — five 10K entries, for example. With it on, they can mix types in one transaction — five 10K entries *and* five 5K entries — or add tickets to your other events.
When Multibuy is on, a second control appears — **What ticket combinations can customers add to their basket?** — which sets whether participants can only combine tickets within this event, or also add tickets from your other events.
When a basket can hold tickets to more than one race at the same event,
participants are warned that those races may be happening at the same time.
Turn Multibuy on for events where people naturally book together — a family entering different distances, or someone adding a ticket to another of your events. Leave it off if each participant should only ever buy one ticket type at a time.
## Bulk Buy discounts
**Bulk Buy discounts** apply an automatic discount to larger orders. Participants get a discount when they buy multiple tickets, based on the tiers you configure.
This toggle only appears if Bulk Buy is enabled on your organizer account. If
you don't see it and want to offer bulk discounts, contact your Let's Do This
account manager.
The discount tiers themselves (how many tickets earn what discount) are set separately — see [Bulk Buy Discount](/docs/event-setup/bulk-buy-discount) for how to configure them and what participants see.
## Payment Plans
**Enable Payment Plans** lets participants split the cost of an event into monthly installments instead of paying in full. Once it's on, you can opt specific tickets out from the Tickets area.
When you enable it, two settings appear:
* **Maximum number of monthly payments** — the cap on installments, between **2 and 30** (default **4**). The number a participant actually sees is calculated at checkout from the time remaining.
* **Last possible payment date** — as this date approaches, the number of monthly payments reduces to fit the time available.
Payment Plans has its own setup, participant experience, and management detail — see [Payment Plans](/docs/event-setup/payment-plans) for the full guide, including how to opt specific tickets out.
## Day-of ticket purchases
**Allow day-of ticket purchases** keeps your event on sale on the day it happens. With it off, once the event start passes the ticket selection page is no longer accessible and participants see an "Event passed" notice. With it on, tickets remain buyable on the day.
For this to apply to a given ticket, the ticket's sales window has to extend past the event start — set its **Available until** date to the day after your event, at 23:59.
## Combined setting behavior
These options are independent — you can turn on any combination. A few interactions worth knowing:
* **Multibuy and Bulk Buy** work together: bulk discounts apply across the multiple tickets a participant adds in one basket.
* **Payment Plans** can be turned off for individual tickets even when enabled at the event level — you do that on the **Tickets** tab, not here.
* **Day-of purchases** depends on each ticket's own **Available until** date, so check your ticket sales windows after enabling it.
# Shipping Addresses for Add-ons
Source: https://partner-help.letsdothis.com/docs/event-setup/shipping-addresses-for-add-ons
Collect a delivery address at checkout when a registration includes an add-on you ship to the buyer.
## Overview
Some add-ons are physical items you mail out — a race t-shirt, a medal, a
finisher pack. When an add-on is set to be shipped, checkout asks the
participant for a delivery address before they can pay. You control this with a
single **Fulfillment** setting on each add-on.
The shipping address section only appears when the basket contains at least one
add-on you've marked **Ship to buyer**. You only need one shippable add-on in
the basket to trigger the address section — a registration buying several
shippable add-ons still provides a single address, and everything for that
registration ships to the same place. If every add-on is picked up on race day
(or has no fulfillment method set), checkout never asks for an address.
The add-on is mailed out. Checkout collects one delivery address for the
registration.
The add-on is collected in person. No address is requested.
## Marking an add-on as shippable (organizers)
Each add-on has a **Fulfillment** section where you choose how it reaches the
participant.
From your event dashboard, go to the **Merch** area and open the add-on you
want to configure.
In the **Fulfillment** section, set **Fulfillment method**. The description
reads:
> Choose how this add-on will be delivered to the buyer.
Pick one of:
| Option | What it means |
| - | - |
| **Ship to buyer** | The item is mailed out. Checkout will collect a delivery address. |
| **Pick up on race day** | The item is collected in person. No address is collected. |
| **Unspecified** | No method set. No address is collected. |
Save your changes. From now on, any registration that includes this add-on
will be asked for a shipping address at checkout.
## Participant checkout experience
When a basket contains a **Ship to buyer** add-on, a **Shipping address**
section appears in the payment step, introduced with:
> Your order contains items that need to be shipped. Please confirm where to
> send all the items for this registration.
The participant first chooses who the order ships to:
* **The first participant** — shown by name, with their address pre-filled from
their registration details. This is selected by default.
* **Somewhere else** — choosing this reveals a first name, last name, address,
and (optional) phone number to fill in.
First name, last name, and a complete address are required before they can
continue. Phone is optional. The participant can't reach payment until a valid
shipping address is in place. If the address fails to save, they'll see a prompt
to try again — refreshing the checkout and re-entering usually resolves it.
# Shipping Fees and Rules
Source: https://partner-help.letsdothis.com/docs/event-setup/shipping-fees
Charge location-based shipping fees on shipped products, block destinations you don't ship to, and offer free shipping above an order value.
Shipping rules apply to products you send to participants — anything with
**Ship to buyer** as a fulfillment method. They build on [shipping
addresses](/docs/event-setup/shipping-addresses-for-add-ons): the address a
participant provides at checkout is what decides the fee they pay.
When you mail out products — t-shirts, medals, race packs — the cost of shipping
usually depends on where they're going. Shipping rules let you charge the right
fee for each destination, block destinations you can't deliver to, and offer
free shipping on larger orders.
Set up your organization defaults once and every shipped product uses them
automatically. Add product-specific rules only for exceptions — for example, a
bulky item with its own courier costs, or a race-pack mailing service that's
only available domestically. A product's own rules **replace** your defaults
entirely for that product; the two are never merged, so what you see on the
product is exactly what applies.
One set of rules and a free shipping threshold that every shipped product
without its own rules follows.
A full replacement rule set for a single product, managed on the product
itself.
## Fee calculation
When a participant's basket contains a shipped product, checkout looks at their
shipping address and applies the most specific rule that matches:
1. A rule for their **state or province** (for example, Alaska).
2. A rule for their **country** (for example, United States).
3. Your **Everywhere else** setting.
Each order pays **one shipping fee**, no matter how many shipped products it
contains. If different products in the basket match different fees, the
participant pays the **highest** matched fee once — fees are never added
together.
If any product in the basket can't ship to the address, the whole order is
blocked until the participant changes the address or removes that product.
If you've set a **free shipping threshold**, orders whose **product total** is
at or above that amount ship free — the fee is replaced by a `Free shipping` line in
the participant's order summary. Only products count toward the total; the race
entry and other charges don't.
For example, with a \$8 United States rule, a \$18 Alaska and Hawaii rule,
**Everywhere else** set to **Doesn't ship**, and a \$100 free shipping
threshold:
| Participant's situation | What they pay |
| - | - |
| Ships a t-shirt to Texas | \$8 shipping |
| Ships a t-shirt to Honolulu | \$18 shipping (the state rule wins) |
| Ships a t-shirt and a medal to Texas | \$8 shipping, charged once |
| Ships \$120 of products to Texas | Free shipping (the product total is at or above \$100) |
| A race entry and a \$20 t-shirt shipped to Texas | $8 shipping (only the $20 of products counts, not the entry) |
| Tries to ship to Canada | Blocked — must change address or remove the product |
## Setting your organization defaults
In your organizer dashboard, go to **Add-ons** → **Shipping rules**. A
summary at the top tells you at a glance what your current setup does — for
example, `Ships to 3 destinations. Everywhere else ships for $8.00.`
If you've blocked any destinations, the summary names them too, so you can
confirm your whole setup without opening the rules editor. Up to three are
listed by name; above that you get a count.
Turn on the **Organization default shipping** toggle. While it's off,
products without their own rules fall back to any flat shipping fee already
set on them, and products with their own rules keep using them.
Pick the default for shipped products that don't set their own rules:
| Setting | What it means |
| - | - |
| **Ships free** | Every destination is allowed and shipping costs nothing. |
| **Set shipping rules** | You define destinations, fees, and blocks below. |
To ship to a specific list of destinations and nowhere else, choose **Set
shipping rules**, add those destinations under **Ships to**, and set
**Everywhere else** to **Doesn't ship**.
With **Set shipping rules** selected, three sections control the outcome:
* **Ships to** — the destinations you deliver to and the fee for each. A
rule can cover one or more countries, and you can narrow it to specific
states or provinces to create overrides like Alaska and Hawaii pricing.
Naming a rule is optional — leave it blank and it's named after the
destination. A fee field left empty reads `Free`, which is how you ship
to a destination at no charge.
* **Doesn't ship to** — destinations you refuse. Block a whole country, or
add a country and use **Block only certain states** to block just part of
a country you otherwise ship to.
* **Everywhere else** — what happens for destinations not listed above:
**Ship** with a default fee, or **Doesn't ship**. Leave the default fee
blank to ship free to all other destinations.
Each destination can only appear once across your rules — if you list it
twice, you'll be asked to remove the duplicate before you can save.
Enter an amount in **Free shipping threshold**. When a participant's
**product total** reaches this amount, their order ships free. Leave it
blank for no threshold. Only products count toward the total — the race entry
and other charges don't — and products that use their own product-specific
rules still count.
Click **Save**. The button stays grayed out until you actually change
something, and grays out again once your changes are saved — so it doubles
as a check on whether you have unsaved edits.
The new rules apply to checkouts from that point on — already-completed
orders keep the fee they were charged.
## Customizing shipping for a single product
A product's own rules are a full replacement for your organization defaults,
not an addition to them. Once a product is customized, changes to your
organization defaults no longer affect it.
Go to **Add-ons** → **Products** and open the product you want to
customize.
In the **Fulfillment** section, make sure **Ship to buyer** is selected.
The **Shipping** controls only appear for shipped products, and start out
showing `Using the organization default shipping rules.`
Click **Customize for this product**, then configure the same controls as
the organization page — **Ships free** or **Set shipping rules**, with the
same destination rule editor. A banner reminds you the product is
customized.
Save the product. To go back later, click **Reset to organization
default** — this discards the product's custom rules and it follows your
organization defaults again.
If you stop shipping a customized product — by removing **Ship to buyer** from
its fulfillment methods — saving the product also removes its custom shipping
rules. You'll see a warning before this happens.
## Switching to free shipping
**What happens:** if you've built destination rules and then switch to **Ships
free** and save, those rules are cleared. You're asked to confirm first, and
canceling leaves everything as it was.
**Why:** **Ships free** means every destination ships at no charge, so there
are no per-destination fees left to keep.
**What to do:** switching between the two options *without* saving keeps your
rules, so you can look at both before committing. If you want them back after
saving, you'll need to re-enter them — so confirm only when you're sure.
## Rules with no shipping destination
**What happens:** if a product's rules list no destinations under **Ships to**
and **Everywhere else** is set to **Doesn't ship**, saving is refused — nothing
would be deliverable, so nobody could have the product shipped to them. This
applies whenever **Ship to buyer** is one of the product's fulfillment methods,
including a product that also offers **Collect on race day**.
On your organization defaults the same setup is allowed, but you're asked to
confirm it first. It's the one way to pause shipping across everything at once.
**Why:** a product that offers shipping but ships nowhere leaves participants
who choose **Ship to me** with no address that works.
**What to do:** to stop shipping one product, remove **Ship to buyer** from its
fulfillment methods, or click **Reset to organization default** — both stay
available and neither is blocked. To ship to a limited list, add those
destinations under **Ships to** and leave **Everywhere else** on **Doesn't
ship**.
Removing **Ship to buyer** stops delivery, not sales. A product that also
offers **Collect on race day** stays on sale for collection, and one with no
shipping option at all sells as normal. To take a product off sale, turn off
**Available** on it instead.
If you do pause shipping organization-wide, note that it affects more than the
products relying on your defaults: an order can't be completed at all once it
contains one of those products set to be shipped, including any products in
that order that have their own rules. Items set to **Collect on race day**
aren't affected. You're warned about this before you save.
## Offering collection or delivery on the same product
You don't need two copies of a product to offer both options. In the
product's **Fulfillment** section, select both **Ship to buyer** and **Collect
on race day**.
Participants adding the product are asked `How would you like to receive
this?` and choose between **Collect on race day** and **Ship to me**. The
shipping cost is shown next to the ship option before they decide.
* Choosing **Ship to me** adds the item to the shipping fee calculation, shows
a **Shipped** badge on the item in their basket, and checkout collects a
shipping address.
* Choosing **Collect on race day** means no shipping fee and no address for
that item, with a **Collect** badge in the basket. If nothing in the basket
ships, checkout never asks for an address at all.
## Participant checkout experience
Shipping appears as its own `Shipping` line in the order summary as soon as a
shipped product is in the basket. The fee is estimated from the address the
participant entered in their registration details, so they see a realistic
total early — before they've confirmed a shipping address. If their address
isn't known yet, the line shows `To be calculated` instead of a number.
If no shipping rules apply to the basket at all — neither your organization
defaults nor the product's own rules — there is no fee to work out, so the
`Shipping` line doesn't appear. Participants only see it once a rule actually
governs what they're buying.
On the payment step, the participant confirms who the order ships to and the
final fee is locked in. Changing the shipping address — for example, switching
from their own address to **Somewhere else** — recalculates the fee
immediately.
If the destination isn't supported, the participant sees a message — for
example, `This product ships to United States only. Choose a supported address
or remove it.` — and can't pay until they choose a supported address or remove
the product.
## Good to know
### Products that can't share one address
Every shipped item in an order goes to a single address. If a participant
combines products whose destinations don't overlap — for example, one product
that only ships within the United States and another that only ships to
Canada — no address can satisfy both, and they'll see: `These products can't
all be shipped to one address. Remove one to continue.`
**What to tell the participant:** they can buy the items in separate orders,
or remove one of them.
### Shipping fees on later orders
Each order pays its own shipping fee. The original checkout, a later product
purchase, and an edit to an existing booking are separate orders — when a later
order adds a shipped product, it's charged that destination's fee in full, even
though an earlier order already paid shipping. Shipping paid on earlier orders
is never credited or refunded automatically; if a participant feels
double-charged, customer service can help with a credit or partial refund.
Orders that ship nothing new never charge shipping: editing an already-purchased
product — for example, swapping a t-shirt size — doesn't charge shipping again,
and neither does an edit that only changes details.
### Changing the shipping address after booking
Once an order is placed, its shipping address is locked. If a participant edits
their booking, the address they already gave is shown read-only, with the note
`This is the shipping address for your order. It can't be changed after
booking.` They can't reroute the order to a new destination or move it to a
different shipping fee.
The one exception is a booking that never had a shipping address — for example,
adding a shipped product to a booking that previously had nothing to ship. There
is no address to lock, so the participant enters one for the first time and pays
that destination's shipping fee, just like a new order. The product appears in
their basket straight away; the shipping fee is added once they've entered the
address.
### Shipping fees in a different currency
Shipping fees are saved in your organization's currency automatically — you
don't choose a currency when editing rules. At checkout, they only apply when
the event is sold in that same currency. If the currencies don't match,
checkout doesn't guess or convert: participants see `Shipping is temporarily
unavailable — please contact support.` and can't complete their order.
This can happen in two ways:
* **Your organization's currency changed after the rules were saved.** The
Shipping rules page warns you — for example, `These shipping fees are in
USD, but your events use GBP.` Re-saving the page stores the rules in your
current currency. The amounts you entered are kept as-is, so check they
still make sense in the new currency.
* **An event sells in a different currency from your organization.** Shipping
rules can't price shipped products for that event, so participants can't buy
them there while shipping rules are turned on.
# Teams
Source: https://partner-help.letsdothis.com/docs/event-setup/teams
Let participants form and join teams at checkout, with controls for size, roles, and privacy.
Teams let your participants enter together — they can start a new team or join an existing one during checkout, and then manage their group from a shared team page. You configure the rules (size limits, ticket restrictions, optional roles) and participants handle the rest.
Teams is recommended for group events. At the checkout teams step, participants are prompted to think about friends or family they could enter with — which drives additional bookings you wouldn't otherwise get.
## Setting up teams
Teams are configured at the event level, under the **Teams** tab in event setup. You can create multiple team setups for the same event — for example, one for relay pairs and another for mixed groups — each with its own name, size limits, and rules.
In your event setup, go to the **Teams** tab and click **Create team setup**.
Give the setup a name for your internal use (for example `Run Relay`). This name is only visible to you in the dashboard — participants do not see it.
Enter a **Minimum team size** and a **Maximum team size**.
* If a team falls below the minimum, members see a notice on the team page prompting them to invite others.
* If a team reaches the maximum, no more participants can join.
Leave either field blank to set no limit on that end.
Under **All team members**, choose which tickets members are allowed to hold:
* **Are attending the same event** — members can hold any ticket for the event. Use this when your team program spans multiple races or categories.
* **Are attending the same race** — all members must hold a ticket in the same race category.
* **Are attending the same ticket** — all members must hold the exact same ticket type.
Toggle **Team Roles** on to define specific roles within the team (for example, Swimmer, Cyclist, Runner in a triathlon relay). Enter a role group title, then add each individual role option. Participants assign a role to themselves when joining the team at checkout.
Click **Save**. The team setup is now active and will appear to participants during checkout.
## Participant team joining
When a participant reaches the teams step in checkout, they choose one of three options:
* **Start a team** — creates a new team and makes them the team captain. They enter a name for the team.
* **Join an existing team** — shows a list of teams they can join. Public teams are visible to anyone; private teams require an invite link or code.
* **No team** — skips the teams step and books without joining a group.
If a participant was sent a reserved entry that already has a team assigned, the team is locked at checkout. They see a "You're joining \[team name]" message and cannot change it.
## Managing your team as captain
The person who created the team is its captain. The captain manages the team from the team page, which has several tabs:
* **Members** — the full list of everyone in the team.
* **Member Details** — individual member information including contact details (visible to captains and organizers).
* **Add-ons** — any team-wide add-ons available for the event.
* **Event Details** — event information for the team.
### Inviting members
From the Members tab, click **Invite** to share the team.
For **public teams**, you get a shareable link. The recipient follows the link, fills in the registration form, and pays for their entry. They'll see the team name and who's already joined.
For **private teams**, you get both a shareable link and an **invite code**. The code is an alternative for participants who find the event themselves — they enter the code at the teams step during checkout to join the right team.
### Editing team settings
Open **Settings** from the team page to update the team name. The privacy setting (public or private) can be changed here too — captains can change the name; organizers can change both the name and privacy.
* **Public** — anyone can join.
* **Private** — others must be invited to join.
When a team is set to private, the invite code is shown in the Settings panel.
### Removing a member
Click on a member's card on the Members tab to open their details, then select **Remove from team**. Before confirming, you'll see a summary of what happens depending on who paid:
* **If you paid for their place:** removing them cancels their entry to the event and removes them from the team.
* **If they paid for their own place:** they are removed from the team only and can still attend the event independently or join another team.
Removed members are not notified automatically — you'll need to let them know
yourself.
### Team size alerts
When the team reaches its maximum, a warning banner appears for members: "The maximum team size is \[N] members. You can leave or switch teams using the Edit button."
When the team falls below its minimum, a notice appears: "Let's find some teammates. The minimum team size is \[N]."
### Downloading emergency contacts
As captain, you can download a CSV of your team's emergency contacts. Click the menu (⋯) in the top-right of the Members tab and select **Emergency Contacts**.
## Organizer view
As the event organizer, you have the same team page access as a captain — you can see all members, remove participants, and edit team settings including the privacy setting. Your organizer access applies to all teams on your event.
# Ticket Price Changes
Source: https://partner-help.letsdothis.com/docs/event-setup/ticket-price-changes
Schedule a ticket to change price automatically, by date or by the number sold.
Price Changes let you sell a ticket at different prices on a schedule you set in advance — the price switches automatically, with no need to edit the ticket at the moment it should change. Use it to run an Early Bird offer, a limited-time deal, or a price that steps up as your event fills.
Set the ticket's currency and standard price first. Until a currency is set,
the price-changes controls stay locked.
## Price change use cases
Price changes work best when you want to reward early commitment or build urgency:
* **Early Bird pricing** — open at a lower price for the first few weeks or the first batch of tickets, then step up. See [Early Bird pricing](/docs/event-setup/early-bird-pricing) for why and when to run one.
* **Stepped pricing** — raise the price in stages as the event approaches.
* **Limited-time offers** — run a short promotional price with a clear end date.
A few things to keep in mind before you set them up:
* A price change is scheduled **per ticket**, in the ticket's **Pricing & availability** section. Each ticket has its own schedule.
* If a price change ends before the next one is scheduled to start, the ticket falls back to its **standard price** in the gap. To avoid an unintended jump, schedule the next change to begin immediately after the previous one ends.
* An active price change **can't be edited directly** — plan your schedule ahead of time (see [Editing a price change that is already live](#editing-a-price-change-that-is-already-live)).
## Setting up a price change
Price changes are configured on each ticket, under **Pricing & availability**.
Edit the ticket, find the **Pricing & availability** section, and select **Add a price change here**.
Enter the price for this period. The currency matches the ticket and can't be changed here.
Set it to begin **immediately** (or immediately after the previous price change ends, if you're chaining several together), or on a **specific date and time**. Times use the event's timezone.
Pick one or both ending conditions:
* **On a specific date and time.**
* **When a set number of tickets have sold** at this price.
If you set both, the price change ends as soon as the first condition is met.
The price label puts an urgency banner on the ticket — this is what nudges participants to book before the price rises, so we recommend setting one on every price change. Choose the label that fits:
| Label | Best for |
| - | - |
| **Super Early Bird** | Your first, lowest tier |
| **Early Bird** | A standard early offer |
| **Limited time offer** | A short promotional price |
| **Last chance to buy!** | The final tier before the price rises or sales close |
You can also override the ticket's **title** and **description** while this price is active — leave these blank to keep the ticket's usual wording.
Save the ticket. The price change appears as a card in the schedule, and the live one is marked as active.
## Participant experience
When a price change with a label is active, participants see the price for that period plus an urgency banner on the ticket. The banner adapts as the deadline or remaining quantity gets close — you don't configure these messages, they update on their own:
| Situation | What the banner shows |
| - | - |
| 10 or fewer left at the price | "Early Bird — only 3 left at this price!" |
| More than a week before the end date | The label on its own, e.g. "Early Bird" |
| Within the last week | "Early Bird — only 5 days left!" |
| The day before it ends | "Early Bird — ends tomorrow!" |
Participants don't visit your event page as often as you do, so most will only
ever see one or two of these variations. Each one is a call to action that
creates urgency — prompting them to book before the price rises.
If you set a title or description override, participants see that wording while the price is active. Once a tier sells out or ends, earlier tiers are grouped together and shown as already sold out, so participants can see they missed an earlier price.
## Managing a schedule of price changes
Each price change shows as a card with its own menu. You can build a full schedule — for example Super Early Bird, then Early Bird, then your standard price — by adding several changes back to back. From the menu you can:
* **Add** another price change, or **insert** one above or below an existing one.
* **Edit** an upcoming change to adjust its price, dates, or quantity.
* **End early** to stop a change before its scheduled end.
* **Delete** an upcoming change you no longer want.
To avoid the ticket dropping back to its standard price between tiers, set each change to begin immediately after the previous one ends.
## Editing a price change that is already live
You can't directly edit a price change once it's active.
**What happens:** if you try, you're told the change is in effect and can't be edited directly. To make a change, you end the current one and create a new one that becomes active immediately.
**What to do:** plan your schedule ahead of time so you rarely need to. If you do, ending a change can't be undone, so have the replacement price ready before you end the live one.
## Deleting a price change
Deleting an upcoming or past price change can't be undone. Removing a change from the middle of a schedule can leave a gap where the ticket reverts to its standard price — check the rest of your schedule still flows the way you want afterward.
## Tracking price changes
To see how your tiers are performing, use the **Price Changes** report in your dashboard. The label you choose is also used to group each change in your reports, so consistent labels make the report easier to read.
# Category Pages
Source: https://partner-help.letsdothis.com/docs/event-setup/tickets/category-pages
Guide participants to the right tickets by adding a category selection step before the standard ticket page.
Category pages add a step between your event page and the ticket page. Instead of sending every participant to your full ticket list, you first ask them to pick a category — International, Charity, Corporate, a distance, a membership status, or anything else you want to segment by. Once they choose, they land on the standard ticket selection page filtered down to just the tickets in that category.
## Category page use cases
Use a category page when the full ticket list is too broad or confusing on its own. Common cases:
* One race with several entry types (for example International, Charity, Corporate) that you want participants to self-select before seeing prices.
* Several races on one event page, where participants should pick a distance first.
* Tickets that should only be surfaced to participants who self-identify — local club members, students, or military participants.
You most likely don't need a category page if your ticket list is already short and easy to scan.
The category step is only a **filter** on your existing tickets. It doesn't change ticket prices, purchase rules, eligibility, form questions, or checkout — everything from the ticket page onward behaves the same as if the participant had landed there directly.
## Setting up category pages
Setup happens in two places under **Manage event**:
* **Details** tab — turn the feature on, write the page copy, and create your category labels.
* **Tickets** tab — assign each ticket to one or more categories.
Open the event in **Manage event**, go to the **Details** tab, and scroll to the **Category Selection** section. Turn **Enable category selection** on.
The feature is live as soon as you save. If you turn it on without adding any labels or assigning tickets, the category page will show one button per race, using the races already configured on your event — so you can enable the toggle first and refine the labels afterward.
Fill in the copy fields in the **Category Selection** section. All four fields support translations via **Add Translations**, so you can add localized copy without creating a separate event.
* **Category selection headline** — the main title shown on the page. For example, *Choose Your Registration*.
* **Category selection description** — supporting text below the headline. For example, *Select the registration that applies to you, whether you're entering from the UK, internationally, through a charity, or as part of a corporate team.*
* **Category selection heading** *(optional)* — a shorter prompt shown directly above the category buttons. Useful when the headline is more brand-led and you want a clearer instruction next to the buttons — for example, *Where do you live?*
* **Category selection subheading** *(optional)* — supporting text below the heading.
A read-only **Category Selection URL** appears at the top of the same section. Use it in marketing links when you want a campaign to send participants straight to the category page instead of the event page.
The **Category labels** section controls the buttons participants see on the category page.
Click **Add**, then enter each label exactly as you want participants to see it — for example *International Registration*, *Charity Registration*, *Corporate Registration*. You can:
* Add translations for each label.
* Use **Remove** to delete a label you no longer need.
* Reorder labels in the list — the order here is the order participants see the buttons in.
Category labels only work once tickets are assigned to them. Open the **Tickets** tab in Manage event and, for each ticket:
1. Click **Edit**.
2. Scroll to **Category group**.
3. Select one or more category labels.
4. Click **Update** and confirm the **Changes saved** dialog.
**Category group** is a multi-select field, so a ticket can belong to more than one category. A ticket assigned to multiple categories will appear whenever a participant chooses any of those categories.
Save the **Details** tab. The category page is now the default landing experience for the event's ticket flow.
## Participant experience
When category selection is enabled, participants land on the category page first. They see the headline, description, heading, and subheading you configured, along with a button for each category label. Choosing a category takes them to the standard ticket selection page, filtered to only show tickets in that category. From there, checkout works exactly as normal.
Tickets are still grouped by race on the ticket selection page. If a category contains tickets from more than one race, participants see one section per race, with only the relevant tickets inside each section.
## Good to know
### Uncategorized tickets
A ticket with no **Category group** assignment will not appear behind any of your custom category buttons. If a category button leads to an empty ticket page, it usually means no tickets have been assigned to that label yet — open the **Tickets** tab and add the label to each ticket that should appear there.
### Tickets in multiple categories
A ticket assigned to several categories appears in all of them. Participants aren't restricted from buying a ticket just because they reached it through a particular category. A ticket assigned to both *International* and *Corporate*, for example, shows up under either category page, and either group of participants can buy it.
### Race name fallback
If the category page is showing your race names rather than the labels you added, the race name fallback is in effect — the feature is enabled but no custom labels are fully in use yet. Check that:
* Category labels have been added in the **Details** tab.
* At least one ticket has each label selected in **Category group** in the **Tickets** tab.
Once tickets are assigned to your labels, the custom labels replace the race fallback automatically.
### Turning category selection off
If you turn category selection off after sharing category page links, those links continue to work — participants land on the standard ticket selection page instead of the category step, and can buy tickets through the normal checkout. Existing campaign links don't need to be updated.
### Translations
Translations are managed per field. If you translate the headline into another language, translate the description, heading, subheading, and every category label into the same language too. If some fields are translated and others aren't, participants may see a mix of languages on the category page.
The event theme is applied automatically to the category page, so its colors and fonts already match the rest of your event — you don't need to configure anything extra.
# Waitlists
Source: https://partner-help.letsdothis.com/docs/event-setup/tickets/event-create-waitlist
Add a waitlist to an event ticket so participants can join a queue when it sells out, instead of being turned away.
## Overview
A waitlist lets participants join a queue when a ticket has sold out, instead of
losing them to a "sold out" message. When a place frees up — someone cancels, or
you increase capacity — the next person in line is offered the spot. You set a
waitlist up per ticket and choose how places are handed out.
When a place opens up, the next participant gets a time-limited invitation
and has to complete their booking before it expires (24 hours by default).
Works for paid and free tickets.
When a place opens up, the next participant is booked in automatically — no
action needed from them. Only available for **free tickets**.
## Setting up a waitlist
A waitlist sits on top of a ticket that has a capacity limit. You duplicate the
ticket you want to waitlist, give it a capacity and a booking form, then turn the
waitlist on and pick a mode. When you duplicate an event, the waitlist setup is
copied across but left turned off, and any dates are shifted to line up with the
new event — re-enable the waitlist on the new event's ticket when you're ready.
From your event, go to the **Tickets** tab in the event setup area.
Click the ellipsis menu (**...**) on the ticket row and choose **Duplicate**.
Clear the title field, enter a new name, then click **Update → Save → Confirm
changes → Confirm**.
Switch to the **Capacity** tab, add a new capacity rule, choose **Ticket** as
the type, link your new ticket, and set the number of places. A waitlist only
makes sense on a ticket with a capacity — that's the limit people queue
behind.
Switch to the **Forms** tab, add a new form, give it a name, select the
ticket, enable booking, and save.
Back on the **Tickets** tab, edit the ticket and toggle **Enable Waitlist**
on. The toggle is only available once the ticket has been saved and has a
capacity set, and it is not available on Application-type tickets.
Pick **Acceptance waitlist** or **Instant waitlist**. Once the waitlist is
open, this choice is locked — switching how places are handed out midway
would be unfair to people already in the queue. Turn the waitlist off first
if you need to change the mode; turning off a live waitlist asks you to
confirm before the change takes effect.
For **Acceptance**, set:
* **Acceptance deadline** — how long each participant has to complete their
booking after receiving an invitation: **24 hours**, **48 hours**, **72
hours**, or **1 week**. The default is 24 hours.
* **Minimum tickets per application** — the fewest places a participant can
claim from a single invitation.
* **Maximum tickets per application** — the most places a participant can
claim from a single invitation.
For **Instant**, the ticket price must be **0**. Set the minimum and maximum
tickets per application.
Set **Join waitlist end date** and time — the point after which participants
can no longer join the queue. Leave blank if you want the waitlist to remain
open until you close it manually.
Set **Last possible registration date** and time — the hard deadline by
which all outstanding invitations must be completed. Any invitation still
open after this point expires automatically. Leave blank if you don't need a
fixed cutoff.
Click **Update → Save → Confirm changes → Confirm**.
## Queue behavior
* People are offered places in the order they joined the queue — first in,
first offered.
* You can move a specific person to the front of the queue from the
**Applications** view if you need to prioritize them.
* **Acceptance:** each invitation expires after the deadline you set — 24
hours, 48 hours, 72 hours, or one week (24 hours is the default). If the
participant doesn't book in time, the invitation expires and the place can be
offered to the next person.
* **Instant:** the next person is booked automatically as soon as a place opens,
so there's nothing for them — or you — to do.
# Purchase Limits & Basket Restrictions
Source: https://partner-help.letsdothis.com/docs/event-setup/tickets/purchase-limits
Control how many of a ticket each participant can buy, and require tickets to be bought together so they can’t be purchased on their own.
Purchase limits and basket restrictions control the **quantity** and **combination** of tickets a participant can buy in one registration. Purchase limits cap (or require a minimum of) a single ticket type. Basket restrictions link tickets together — useful when a ticket shouldn't be sold on its own, like a child entry that must accompany an adult. Both are set on the ticket, in its **Purchase limits** section, which manages how many of that ticket a participant can buy in one registration.
## Limit use cases
* **Purchase limits** — use a **maximum** to stop one person buying up a capped or premium ticket, and a **minimum** when a ticket is only sold in groups (for example a relay team that needs at least four entries).
* **Basket restrictions** — use **Link tickets** when a ticket can't be bought on its own and must go alongside another, such as a junior ticket that needs an accompanying adult.
Set limits to match how you actually want the ticket sold, and check them against any group sizes you expect — a minimum that's too high or a maximum that's too low will block legitimate bookings at checkout.
## Setting purchase limits
Purchase limits are the two fields at the top of the ticket's **Purchase limits** section.
Edit the ticket and find the **Purchase limits** section.
**Minimum tickets per booking** is the fewest of this ticket a participant must buy in one registration. Leave it blank (or set it to 1) for no minimum. When you set a minimum above 1, a participant has to add at least that many before they can check out.
**Maximum tickets per booking** is the most of this ticket one participant can buy in a single registration. Leave it blank for no cap (it shows as **Unlimited**). Values run from 0 up to 1,000.
Save the ticket. The limits apply immediately to new baskets.
## Participant limit experience
At ticket selection, a participant can't add more of a ticket than its **maximum**. If the ticket has a **minimum**, they must reach it before checkout will let them continue. The limits apply per registration, so the same person could place a second separate order — purchase limits cap a single basket, not a person across multiple orders.
## Linking tickets (basket restrictions)
Basket restrictions live under **Advanced settings** in the same **Purchase limits** section, where you'll find the **Basket restriction** controls. A basket restriction makes one ticket depend on another being in the basket.
In the ticket's **Purchase limits** section, open **Advanced settings** and choose **Add a cart restriction** to open the **Basket restriction** setup.
Turn on **Link tickets** to mark that this ticket can't be bought on its own. Then choose the **Mandatory additional ticket** that must be in the basket alongside it. For example, if a participant selects a Child ticket, they can't check out until at least one Adult ticket is also in the basket.
Set a **Minimum** and **Maximum** number of the linked ticket allowed for each ticket of this type — so you can require, say, one adult for every child, or cap how many of the linked ticket can be added.
You can customize the checkout message participants see when the rule isn't met (the default is "Complete your cart", up to 160 characters). A live preview updates as you type. Save when you're done.
A link only governs the basket from the perspective of the ticket it's set on.
If you want the rule enforced both ways, add the matching restriction to the
other ticket too.
## Participant basket restriction experience
When a participant has a restricted ticket in their basket without the ticket it's linked to, they can't check out. They see your cart restriction message — by default, "Complete your cart" — prompting them to add the required ticket. Once the basket satisfies the rule, with the mandatory ticket present in the right quantity, checkout continues as normal.
## Bundle limits
If you sell [bundles](/docs/event-setup/bundles), the number of times a bundle can be added to one checkout is controlled separately by the bundle's **Limit per booking** setting. That limit is configured on the bundle, not in a ticket's Purchase limits section.
# Reserved Capacities
Source: https://partner-help.letsdothis.com/docs/event-setup/tickets/reserved-capacities
Hold a ticket spot for a participant the moment they add it to their basket, so the same place can never be sold twice during a busy on-sale.
Reserved Capacities holds a ticket spot for a participant as soon as they add it to their basket, and gives them a set window to finish checkout. While the spot is held, no one else can buy it. If the participant completes their registration, the spot is theirs; if they leave or run out of time, it goes back into the pool for the next person. A "spot" here comes out of the **capacity** you set on a ticket — the total number of places you make available for that ticket type.
This stops the on-sale problem where two people both reach the payment screen for your last remaining place and only one can actually be charged. Each participant gets a time-boxed window to complete their purchase.
Reserved Capacities is on automatically for every organizer — there is no
switch to flip in your dashboard. The capacity you set on each ticket is what
gets held; the holding and timing behavior described below then happens
automatically at checkout. It covers ticket spots by default — see [Add-on
availability](#add-on-availability) below for how add-ons in the same basket
are typically handled.
## Reserved capacity use cases
Reserved Capacities matters most when demand is likely to outpace supply in a short window:
* **High-demand on-sales** where many participants hit checkout at the same moment and your ticket capacity is limited.
* **Events with strict capacity caps** — sold-out races, capped waves, or limited premium tickets — where overselling is not an option.
* **Reserved entry allocations**, where a fixed number of places are set aside and must not be double-sold.
For a low-demand event with plenty of capacity, participants will rarely notice the feature at all — spots are held in the background and there is almost never contention for the last place.
## Participant experience
The whole flow is automatic for the participant. There is nothing for them to turn on.
The moment a participant adds tickets and moves into checkout, those spots
are reserved for them. The places are taken out of general availability
straight away, so no one else can claim them while this participant is
filling in their details.
A banner at the top of checkout reads `Time to complete registration` with a
countdown timer (for example, `9:30`). It starts at **10 minutes** and
counts down while the participant works through checkout. This is their
window to finish before the held spots are released.
When 30 seconds of the countdown remain, a pop-up warns the participant that
their session is about to expire due to inactivity. They can click **I'm
still here** to keep their spots and carry on. This adds **5 more minutes**
to the timer.
If the participant doesn't act in time, the message
`Allocated time for checkout has expired, we are redirecting you to the start
of the flow` appears and they are sent back to the ticket selection screen.
Their held spots return to the pool for other participants, and they can
start again if tickets are still available.
## Good to know
### One-time extension
The **I'm still here** button can only be used once per checkout. After a participant takes the one extension, the warning will not appear again — when the extended timer runs out, their spots are released and they are returned to ticket selection.
**What to tell a participant:** if they need more time, they should use the extension deliberately and then complete their details promptly. If they were sent back to the start, nothing was charged — they need to add their tickets again and finish within the window.
### Tickets held in other baskets
While other participants have spots held, your remaining capacity reflects what is actually still available. If every remaining place for a ticket is currently held in someone else's basket, that ticket shows the message `Tickets are currently held in other customers' baskets. Check back soon, they may become available.` rather than letting a new participant start a checkout they couldn't complete.
This is different from `Sold out`. "Sold out" means the tickets are gone for good. "Held in other customers' baskets" means the places are temporarily reserved by people mid-checkout — if any of those checkouts aren't completed in time, the spots come back automatically.
**What to tell a participant:** ask them to check back in a few minutes. Held spots are released as soon as another participant finishes or their timer expires, so availability can reopen without you doing anything.
### Add-on availability
By default, Reserved Capacities holds ticket spots only. If a participant's basket also includes **add-ons** — merchandise or other extras purchased alongside a ticket — those items are typically not reserved the moment they're added to the basket. Availability is checked again when the participant submits their details, so someone else can still claim the last one while your participant is still filling in checkout.
If an add-on sells out before submission, the participant sees a message against that item — something like `Only 2 left` for merchandise, or `Not enough capacity` for a limited-quantity add-on — rather than the "held in other customers' baskets" message tickets show. Their ticket spot is unaffected; they just need to adjust the quantity or remove that item to continue.
**What to tell a participant:** if this happens on an add-on, it sold out to someone else while they were completing checkout — it isn't an error, and their ticket registration isn't affected. They can remove or reduce that item and resubmit.
### Completed registrations
Once a participant completes checkout and pays, their held spots are converted into confirmed places. The capacity is permanently claimed and the countdown no longer applies — there is no risk of their place being released after a successful registration.
### Reappearing places
Because abandoned and timed-out checkouts release their spots automatically, a ticket that briefly showed as held or unavailable can become available again a few minutes later. This is expected behavior, not an error. If a participant tells you a ticket "came back," it means someone else's hold expired and the place returned to the pool.
# Reserved Entries
Source: https://partner-help.letsdothis.com/docs/event-setup/tickets/reserved-entries
Set aside a block of places for a partner or for people you invite, so they can register through a code or link without buying a ticket on the open sale.
Reserved entries let you hold a block of places for specific people and invite them to register, instead of having them buy on the open sale. You group the places together, decide who they're for, and share access by a link or a unique code. This is how you handle charity places, sponsor allocations, comped entries, and ballot winners.
## Reserved entry use cases
Reserved entries fit any situation where places go to people outside the normal sale:
* **Partner and charity allocations** — give a charity or corporate sponsor a block of places, and optionally their own dashboard to manage them.
* **Invited or comped entries** — invite named people (VIPs, winners, guests) to register, with or without a discount.
* **Ballot and application outcomes** — allocate places to successful entrants of a draw.
Before you start, decide who manages the group and how people claim their place:
The partner gets their own dashboard to manage their entries, track fill
rates, copy links, and cancel places.
You send out the link and handle any changes or cancellations yourself.
One link anyone can use to claim a place, until the group is full.
Each person gets their own link, tied to their email address.
## Creating a reserved entry group
From your event, go to **Startlist → Entries → Reserved**, then choose **Create Entries**. The form is split into sections; required fields are marked with an asterisk.
Pick **Assign to a partner** or **Fill the entries yourself**, then continue.
If you're assigning the group to a partner, select an existing **Partner** or use **Add new partner** to enter their details. Skip this if you're filling the entries yourself.
Under **Group**, give the group a name and an optional description so partners and recipients know what it's for.
Under **Capacity**, set how many places the group can grant, and whether to reserve them from your event's overall capacity. Reserving from overall capacity keeps your total numbers correct; not reserving adds these places on top.
Under **Tickets**, choose which tickets the group can claim and how many of each. You can set a per-ticket cap within the group's total.
You can include tickets that are closed or off sale on your main
registration path. Reserved entries can grant access to tickets the public
can no longer book — see [Making a ticket reserved-entry
only](#making-a-ticket-reserved-entry-only).
Under **Pricing**, apply a percentage or flat discount to the selected tickets (you can include fees). Use this for charity or comped places, or leave it off for full-price invited entries.
Under **Set ticket dates**, optionally set a start and end window so the group can only claim tickets during a set period.
Under **Invitation restrictions**, optionally restrict claims by email — an exact address, or an "ends with" rule such as a single company domain.
If you assigned the group to a partner, choose under **Partner Settings** whether they can cancel entries, and whether a canceled entry is automatically reallocated as a fresh place.
Save the group. For a shared-link group, a unique link appears with a **Copy** button so you can share it.
## Sharing access and allocating places
How people claim depends on the group type.
**Shared invite link** — share one link, using **Copy invite link** from the group's menu. Anyone with the link can claim a place until the group is full, subject to any invitation restrictions. The link carries the recipient straight into checkout, where the discount (or free place) is applied automatically.
**Individual allocations** — assign places to named people with **Allocate** from the group's menu:
Upload a CSV of recipients. It must include three columns titled exactly **firstName**, **lastName**, and **emailAddress** so each person can be matched.
Email each person their unique link. You can send a test to yourself first to preview it, then track who's booked from your dashboard. To chase everyone who hasn't registered yet, see [Resending invitations in bulk](#resending-invitations-in-bulk).
Each allocation is tied to the recipient's **email address**. When they open
their link, they confirm that email before they can claim — so they need to
use the exact address you uploaded.
For a partner group, you can also **Copy link to Partner dashboard** to let the partner manage their block, and **Send claim email to partner** to email it to them.
## Resending invitations in bulk
People lose invitation emails, or never open them in the first place. Instead of chasing them one at a time, you can email everyone in a group who still hasn't registered in a single action. It's most useful as a reminder in the weeks before your claim window closes, when a group is sitting part-filled.
From the group, choose **Modify → Resend all invites**.
This applies to **every unclaimed entry in the group** — not only the rows you've selected, and not only the people shown on the current page. Before anything is sent, you'll see how many people it covers, for example `Invitation emails will be sent to 42 participants who have not completed their entry.`
This includes people who have never been sent an invitation yet — not only
those you're reminding for a second time. If you've deliberately held some
invitations back, sending in bulk releases them.
Confirm with the send button, which shows the number of invites going out. The invitations are queued and sent shortly afterward, and you'll get a confirmation of how many were queued.
### Email recipients
Someone is included when they've been allocated a place but haven't finished registering — whether they've never been invited, were invited already, or opened their invitation without completing it.
Entries are left out when the place has already been claimed, or when it's been canceled, revoked, or not yet allocated to anyone. People who have completed their registration won't be emailed again.
If someone claims their place while the send is in progress, they're skipped rather than re-invited — so nobody gets a reminder for an entry they've just used.
### Entries with no email address
An allocation with no email address can't be invited, so it's skipped. You'll see how many were skipped after sending, for example `3 entries were skipped because they have no email address.`
Treat that count as information — you can't add an email address to a place that's already allocated. To get those people invited, cancel the allocation and allocate the place again with their address. If the group is set to reallocate on cancellation, the freed place reappears in the table ready to assign; see [Canceling and reallocating an entry](#canceling-and-reallocating-an-entry).
### Fully claimed groups
If everyone in the group has already registered, there's nobody to email and the send button is unavailable. That's the expected state for a group that has filled.
### Failed sends
If you see `Error sending invitations`, nothing further is queued — try again. Anyone who already received an invitation in an earlier attempt is safe to resend to; they'll get the reminder again.
## Recipient claim experience
Recipients on a **shared link** go straight to checkout, with the discount already applied, and register as normal.
Recipients on an **individual allocation** first confirm the email address their invitation was sent to. If it matches, they continue to checkout; if it doesn't, they're asked to check they're using the same address from the invitation.
If a place can't be claimed, the recipient sees a **Sold out** screen instead of checkout. The usual reasons are that the group is full, the claim window has closed or the allocation has expired, the email doesn't meet the group's restrictions, or the ticket is no longer available to the group.
If a recipient is stuck, ask them to use the exact email the invitation was
sent to, and check whether the group is full or the claim window has passed. A
**Sold out** screen means the place is no longer available through that link.
## Canceling and reallocating an entry
When you cancel an allocated entry, you can choose whether to email the participant about it. If the group reallocates on cancellation, a replacement place appears in the table for you to assign to someone else, so a freed-up place isn't wasted.
## Making a ticket reserved-entry only
A common setup is to give reserved entries access to a ticket the public can't book. The cleanest way is to take that ticket **off sale on the main registration path** — set its **Available until** date to before your public on-sale (or in the past). The ticket then disappears from the normal flow, but reserved entry recipients can still claim it through their link.
There's also a **Require invitation link** setting on the ticket. It keeps the
ticket **visible** in the normal flow but not bookable without an invitation
link — so participants can see a ticket they can't book, which is often
confusing. In most cases, taking the ticket off sale by its **Available
until** date is the better option.
## Group fill tracking
The Reserved Entries table shows each group's **Total** and **Registered** counts, with a search box and an event occurrence filter. For a fuller view across groups, partners, and events, use the **Reserved Entry Performance** report — see [Reserved Entry Reporting](/docs/reports/reserved-entry-reporting).
# Connecting Stripe
Source: https://partner-help.letsdothis.com/docs/getting-started/connecting-stripe
How to connect your Stripe account to Let's Do This so that registration payments are deposited into your bank account.
You need to connect a Stripe account before you can receive payments from
registrations. Events can go live without a connected Stripe account, but
payouts will not be processed until the connection is complete.
Let's Do This uses Stripe to process payments and send the money to you. When a participant checks out, the funds flow through Stripe and are deposited into the bank account linked to your Stripe account. The Let's Do This team connects your Stripe account to your events once the authorization is complete.
## Payment flow
When a participant completes checkout, the payment is collected by Let's Do This via Stripe. Funds are paid out to your Stripe account on a rolling basis, typically within a few business days depending on your Stripe payout schedule. Let's Do This applies its platform fee before the remaining amount is sent to you.
## Connecting your Stripe account
Let's Do This will send you a Stripe connection link. The link is specific to your account's currency, so use the one sent to you rather than navigating there directly.
Click the Stripe connection link sent to you by the Let's Do This team.
You are taken to Stripe's website to complete the connection:
* **If you already have a Stripe account** — sign in to your existing Stripe account and authorize the connection to Let's Do This.
* **If you don't have a Stripe account** — Stripe will guide you through creating one. You will need to provide your business details and bank account information.
After authorizing on Stripe, you are redirected back to Let's Do This. The Let's Do This team will then apply the connected account to your events so that payments flow through correctly.
## Re-enabling Stripe
If your Stripe connection is removed or becomes inactive, contact Let's Do This support. They will send you a new connection link and re-apply the account to your events once reconnected.
## Processing fees
The platform fee charged by Let's Do This is shown in **Settings → Payments**. This section displays the fee structure applied to your account — a percentage, a fixed amount, or both. The fee is deducted from each order before the remainder is paid out to you.
You can view your processing fee breakdown in the Payments settings at any time, but the fee itself is set by Let's Do This and is not editable from the dashboard.
# Dashboard overview
Source: https://partner-help.letsdothis.com/docs/getting-started/dashboard-overview
A guide to every section of the organizer dashboard, how to navigate between them, and keyboard shortcuts for moving around quickly.
The dashboard is your control center for managing events, participants, marketing, and organization settings. The left-hand sidebar is the main navigation; it stays visible as you move between sections. Selecting an event in the **Events** list expands the sidebar to show everything available for that specific event.
## Sidebar sections
### Events
The landing page when you open the dashboard. It shows all your events as cards, with quick actions available from the **⋯** menu on each card — including **Edit event**, **View event page**, **Marketing links**, **Repeat event**, and **Make a copy**. Use the **Create new event** button at the top to start a new event.
Selecting an event opens an event-level navigation panel inside the sidebar, covering:
* **Entries** — Startlist, Reserved, and Applications (where enabled)
* **Manage event** — the event setup screens
* **Data & Insights** — per-event Analytics and Reports
* **Waves and capacity**
* **Volunteers** — Recruitment Setup and Sign-ups
* **Participant settings**
* **Transactional emails** — Event and Registration email campaigns
* **Race day** — Participant fields, Participant data upload, and Bib validation
* **Cancel or postpone**
### Data & Insights
Organization-wide analytics and reports. Contains:
* **Analytics** — charts and trends across your events
* **Reports** — exportable data tables for registrations, financials, and more
### Add-ons
Manage merchandise and other add-ons sold alongside your events:
* **Sales** — view all add-on purchases
* **Products** — create and edit the add-ons available for sale
### Marketing
Tools for driving registrations and communicating with participants:
* **Discount codes** — create and manage promo codes
* **Bulk buy discount** — configure multi-registration discounts
* **Credits** — issue and track account credits
* **Bundles** — group events into bundle offers
* **Referrals** — set up referral programs
* **Email marketing** — Email campaigns, Email templates, Audiences, and Analytics
### Customers
* **All customers** — a searchable list of everyone who has registered for your events
* **All registrations** — every registration across all events in one view
### Memberships
Set up and manage membership schemes, tiers, plans, offerings, and benefits.
### Partners
Manage your partner, charity, and sponsor relationships.
### Settings
Organization-level configuration, including Branding, Location, Integrations, Profile, Participant self-serve options, Registration email settings, and Roles and permissions.
## Keyboard shortcuts
The dashboard supports keyboard shortcuts for navigating quickly without leaving your keyboard. Most shortcuts work from any page in the dashboard.
### Opening the command bar
Press **⌘K** (Mac) or **Ctrl+K** (Windows/Linux) to open the command bar. From there you can search for events, customers, registrations, discount codes, and reports, and use navigation commands by typing.
### Navigation shortcuts
These shortcuts navigate directly to the corresponding page — no command bar needed:
| Shortcut | Destination |
| - | - |
| `h` | Home |
| `g` `e` | Events list |
| `g` `r` | Reports |
| `g` `c` | Customers |
| `g` `a` | Add-on sales |
| `g` `p` | Add-on products |
| `g` `d` | Discount codes |
| `g` `m` | Email campaigns |
| `g` `t` | Email templates |
| `c` `e` | Create a new event |
Sequential shortcuts (two-key sequences like `g` then `e`) must be pressed within half a second of each other. Shortcuts are available when you have full read access to the account; they are not available to event-restricted users.
Press **?** or open the command bar and look for **Keyboard shortcuts** to see
the full shortcut reference inside the dashboard.
# Glossary
Source: https://partner-help.letsdothis.com/docs/getting-started/glossary
Plain-English definitions for every term you will encounter while setting up and running events on Let's Do This.
This glossary covers the key terms used across the dashboard and in the rest of these docs. If you are new to the platform, start here — or use it as a quick reference when you come across an unfamiliar term elsewhere.
## A
**Add-on**
A physical or digital item sold alongside an event entry — for example, a t-shirt, medal, finisher pack, or timing chip. You create and manage add-ons under **Add-ons → Products** in the dashboard. Each add-on has a fulfillment method that determines whether participants collect it on race day or have it shipped.
**Application ticket**
A ticket type where a participant submits a request for a place rather than buying one instantly. You review and approve (or decline) each application before a place is confirmed. Application tickets require additional configuration — contact your account manager to enable them.
**Audience**
A segment of your customers you can target with an email campaign. You define an audience using filters (for example, everyone who registered for a specific event or all participants who haven't yet registered for your upcoming event). Audiences are managed under **Marketing → Email marketing**.
## B
**Basket**
The in-checkout shopping cart. When a participant selects tickets and add-ons before completing payment, those items are in their basket. Under Reserved Capacities, items in the basket are temporarily held so no one else can buy them while the participant checks out.
**Bib number**
The unique race number assigned to a participant for race day. Also called a race number or start number. Assigned after booking and scoped to a specific occurrence and race.
**Booking**
The completed record created when a participant finishes registering for an event. A booking contains one or more tickets, any add-ons purchased, and the associated payment. Each booking has a unique **Booking ID** you can use to look it up or share with LDT support. The **booking date** is when the transaction was completed. You can view all bookings for an event from its **Entries → Startlist**.
**Booker**
The person who completed the booking — they hold the account and received the confirmation email. The booker may or may not be participating in the event themselves. A single booking can cover multiple participants (for example, a group registration), but there is always one booker. In reports and exports, booker details appear as separate fields: **Booker First Name**, **Booker Last Name**, **Booker Email**, and **Booker Address**.
**Booking fee**
An optional fee charged per booking, separate from the ticket price. When configured, it appears as its own line item in the order summary at checkout and in financial reports.
**Booking form**
A custom set of questions attached to a specific ticket and presented at checkout. Use booking forms to collect information beyond the standard fields (name, email, date of birth, gender) — for example, emergency contact, club affiliation, or t-shirt size. You manage forms on the **Forms** tab of event setup.
**Bulk Buy Discount**
An automatic discount offered when a participant buys multiple tickets in a single order. You configure tiers — each tier sets a minimum quantity and the discount that unlocks at that quantity. Configured under **Marketing → Bulk buy discount**.
**Bundle**
A package of tickets from multiple events sold together at a combined price. When a participant adds all the tickets in a bundle to their basket, the bundle discount applies automatically. You create and manage bundles under **Marketing → Bundles**.
## C
**Capacity**
The total number of places available for a ticket. When all places have been sold or held, the ticket shows as sold out. You can set capacity when creating or editing a ticket, and manage available places across the event from **Waves and capacity**.
**Checkout**
The multi-step flow a participant moves through to complete a booking — selecting tickets, filling in their details, choosing add-ons, and paying. Participants reach checkout from your event page on the Let's Do This marketplace.
**Checkout branding**
The colors, logo, and fonts applied to your checkout pages and post-booking confirmation screens. You can apply your organization-wide theme or create a custom look for a specific event. Configured under **Settings → Branding** or from the event setup screen.
**Conditional fields**
Form fields that appear or hide based on a participant's answer to an earlier question in the same booking form. For example, a follow-up question only shown to participants who answered "Yes" to a prior question. Contact your account manager to set up conditional fields.
**Copy**
Creating a new, independent event using an existing event as a starting template. A copy has no historical link to the original — it starts fresh with no registrations or reviews. Use **Copy** when you want to reuse event setup for something unrelated to the original. Compare with **Renew**.
**Credit**
Account credit you issue to a participant, which they can put toward a future booking. Managed under **Marketing → Credits**.
## D
**Custom question**
A question you add to a booking form to collect event-specific information from participants at checkout — for example, club affiliation, t-shirt size, or dietary requirements. Custom questions are also called form fields in the event setup screen. In reports and data exports they appear under the label of the question you gave them. See **Booking form** and **Form field**.
**Customer**
A person who has made at least one booking through your events. Customer records are scoped to your organization — the same person can be a customer of multiple organizers on Let's Do This. View all customers under **Customers → All customers** in the dashboard.
**Data & Insights**
The reporting section of the dashboard, containing **Analytics** (charts and trends) and **Reports** (exportable data tables). Available at both organization level (all events) and per-event level.
**Deferral**
Moving a participant's entry to a future occurrence of the same event — for example, rolling over from this year's race to next year's. The original entry is canceled and a new one is created for the future occurrence.
**Discount code**
A promo code that participants enter at checkout to receive a price reduction. You set the discount amount or percentage, which tickets it applies to, and any usage limits. Each code has a unique **Discount ID** used in reports. Managed under **Marketing → Discount codes**.
**Discount tier**
A quantity threshold within a Bulk Buy Discount configuration. For example, a tier might apply a 10% discount when a participant buys 5 or more tickets. You can set multiple tiers with different thresholds and discounts.
## E
**Electronic signature**
A waiver requirement where participants must type their full name to sign. When enabled on a waiver field, the participant cannot complete checkout without entering their signature. Configured by Let's Do This — contact your account manager to enable it.
**Emergency contact**
The name and phone number of a person to contact in an emergency, collected from participants at checkout via a booking form. In reports and exports these appear as separate fields: **Emergency Contact** (name) and **Emergency Phone** (number).
**Entry**
A place at an event secured by a completed booking. Used interchangeably with "registration" or "booking" in some parts of the dashboard. Each entry has a unique **Entry ID**. The **Entries** section of your event sidebar shows the Startlist, Reserved entries, and Applications.
**Entry code**
A type of discount code that unlocks a restricted or hidden ticket — for example, a members-only allocation or a ballot place — rather than reducing the price. Participants without the code cannot see or purchase the ticket. Managed under **Marketing → Discount codes** alongside other code types.
**Event**
The top-level listing on Let's Do This — for example, "London Marathon". An event is the parent that groups all races, tickets, and occurrences together. You create and manage events from the **Events** section of the dashboard.
## F
**Fast checkout**
A toggle that shortens the checkout form for returning participants who have registered before. When enabled, returning participants skip fields already on file, speeding up re-registration. Configured per ticket in event setup.
**Form field**
A single question or input in a booking form. Supported field types include text, phone, dropdown, date, checkboxes, radio buttons, address, email, duration, and waiver. You manage form fields on the **Form fields** tab of event setup.
**Fulfillment**
How an add-on reaches the participant after purchase. The three options are **Ship to buyer** (mailed to a shipping address collected at checkout), **Pick up on race day** (collected in person at the event), and **Unspecified** (you manage delivery separately). Set per add-on product.
## G
**Gender**
A standard participant field collected at checkout. Appears as a column in registration and startlist exports.
## I
**Installment**
One of the monthly payments in a Payment Plan. The first installment is charged at checkout; subsequent installments are charged automatically on the same day each month until the plan is complete.
## L
**Line item**
A single product in an order — a ticket, add-on, booking fee, or discount. Also referred to as an **item** in some parts of the dashboard and exports. Each line item has its own price and quantity.
**Line item detail**
Additional information about a line item — for example, a size or color selection for a merchandise add-on. Also referred to as a **detail** or **variant** in exports.
**Listed**
An event that is publicly visible on the Let's Do This marketplace and discoverable via search. Compare with **Unlisted**.
## M
**Marketplace**
The Let's Do This public website where participants discover, browse, and register for events. Your event page on the marketplace is the main place participants find you before checkout.
**Membership**
A subscription scheme you can offer participants — for example, a club membership or loyalty plan with tiered benefits. Managed under **Memberships** in the dashboard sidebar.
**Minor**
A participant under 18 years old. When a waiver includes an under-18 restriction, participants registering a minor must indicate they are registering on behalf of a minor and sign as the minor's guardian.
## O
**Occurrence**
A specific dated instance of a repeating event. For example, an annual race has one occurrence per year. All bookings, capacity, and startlist entries are scoped to an occurrence, so each year's edition is managed independently. See **Repeat event**.
**Organizer**
You are the person or company that owns and manages events on Let's Do This. Your events, tickets, and bookings belong to your organizer account.
## P
**Participant**
A person who registers for and attends your event. The term used across the dashboard and these docs for the people your event is for.
**Participant address**
The postal address collected from a participant at checkout, either as a standard field or via a shipping address prompt when the basket includes an add-on set to **Ship to buyer** fulfillment.
**Participant phone**
The phone number collected from a participant at checkout via a booking form field. Appears as a column in registration exports.
**Partner**
An external organization — such as a charity, corporate sponsor, or club — associated with reserved entry allocations. Managed under **Partners** in the dashboard.
**Payment Plan**
A feature that lets participants split the cost of a ticket into interest-free monthly installments rather than paying in full at checkout. You enable Payment Plans at the event level and set the maximum number of monthly payments and a last possible payment date. See [Payment Plans](/docs/event-setup/payment-plans) for full details.
**Payout**
A transfer of funds from Let's Do This to your connected bank account, representing your earned revenue minus platform fees and any deductions. Payouts are visible in the **Financial reporting** section.
## Q
**QR code check-in**
A race-day feature that lets you scan a participant's ticket QR code to confirm their attendance. Enabled per ticket in event setup. Requires the Let's Do This race day app.
## R
**Race**
A distinct distance, wave, or category within your event. Participants choose a race when they select a ticket — for example, "Half Marathon" or "Elite Wave". The **race title** is the name shown to participants in the ticket selector and in reports. You set up races on the **Races** tab of event setup before creating tickets, as each ticket is linked to a specific race.
**Race day app**
The mobile and tablet application used at events for checking in participants by scanning their QR codes. Separate from the organizer dashboard.
**Renew**
Creating the next edition of an ongoing event — for example, this year's version of an annual race — while carrying forward historical performance data, reviews, and marketplace presence. A renewed event is linked to the original in the marketplace. Compare with **Copy**.
**Repeat event**
An event with multiple instances at different dates and times, all sharing the same setup. Instead of rebuilding your event from scratch each time, you create a repeating event and manage each occurrence (date/time) independently. Configured using **Repeat event** from the event card menu.
**Reserved Capacities**
A feature that holds a ticket the moment a participant adds it to their basket, preventing anyone else from buying it while they check out. The hold lasts about 10 minutes; participants can extend it once by 5 minutes if they need more time. See [Reserved Capacities](/docs/event-setup/tickets/reserved-capacities) for full details.
**Reserved entry**
A block of places held for a specific partner organization — such as a charity or corporate group — who commits to filling those spots. Participants in that group use a reservation code to claim their reserved places. Managed under **Partners** and visible in the **Reserved entry reporting** report.
**Role**
The permission level assigned to a team member on your account. Roles control what they can see and do in the dashboard. Available roles include **Admin**, **Editor**, **Editor (No Financials)**, **Viewer**, and **Viewer (No Financials)**, plus event-scoped variants that limit access to a single event.
## S
**Sale dates**
The window during which a ticket is available for purchase — a **sale start date** and a **sale end date**. Outside these dates, the ticket is not shown to participants at checkout. Set per ticket in event setup.
**Startlist**
The list of all participants who have completed a booking for your event. Found under **Entries → Startlist** in the event sidebar.
**Startlist entry**
The individual record for one participant in one race. A booking that covers multiple participants produces one startlist entry per participant. Startlist entries are the records used for bib assignment and race day operations.
## T
**Team**
A group of participants who register together under a shared team name. Teams have a **Team ID** and **Team Name** that appear as columns in registration reports, making it easy to identify and manage group entries.
**Ticket**
The purchasable entry a participant buys at checkout. Each ticket is linked to a specific race and has its own price, sale window, capacity, and settings. The **ticket title** is the name shown to participants at checkout; the **Ticket ID** is the unique identifier used in reports. The two ticket types are **Standard** (open purchase) and **Application** (organizer approval required).
**Theme**
The visual style — logo, colors, and fonts — applied to your checkout pages and confirmation emails. Your organization has a default theme; you can override it with a custom theme for specific events. Managed under **Settings → Branding**.
**Transactional email**
An automated email sent to a participant in response to an action — for example, a booking confirmation, a waitlist invitation, or a payment reminder. You can customize transactional emails per event under **Transactional emails** in the event sidebar.
**Transfer**
Moving a registration to a different participant, race, or event. There are three types:
* **Transfer to another race** — the participant moves to a different race within the same event (for example, switching from the 10K to the Half Marathon).
* **Transfer to another event** — the participant moves their entry to a different event entirely.
* **Transfer to a friend** — the participant passes their entry to someone else to complete checkout in their own name.
Transfers that involve an active Payment Plan are blocked until the plan is resolved.
## U
**Unlisted**
An event that is hidden from the Let's Do This marketplace and search results. Use this during setup to keep the event invisible until you are ready to go live. Toggle an event listed or unlisted from the event setup screen or the event card menu.
## V
**VAT invoice**
A monthly invoice from Let's Do This covering platform fees and applicable taxes for that period. Accessible from **Financial reporting**.
## W
**Waitlist**
A queue that lets participants register their interest when a ticket is sold out. When a place opens up (due to a cancellation or capacity increase), the next person in the queue receives an invitation to complete their booking. There are two modes:
* **Acceptance waitlist** — participants receive a time-limited invitation (24 hours, 48 hours, 72 hours, or 1 week) to claim their place. If they don't complete the booking before the deadline, the invitation passes to the next person in the queue.
* **Instant waitlist** — available for free tickets only. When a place opens, the participant is booked in automatically without needing to take any action.
See [Waitlists](/docs/event-setup/tickets/event-create-waitlist) for setup instructions.
**Waiver**
A legal agreement presented at checkout that a participant must read and acknowledge before completing their registration. Waivers are added as a field type within a booking form. You can require an electronic signature (the participant types their full name) by contacting your account manager. See [Waivers](/docs/creating-managing-events/waivers) for full details.
## Booking statuses
Every booking has a status that reflects its current state. These appear in the Startlist, registration reports, and exports.
**Confirmed**
The booking is active and the participant is registered. Payment has been completed (or the ticket is free).
**Pending**
The booking has been started but not yet completed — for example, a Payment Plan where the first installment has not yet been taken, or an application ticket awaiting approval.
**Cancelled**
The booking has been canceled by the participant or organizer. The place has been released.
**Refunded**
The booking has been canceled and a refund has been issued to the participant.
**Refunding**
A refund has been initiated and is being processed.
**Refunded to credit**
The booking has been canceled and the amount paid has been issued as account credit rather than returned to the original payment method.
**Transferred events**
The participant's entry has been transferred to a different event. The original booking on this event is closed.
**To be transferred**
The booking has been flagged for transfer but the process has not yet been completed.
**Deferred**
The participant's entry has been moved to a future occurrence of the same event. The original booking is closed; a new booking will be created for the future occurrence.
**Withdrawn**
The participant has withdrawn from the event. Similar to canceled but typically used for participant-initiated withdrawals ahead of race day.
# Two-factor authentication
Source: https://partner-help.letsdothis.com/docs/getting-started/two-factor-authentication
How to add two-factor authentication to your account for an extra layer of sign-in security.
Two-factor authentication (2FA) adds a second step to your login: after entering your password, you confirm your identity with a one-time code from an authenticator app. This means your account stays secure even if your password is ever compromised.
We recommend that every person with access to your dashboard enables 2FA — especially Admins and Editors who can make changes to events or view financial data. There is no way to recover access to your account without your authenticator if you lose it, so it's worth setting up as early as possible and encouraging your whole team to do the same.
2FA is configured per person in each person's own account settings. Each team member needs to set it up themselves — it cannot be enabled on their behalf.
## Setting up two-factor authentication
You need an authenticator app installed on your phone before you begin. Any TOTP-compatible app works, including Google Authenticator, Authy, and 1Password.
Click your profile at the bottom of the sidebar and select **Settings**.
Find the **Two-step verification** section on the Settings page and click to manage it. If you have no authenticator set up yet, you will see a prompt to add one.
A QR code appears on screen. Open your authenticator app and scan it to add the account. If your app doesn't support scanning, copy the text key shown below the QR code and enter it manually into your app.
Your authenticator app will display a six-digit code. Enter it in the **Verification code** field and click **Verify**. The code changes every 30 seconds — if it expires before you submit, just use the next one.
Once verified, two-factor authentication is active on your account. Every sign-in will prompt you for a code from your authenticator app after your password.
## Viewing and removing authenticators
To see which authenticators are registered, return to **Settings → Two-step verification**. Each authenticator is listed by the name you gave it and when it was added.
To remove an authenticator, click **Remove** next to it. Once removed, you will no longer be prompted for a second factor at sign-in. Add a new authenticator at any time by repeating the setup steps above.
## Lost authenticator access
If you lose your phone or can no longer access your authenticator app, contact Let's Do This support. They can help you regain access to your account.
# User access
Source: https://partner-help.letsdothis.com/docs/getting-started/user-access
How to invite team members to your dashboard, and what each role can see and do.
Only **Admin** users can invite new team members and change existing roles.
Roles and permissions let you give team members, contractors, or partners access to your dashboard without sharing your own login. Each person gets only the access they need. You can scope access to your entire organization or to a single event.
## Your first admin account
When Let's Do This sets up your account, the first Admin user is created as part of that process. That person can then invite others from **Settings → Roles and permissions**. If you're not sure who the Admin on your account is, contact Let's Do This support.
## Roles
Each person you invite is assigned one role. The role controls which sections of the dashboard they can see and what actions they can take.
| Role | What they can do |
| - | - |
| **Admin** | Full access — can manage events, view all financials, invite users, and change roles |
| **Editor** | Can create and edit events and view financial data, but cannot manage users |
| **Editor (No Financials)** | Same as Editor, but financial data (revenue, payouts) is hidden |
| **Viewer** | Read-only access to all sections, including financials |
| **Viewer (No Financials)** | Read-only access with financial data hidden |
Roles can also be scoped to a single event — for example, **Event Editor** or **Event Viewer (No Financials)**. Event-scoped users can manage or view that event only; org-level sections like Memberships, Settings, and account-wide reports are not available to them.
## Inviting a team member
In the sidebar, open **Settings** and select **Roles and permissions**.
Click the **Invite** button in the top-right corner of the page.
Select the role that matches the level of access you want to give. If you want to limit access to one event, choose an event-scoped role and then pick the event on the following screen.
Not sure which role to pick? Select **View role descriptions** in the invite dialog for a summary of what each role can access.
Type the email address of the person you want to invite and click **Invite**.
A unique access link is generated. Copy it and send it to the person directly — by email, Slack, or however you prefer. They use the link to claim their access and set up their account.
## Managing existing users
Only Admin users can change roles or remove access for other users.
The **Roles and permissions** page lists every person who has access to your account, along with their email address, role, and login type. From the table you can:
* Change a person's role
* Remove a person's access entirely
## Event-restricted user experience
A user with an event-scoped role (Event Editor or Event Viewer) sees only the event they were given access to. When they log in:
* The event list shows only their assigned event
* **Create new event** is visible but disabled
* Org-level sections — Settings, Memberships, and account-wide reports — are not accessible
* Attempting to reach those sections shows an access-denied message
This makes event-scoped roles a good fit for third-party timing companies, photographers, or contractors who need access to one event's startlist or data exports without seeing the rest of your account.
# British Triathlon Race Pass
Source: https://partner-help.letsdothis.com/docs/integrations/british-triathlon-race-pass
Participants entering British Triathlon-licensed events confirm their membership or purchase a one-day Race Pass at checkout.
Events licensed by British Triathlon require every participant to hold a valid
British Triathlon membership or purchase a one-day Race Pass. The checkout
handles this automatically — participants confirm their status and either enter
their membership number or purchase a pass, all within the registration flow.
## Participant checkout experience
Each participant is asked: **Are you a British Triathlon member?**
### Yes responses
The participant enters their British Triathlon membership number. The number is
validated before they can continue.
### No responses
The participant chooses which Race Pass to purchase:
| Pass | Price | Eligibility |
| - | - | - |
| Adult Race Pass | £8 | Aged 25 or over on 31 December in the year of the event |
| Children & Young Persons Race Pass | £2 | Aged 24 or under on 31 December in the year of the event |
The participant must agree to the British Triathlon Race Pass terms and
conditions before completing their purchase. The terms are linked directly in
the checkout.
## Cost and payment
Race Pass charges are collected in full at checkout. They are not spread across
installments if the participant is paying by a payment plan — the pass fee is
collected upfront regardless of how the rest of the registration fee is paid.
## Registration transfers
If a participant transfers their registration to another person, the Race Pass
transfers with it. The new participant inherits the Race Pass already attached
to that registration and does not need to pay again.
# Charity fundraising
Source: https://partner-help.letsdothis.com/docs/integrations/charity-fundraising
Connect your event to a fundraising platform so participants can set up a personal fundraising page as part of registration.
Charity fundraising integrations are configured by the Let's Do This team.
Contact your account manager to discuss enabling fundraising for your event.
Fundraising integration adds a dedicated step to your checkout where participants
can set up a personal fundraising page without leaving the registration flow. The
page is created the moment payment is confirmed and participants are sent directly
to your fundraising platform to activate and share it — all in the same session.
You can offer fundraising as an **optional extra** — participants choose whether
to fundraise — or make it **mandatory**, so participants must select a charity
and agree to fundraise before they can complete their registration. Mandatory
fundraising is commonly used for charity places.
Supported platforms include **JustGiving**, **Enthuse**, **Givestar**,
**GivenGain**, and **GoFundraise**.
## Participant checkout experience
Participants see a fundraising step between their registration details and the
payment screen.
**When fundraising is optional**, participants choose **Yes, I'd like to
fundraise** or **No, not this time**, then proceed. If they choose to fundraise,
they search for and select a charity from the platform's charity list.
**When fundraising is mandatory**, participants must select a charity and confirm
their commitment before they can continue. They cannot complete their registration
without completing this step.
## After payment — getting to the fundraising page
The fundraising page is created automatically the moment payment is confirmed.
On the confirmation screen, participants see a card prompting them to activate
their page:
How they get there depends on the platform your event uses:
* **Enthuse** — a countdown begins automatically. After 8 seconds the participant
is redirected to their new fundraising page. They can also click the button to
go immediately.
* **JustGiving and other platforms** — participants click **Activate your
fundraising page**, which opens their page on the fundraising platform in a
new tab.
The page is ready to personalize and share straight away.
## Reminder email
If a participant doesn't activate their page right away, the fundraising platform
sends them a follow-up email with a link to return and complete the activation.
This is sent by the platform directly, not by Let's Do This.
If a participant contacts you because they can't find their fundraising page,
direct them to the email they received from the fundraising platform after
registration — it contains a direct link to their page.
# ChronoTrack Live
Source: https://partner-help.letsdothis.com/docs/integrations/chronotrack-live
Sync participant registrations from your event directly to ChronoTrack in real time.
The ChronoTrack integration is available to select accounts. Contact your
account manager to enable it.
The ChronoTrack integration keeps your participant list in ChronoTrack up to date
automatically. When a participant registers or updates their registration, their
details are pushed to ChronoTrack without any manual export. You can also sync
specific fields from your custom registration questions and map each ticket type
to the corresponding ChronoTrack entry category.
## Before you start
You need an active ChronoTrack account and at least one event created in
ChronoTrack before you can configure the integration. Have your ChronoTrack event
ID ready — you'll need it during setup.
## Setting up the integration
Go to your event in the dashboard and open the **ChronoTrack** integration
page. If your account is not yet connected, click **Connect ChronoTrack** and
follow the authorization steps to link your ChronoTrack account.
Once connected, your account details appear at the top of the page.
On the **Event Mapping** tab, click **Map event** and enter your ChronoTrack
event ID. The integration will confirm the event name it found in ChronoTrack.
Once mapped, the tab shows both the name from your Let's Do This event and
the name from ChronoTrack so you can confirm they match.
Below the event mapping, map each ticket type from your Let's Do This event
to the corresponding registration option in ChronoTrack. Participants who
register with a ticket that isn't mapped are not synced.
On the **Field Mapping** tab, map answers from your custom registration
questions to ChronoTrack's custom fields. Only fields you map here are sent
to ChronoTrack; standard fields (name, date of birth, sex, and age) are
always included automatically.
On the **Sync Settings** tab, turn on **Real-time sync**. From this point,
new registrations and updates are sent to ChronoTrack automatically.
## Syncing existing registrations
After setting up the integration, use **Sync all entries** on the Sync Settings
tab to push all existing registrations to ChronoTrack. This ensures participants
who registered before you enabled the integration appear in ChronoTrack.
## Data sent to ChronoTrack
Every synced participant sends the following standard fields:
* First name and last name (trimmed and title-cased)
* Middle name
* Sex
* Date of birth and age
* External registration ID
* Registration option (your mapped ticket type)
Any custom question answers you've mapped on the Field Mapping tab are also sent,
each prefixed with `custom_` in ChronoTrack.
## Syncing an individual participant
To sync a single participant — for example, after correcting a detail — go to
**Sync Settings** > **Sync single entry**, enter the participant's registration
ID, and click **Sync**. The participant's current data is sent to ChronoTrack
immediately.
## Retrying failed syncs
If a sync attempt fails, it appears in the **Failed executions** list on the
Sync Settings tab. You can retry individual failed entries from there once the
underlying issue (such as a ChronoTrack API outage) is resolved.
## Removing the integration
To disconnect the integration for an event, go to **Sync Settings** and click
**Delete integration**. This removes the event mapping and stops all future
syncs. Participant data already sent to ChronoTrack is not affected.
# HotelPlanner
Source: https://partner-help.letsdothis.com/docs/integrations/hotelplanner
Show participants curated hotel options close to your event venue, with check-in and check-out dates pre-filled based on the event date.
The HotelPlanner integration is configured by the Let's Do This team for
eligible events. Contact your account manager to set it up for your event. By
default, the same HotelPlanner link is used across all of your events — ask
your account manager if you'd like a different link set up for a specific
event.
HotelPlanner lets participants find and book nearby hotels without leaving the
registration journey. Where the integration is active, a hotel search card
appears on your event page, on the post-purchase confirmation screen, and on
the manage booking page. Participants can browse options and book directly on
HotelPlanner in a new tab.
The integration pre-fills the search with your event's location and suggested
dates — check-in two days before the event and check-out on event day — so
participants land on relevant results immediately.
## Commission
Every hotel booked through your HotelPlanner link earns you money. You receive **50% of the commission** HotelPlanner
collects on each booking — typically around \$10 (or £8) per booking. Your
share is paid into your Stripe account on a quarterly basis.
## Hotel option visibility
### On your event page
The **Hotels & Accommodation** section appears below the event details. It
includes a short description and a **Find your room** link that opens a
pre-filtered HotelPlanner search for your venue.
### After completing a purchase
On the confirmation screen shown immediately after a successful registration, a
**Race day ready hotels** card invites participants to explore accommodation.
Clicking **Explore hotels** opens HotelPlanner in a new tab with location,
check-in, and check-out pre-filled.
### On the manage booking page
The same hotel card is shown when participants view or manage their booking,
so they can find accommodation even if they didn't book it during checkout.
### In a follow-up email
Participants may also get an email after registering, inviting them to book a
hotel through HotelPlanner. It links to the same pre-filled search as the
other placements.
## Suggested dates
The integration pre-fills HotelPlanner with:
* **Check-in** — two days before the event start date.
* **Check-out** — the event start date.
Participants can adjust these dates on HotelPlanner before completing their
booking.
# mika:timing
Source: https://partner-help.letsdothis.com/docs/integrations/mika-timing
Sync participant registrations to mika:timing and receive bib numbers back automatically.
The mika:timing integration is available to select accounts. Contact your
account manager to enable it.
The mika:timing integration keeps your participant list in mika:timing up to
date automatically. When a participant registers or updates their registration,
their details are pushed to mika:timing without any manual export. Bib numbers
assigned in mika:timing are sent back and applied to the participant's record
automatically.
## Before you start
You need a mika:timing account and a meeting created in mika:timing for your
event. Have your account and meeting details ready — your account manager will
ask for them during setup.
## Setting up the integration
Setup is per event and is handled by the Let's Do This team. Contact your
account manager with:
* Your mika:timing account details
* The mika:timing meeting for your event
* Which mika:timing race each of your ticket types maps to
Once configured, new registrations and updates sync automatically, and existing
registrations are backfilled so participants who registered before the
integration was enabled also appear in mika:timing.
## Data sent to mika:timing
Every synced participant sends the following standard fields:
* First name and last name
* Email address
* Sex
* Date of birth
* Address (street, city, state, postcode, and country)
* Phone number
Additional fields from your registration questions, such as nationality, can be
mapped during setup.
## Receiving bib numbers
When mika:timing assigns a bib number to a participant, it is sent back to
Let's Do This and appears on the participant's record without any manual
import. Updates are applied in the order they changed at the timing provider,
so an older value never overwrites a newer one.
For timing providers: the inbound message contract is documented in the Timing
section of the [API reference](/api-reference/overview).
# Advertising & analytics tracking
Source: https://partner-help.letsdothis.com/docs/integrations/pixel-tracking
Connect your advertising and analytics accounts to your Let's Do This event to measure conversions and optimize campaigns based on participant activity.
Tracking lets you connect advertising and analytics platforms — Meta, Google,
TikTok, and others — to your Let's Do This event. Once set up, tracking events
fire automatically as participants move through your event page and checkout,
giving your ad platforms the data they need to measure registrations, build
audiences, and optimize campaigns.
Most platforms track through a **pixel** — a small piece of tracking code that
runs in the participant's browser. For Meta you can also turn on the
**Conversions API**, which sends completed purchases to Meta directly from Let's
Do This rather than from the browser. See
[Meta Conversions API](#meta-conversions-api) below.
Tracking runs at two levels:
* **Organizer-wide** — fires across all your events. Useful for pixels tied to
your brand rather than a specific campaign.
* **Event-specific** — fires only for a single event. Useful when each event has
its own ad campaign or budget.
The **Tracking** tab in an event adds and edits **event-specific** pixels. Any
organizer-wide pixel you already have also appears on that tab, marked
**Global** — you can see it there, but you can't edit or delete it from inside an
event. To change an organizer-wide pixel, including adding a Conversions API
access token to it, get in touch with your Let's Do This contact.
Tracking only fires for participants who have given the appropriate consent. If a
participant declines tracking, it is suppressed for that session.
## Supported platforms
| Platform | ID format |
| - | - |
| Meta Pixel | Numeric (e.g. `123456789012345`) |
| Google Analytics 4 | `G-XXXXXXXXXX` |
| Google Ads | `AW-…` |
| TikTok Pixel | Alphanumeric (e.g. `CXXXXXXXXXXXXXXXXX`) |
| AdRoll | Pixel ID + Advertisable ID |
| SiteScout | Pixel ID |
| Programmatic Trader | Separate IDs per conversion type |
**Google Tag Manager is not supported** due to security considerations. Google
Universal Analytics (UA-…) is also not supported as it has been discontinued
by Google.
## Setting up a pixel
In your dashboard, open the event and go to **Event Setup** > **Tracking**.
You need to save your event details at least once before the Tracking tab
becomes available.
Click **Add pixel** and select the platform you want to connect.
Fill in the required IDs for the platform you selected. See the platform
notes below for where to find each ID.
Click **Save**. The pixel applies to this event only, and is now active for
future participant sessions on this event.
## Platform setup notes
### Meta Pixel
Enter your **Pixel ID** from Meta Events Manager. Two optional fields sit
underneath it — **CAPI access token** and **Test event code**. Both are covered
in [Meta Conversions API](#meta-conversions-api) below.
### Google Tag
You can enter a **GA4 Measurement ID** (`G-XXXXXXXXXX`), a **Google Ads
Conversion ID** (`AW-…`), or both — whichever you use for your campaigns. If
you run a server-side Google Tag Manager container, you can also provide a
**server-side proxy URL** to route events through your own domain.
For cross-domain tracking, make sure to include `www.` when configuring your
domain in GA4 (use `www.letsdothis.com`, not just `letsdothis.com`).
### AdRoll
Enter your **Pixel ID** and your **Advertisable ID**. Both are required.
## Meta Conversions API
The Meta Pixel reports from the participant's browser, so ad blockers, browser
privacy settings, and cookie restrictions can stop purchases reaching Meta. Every
purchase they block is a registration missing from your reporting and from the
data Meta uses to optimize your campaigns.
The **Conversions API** (often shortened to CAPI) closes that gap. When a
participant completes a purchase, Let's Do This sends it to Meta directly from
our servers, alongside the browser pixel. Because that send never touches the
participant's browser, it isn't affected by ad blockers or browser privacy
settings — so your conversion counts and match rates get closer to the real
number of registrations.
Turn it on if you run paid campaigns on Facebook or Instagram and want the most
complete conversion data you can get. There's no downside to enabling it on a
live event, and it doesn't replace your Meta Pixel — the two work together, and
you need the pixel in place for the Conversions API to add anything.
The Conversions API sends **completed purchases only**. Page views, race
selection, and checkout steps continue to come from the browser pixel alone.
### Setting up the Conversions API
In Meta Events Manager, open your pixel and go to **Settings**. Generate a
Conversions API access token and copy it.
Go to **Event Setup** > **Tracking**, find the **Meta Pixel** card, and click
**Edit**. If you haven't added your Meta Pixel yet, add it first — the
Conversions API fields appear on the same form.
Paste your token into **CAPI access token**. The field is masked, so you
won't be able to read the token back after saving.
Click **Save**. The Conversions API is now active for purchases on this
event.
Once a token is saved, the field shows `Leave blank to keep existing token`.
Leave it empty to keep the token you already have, or paste a new one to replace
it. Clearing the field does not remove the token.
**Running the same pixel on several events?** You can paste the same access
token into each of them. Tokens belong to the pixel in Meta, not to the event,
so generate one token per pixel and reuse it across every event that uses that
pixel. An event using a different pixel needs a token generated for that
pixel.
### Avoiding double-counted purchases
Every purchase is reported twice — once by the browser pixel and once by the
Conversions API. This is expected, and Meta is told which two reports belong
together so it counts the purchase only once. You don't need to change anything
in Meta Events Manager to make this work.
You may still see both a browser event and a server event listed in Meta Events
Manager. That's the two sources arriving, not two registrations.
### Data sent to Meta
For each completed purchase, Meta receives:
* The order total, currency, and your Let's Do This booking reference.
* The tickets, add-ons, and donations bought, with their individual prices and
quantities.
* Matching information about the purchaser: first name, last name, email
address, phone number, and date of birth. These personal details are converted
into a scrambled, one-way form before they leave Let's Do This — Meta uses them
to match the purchase to an account, and cannot read the original values.
* The browser and device signals Meta uses for matching, including its own
advertising cookies.
Nothing is sent for a participant who declined marketing consent — see
[Consent](#consent-and-the-conversions-api) below.
### Consent and the Conversions API
The Conversions API follows the same consent decision as the browser pixel. If a
participant declines marketing cookies in the cookie banner, their purchase is
not sent to Meta from the browser **or** from our servers. One decision covers
both, so a participant who opts out stays out.
This means enabling the Conversions API doesn't change what you can tell a
participant who asks about their data: if they declined, Meta never receives
their purchase.
### Test event code
The **Test event code** field routes this event's conversions into Meta's **Test
Events** tab so you can confirm your setup is working before you launch.
**Don't set a test event code on a live event.** While a code is set,
conversions for the event go to Meta's Test Events tab and are **excluded from
your production attribution** — your campaigns will look like they're
converting nothing. Only use it on a staging event or before you go on sale,
and clear it before your event opens for registration.
Find your code in Meta Events Manager under **Test events**. It looks like
`TEST12345`. Clear the field and save to go back to normal reporting.
### Purchase attribution across pixels
If you have both an organizer-wide Meta pixel and event-specific Meta pixels, a
single checkout is split so no purchase is counted twice:
* Each event-specific pixel receives only the part of the order for its own
event.
* Your organizer-wide pixel receives whatever is left — the events in that order
that don't have a pixel of their own. If every event in the order has its own
pixel, the organizer-wide pixel doesn't receive that purchase at all.
Most checkouts cover a single event, so this only comes into play when a
participant registers for several of your events in one go.
There's one other reporting change to expect. Before you add an access token,
a checkout containing several ticket types is reported to Meta as one purchase
per ticket type. Once the Conversions API is on, the same checkout is reported as
a **single purchase** with the tickets and add-ons itemized inside it. Your total
revenue is unchanged, but your purchase count will step down at the point you
switch it on — so compare like with like when looking at trends across that date.
### Failed sends
Server-side sends can occasionally fail — an expired or revoked access token is
the most common cause. When that happens the purchase still completes normally
and the browser pixel still reports it, so you fall back to browser-only
tracking rather than losing the conversion entirely. Checkout is never affected,
and your participant sees nothing different.
If your Meta reporting suddenly drops back to browser-only match rates, generate
a fresh access token in Meta Events Manager and paste it in again.
## Tracking events
LDT fires tracking events at key moments in the participant journey. The table
below shows each event, when it fires, and the corresponding event name on each
platform.
| LDT event | When it fires | GA4 event | Meta Pixel event | TikTok event | AdRoll event |
| - | - | - | - | - | - |
| eventView | Participant views your event page | `page_view` | `ViewContent` | `ViewContent` | `pageView` |
| raceSelectionView | Participant views the race selection page | `page_view` | `ViewContent`, `AddToCart` | `AddToCart` | `pageView` |
| bookingFormView | Participant opens the booking form | `page_view` | `ViewContent`, `InitiateCheckout` | `InitiateCheckout` | `pageView` |
| checkoutView | Participant reaches the payment step | `page_view` | `ViewContent`, `AddPaymentInfo` | `AddPaymentInfo` | `pageView` |
| bookingConfirmationView | Participant completes their registration | `page_view` | `ViewContent` | — | `pageView` |
| ticketsPurchased | Ticket purchase is confirmed | `purchase` | `Purchase` | `CompletePayment` | `purchase` |
| basketItemAdded | Item added to basket | `add_to_cart` | — | — | — |
| basketItemRemoved | Item removed from basket | `remove_from_cart` | — | — | — |
| basketUpdated | Basket contents change | `cart_updated` | — | — | — |
| membershipsPurchased | Membership purchase is confirmed | — | — | — | — |
The `ticketsPurchased` event is not emitted for ballot ticket registrations
(where the outcome is not immediate). For Meta Pixel, ballot ticket purchases
include an additional `content_category="ballot_ticket"` parameter. This
parameter is not included once the Conversions API is enabled, because
purchases are then reported at checkout level rather than per ticket type.
### Purchase event details
When a ticket purchase fires, GA4 and Google Ads receive transaction-level data
including the transaction ID, total value, currency, and an items list. Each
item in the list follows this naming pattern:
> **Event Name — Race Name — Ticket Name — TICKET**
For add-on items (clothing, parking, coaching subscriptions, etc.) the pattern is:
> **Event Name — Race Name — Ticket Name — Item Name — ITEM TYPE**
This lets you see exactly which ticket and add-on combinations are converting in
your GA4 reports.
## Editing or removing a pixel
To update a pixel, find it on the **Tracking** tab and click **Edit**. To remove
it, click **Delete**. Deleted pixels stop firing immediately.
Pixels marked **Global** are organizer-wide and can't be edited or deleted from
inside an event — contact your Let's Do This contact to change one.
# Refund Protect
Source: https://partner-help.letsdothis.com/docs/integrations/refund-protect
Give participants the option to purchase a refundable registration at checkout, so they can claim a full refund if unforeseen circumstances stop them from attending.
Refund Protect is enabled on a per-account basis. Contact your account manager
to have it set up for your events.
Refund Protect adds an optional insurance step to your checkout. Participants
who add it to their registration receive a full refund if they cannot attend due
to a covered reason — illness, injury, bereavement, redundancy, and many others
listed in the policy terms. You receive the registration fee regardless.
Offering refund protection can reduce hesitation at checkout, particularly for
higher-priced entries or events booked well in advance. You also earn a revenue
share on each policy purchased, as set out in your Event Organizer Agreement.
## Pricing
The cost of a Refund Protect policy is set dynamically by Protect Group based on
the participant's total order value — typically between 10% and 15%, varying by
event. The policy covers the full basket value, including add-ons such as
clothing, parking, and coaching subscriptions, but not donations or membership
fees. Participants see the exact price per person before they choose.
## Coverage
Refund Protect covers a wide range of unforeseen circumstances, including:
* Illness, injury, or medical emergency (participant or immediate family member)
* Bereavement
* Redundancy or involuntary loss of employment
* Jury service or being called as a witness in court
* Home emergency (fire, flood, burglary)
* Adverse weather making travel impossible
* Public transport failure
* Vehicle breakdown en route to the event
* Pre-existing medical conditions (where declared and accepted)
The full list of covered reasons and exclusions is set out in the Refund Protect
policy terms, which are linked directly in the checkout.
## Participant checkout experience
When Refund Protect is active for your event, a dedicated step appears between
the registration details and the payment screen.
Participants choose one of two options:
* **Refundable Registration with Refund Protect** — adds the protection fee to
their order. The price is shown per person. Selecting this option means the
participant accepts the Refund Protect Terms and Conditions, linked on screen.
* **No, thank you** — completes the registration without protection.
The participant must make a choice before continuing to payment; the button
stays disabled until they select an option.
The step also shows the covered reasons for a refund — illness, injury, and
many more — with a link to the full terms.
## After purchase
Once a participant has purchased Refund Protect, their manage booking page shows
a **Refundable Registration** card with a direct link to submit a refund claim
and a link to the terms and conditions.
The same information is shown if the participant edits their booking.
## Reporting on Refund Protect
Your **Transactions** and **Payouts** reports include columns for Refund Protect
income alongside your ticket revenue:
* **Refund Protect purchase amount** — the total policy fee paid by the participant.
* **Your Refund Protect income** — your revenue share of that fee.
Your **Startlist** report includes a **Refundable status** column showing which
participants purchased Refund Protect, making it easy to filter or export that
subset.
## Participant refund claims
Direct the participant to the link on their manage booking page. Claims are
handled directly by Refund Protect — you do not need to process the refund
yourself. If a claim is approved, the participant's booking will show a status
of **Refunded by Refund Protect** in your dashboard.
# Registration webhooks
Source: https://partner-help.letsdothis.com/docs/integrations/registration-webhooks
Send participant registration data to external tools and platforms the moment someone registers for your event.
Registration webhooks are enabled on a per-account basis. Contact your account
manager to have this feature enabled for your account.
Webhooks let you push registration data to other tools — email marketing platforms,
timing systems, shipping providers, or any system that accepts an HTTP request —
without manual exports or scheduled syncs. Each time a participant registers or
updates their registration, the data is sent automatically.
Set up a separate webhook for each destination you need. You can filter each one
to a specific race, ticket type, or event occurrence so only relevant registrations
are forwarded.
## Webhook behavior
When a participant completes a registration or updates their existing registration,
your webhook receives the participant's data: name, email, selected ticket, custom
question answers, and other registration details. The webhook fires once per
triggering event, in close to real time.
If your receiving endpoint is temporarily unavailable, the webhook retries
automatically. If errors persist over time, the webhook is paused to protect your
receiving system. You can re-enable it once the issue is resolved.
## Creating a webhook
In your dashboard, go to **Settings** > **Integrations** > **Webhooks** and
click **Add webhook**.
Select the type of system you're connecting:
| Type | What it connects to |
| - | - |
| URL endpoint | Any system that accepts an HTTP POST request (custom integrations, Zapier, etc.) |
| Mailchimp | Your Mailchimp audience list |
| Klaviyo | Your Klaviyo list |
| ChronoTrack | ChronoTrack timing system |
| ShipStation | ShipStation order fulfillment |
Depending on the type you selected:
* **URL endpoint** — enter the full URL that will receive the data.
* **Mailchimp** — enter your Mailchimp list ID.
* **Klaviyo** — enter your Klaviyo list ID and select your saved Klaviyo credentials.
* **ChronoTrack** and **ShipStation** — follow the prompts for the required
connection details.
Select one or both trigger events:
* **Entry created** — fires when a participant completes a new registration.
* **Entry updated** — fires when a participant updates their existing
registration (for example, changing a custom question answer or upgrading
their ticket).
By default, the webhook fires for all registrations across your event. To
narrow the scope, add filters:
* **Event occurrence** — limit to a specific date or wave.
* **Race** — limit to a specific race within the event.
* **Ticket type** — limit to a specific ticket.
Filters use OR logic: if a registration matches any one of the filters you've
set, the webhook fires. If you add no filters, the webhook fires for every
registration.
Click **Save**. The webhook is now active and will fire for new registrations
matching your configuration.
## Sending existing registrations
After you save a new webhook, it will only receive registrations going forward.
To send existing registrations to your destination, use the **Backfill** option.
This re-sends all registrations that match the webhook's filters, letting you
populate your external system from day one.
## Automatic pausing on errors
If your receiving endpoint returns repeated errors over a rolling time window,
the webhook is automatically paused to avoid sending data into a broken
destination. When this happens, the webhook's status shows **Disabled** with the
reason **High error rate**.
To resume the webhook, fix the issue on the receiving end and then re-enable it
from the webhook's settings. The webhook will pick up new registrations from the
moment you re-enable it; use **Backfill** if you need to catch up on registrations
that were missed while it was paused.
## Checking delivery history
Each webhook shows a delivery log where you can review recent executions, inspect
the data that was sent, and see the response your endpoint returned. Use this to
confirm data is arriving correctly or to diagnose delivery failures.
# Runna
Source: https://partner-help.letsdothis.com/docs/integrations/runna
Offer participants a Runna personalized training plan as an optional add-on at checkout, so they can start training for your event as soon as they register.
The Runna add-on is set up by the Let's Do This team for eligible events.
Contact your account manager to have it enabled for your organizer account.
Runna is a personalized running coaching app. When the integration is active for
your event, participants can add a Runna training subscription or free trial to
their order at checkout — alongside their registration — without visiting a
separate site.
Runna receives a notification for each participant who adds the plan, so their
subscription or trial is ready as soon as they complete registration.
## Participant checkout experience
Participants see Runna listed as an optional add-on during checkout. Depending
on which plans are enabled for your event, they may be offered:
* A **2-week free trial** — at no cost, letting them try Runna before committing.
* A **subscription plan** — 3 months, 6 months, or 12 months, at a discounted
price compared to buying directly from Runna.
Plans are shown with any applicable discount and the original full price.
Participants who don't want a Runna
plan can skip the add-on and complete their registration as normal.
## Available plans
Which plans and currencies are available depends on what your account manager
has configured for your account:
| Plan | Currency |
| - | - |
| 2-week trial | GBP, USD |
| 3-month plan | GBP, USD |
| 6-month plan | GBP, USD |
| 12-month plan | GBP, USD |
If your event attracts participants from multiple regions, your account manager
can advise on which currency options to enable.
# Timing Inbound
Source: https://partner-help.letsdothis.com/docs/integrations/timing-inbound
Choose what your timing provider can write back to an occurrence — bib numbers, check-ins, and bib-pack shipments.
You need permission to edit the event to open the **Timing Inbound** page.
There is no view-only version of the page.
Timing Inbound controls what your timing provider can send back to Let's Do
This for one **occurrence** — a specific dated edition of your event, such as
this year's race. Your timing provider can report three kinds of data:
* **Bib numbers** — the race number assigned to each participant.
* **Check-ins** — when a participant checked in, for example at bib pickup.
* **Bib-pack shipments** — when a participant's bib pack was shipped, with
carrier and tracking details.
For bib numbers and check-ins, you choose an **owner**: either Let's Do This or
your timing provider. The owner is the system allowed to set that value. Data
from a timing provider that doesn't own a value is ignored.
**When to use it:**
* Set up Timing Inbound **before your timing provider starts sending data**.
Anything they send for an occurrence you haven't configured is not applied.
* Hand bib numbers to your timing provider when they assign bibs. Keep them with
Let's Do This when you assign bibs in the dashboard, the check-in app, or by
import.
* Hand check-ins to your timing provider when they run check-in or bib pickup on
their own system. Keep check-ins with Let's Do This when your team uses the
Let's Do This check-in app.
Avoid assigning bib numbers in two places. Once your timing provider owns bib
numbers, any bib they send replaces the number currently on the participant's
record, including one you assigned in Let's Do This.
Timing Inbound works alongside the [mika:timing](/docs/integrations/mika-timing)
integration. mika:timing sends your participant list to mika:timing, and Timing
Inbound controls what comes back.
## Setting up Timing Inbound
Set up each occurrence separately.
In the dashboard, open the event occurrence, then go to **APIs +
Integrations** → **Timing Inbound**.
If the occurrence hasn't been set up yet, a **Not receiving timing data**
warning appears at the top of the page.
The **Ownership** section shows your timing provider next to **Provider**.
Mika is currently the only provider.
Next to **Bib numbers**, choose **Let's Do This** or **Timing provider
(Mika)**. The default is Let's Do This.
If you choose the timing provider, a warning appears under the field to
remind you that bibs they send will overwrite numbers assigned in Let's Do
This.
Next to **Check-in**, choose **Let's Do This** or **Timing provider
(Mika)**. The default is Let's Do This.
If you choose the timing provider, check-in times from their system are
written to participants in this occurrence.
Click **Save**. Some saves open a **Confirm timing configuration** window
that lists what will change:
* The first save for an occurrence always asks you to confirm, even if you
keep both owners set to Let's Do This.
* Handing bib numbers or check-ins to your timing provider always asks you
to confirm.
Click **Save configuration** to apply your changes, or **Cancel** to go back
without saving.
Once you save, the warning at the top of the page is replaced by a note
confirming that the occurrence accepts timing provider data.
To undo edits you haven't saved, click **Discard changes**. The page shows
**Unsaved changes** while you have edits pending.
## Data from your timing provider
| Data | When it's applied | Where you see it |
| - | - | - |
| Bib numbers | Only when your timing provider owns bibs | On the participant's record and everywhere bib numbers appear, such as the check-in app and exports |
| Check-ins | Only when your timing provider owns check-ins | On the participant's record, in check-in reports and exports |
| Bib-pack shipments | Always, once you've saved the occurrence setup | In the participant's **Raceday Info** timeline, marked as reported by your timing provider |
Your timing provider can also remove a bib number. When they do, the number is
cleared from the participant's record.
Every bib change from your timing provider is added to the participant's
**Raceday Info** timeline as made **by the timing provider**, so you can see
where a number came from.
Updates are applied in the order they changed at your timing provider. An
older value never overwrites a newer one, even if it arrives later.
## Changing ownership back
To take a value back from your timing provider, set its owner to **Let's Do
This** and click **Save**. No confirmation is needed. From then on, data your
timing provider sends for that value is ignored.
Handing ownership back doesn't undo anything already applied. Bib numbers and
check-ins your timing provider already wrote stay on participants' records
until you change them.
## Good to know
### Shipments after the first save
Shipment reports can't be turned off once you've saved Timing Inbound for an
occurrence. This is why the first save always asks you to confirm, even with
both owners set to Let's Do This.
### Data sent before setup
If your timing provider sends data for an occurrence you haven't set up, it
isn't applied and isn't held to be applied later. The **Not receiving timing
data** warning on the page tells you when this is the case. Save the setup
before your timing provider starts sending, and ask them to resend anything
they sent earlier.
### Occurrence set up under a different organizer
If an event moved to a different organizer account after Timing Inbound was set
up, saving shows **The configuration was not saved** with the message
`This occurrence is already configured under a different organiser — contact support.`
Contact Let's Do This support to fix this.
### Save errors
If a save fails, the page shows **Something went wrong**. Your changes stay on
the page, so you can click **Save** again.
If the page shows **Saved, but this page is out of date**, your changes were
saved but the page couldn't reload them. Reload the page to see the current
setup.
If the page shows **Couldn't load the timing configuration**, nothing has
changed. Reload the page to try again.
# Managing Participants
Source: https://partner-help.letsdothis.com/docs/managing-participants
View, export, and edit bookings, resend confirmation emails, and review email history for your participants.
Your dashboard has two main places to manage participants, and which one you use depends on what you need to do.
## The Startlist and the Customers tab
**The Startlist** is per-event. Open any event in your dashboard and select **Entries → Startlist** in the sidebar. It shows every participant booked for that specific event, with their entry status, ticket, and booking details. The Startlist is where you take action on individual entries — issuing refunds, initiating transfers, exporting the participant list, and more. The **Export** option sits alongside it in the same Entries section.
**The Customers tab** is organizer-wide. Select **Customers** from the sidebar to see participant data across all your events. **All customers** opens individual customer profiles — their registrations, memberships, account credits, and email history. **All registrations** gives you a flat view of every booking across all events.
If you know which event a participant is in, start from the Startlist. If you want to look up a specific person across all your events, use the Customers tab.
## Viewing bookings
**From a specific event** — open the event and go to **Entries → Startlist**. Every participant who has booked is listed with their entry status, ticket, and booking date. Click any entry to open the full booking.
**Across all events** — go to **Customers → All customers** and search by the participant's email address. Their profile shows two tables:
* **Registrations** — one row per event entry, showing the participant's name, event, race or category, booking status, and event date.
* **Memberships** — one row per membership, showing the tier, plan, policy status, membership status, and the date the membership was created.
Each registration row has two actions:
* **View startlist** — opens the event's Startlist filtered to this participant in a new tab.
* **Edit booking** — opens the booking management page in a new tab. This action requires write access to your organization.
Each membership row has a **View member account** action that opens the participant's membership management page.
## Exporting bookings
You can export a full list of participants for any event as a file — useful for race-day check-in, fulfillment, or sharing with timing providers.
In your organizer dashboard, open the event and select **Export** from the Entries section of the sidebar.
Choose the columns you want to include, then click **Export**. The file downloads to your device once it is ready.
Exports are generated on demand. For large events, the download may take a few
moments to prepare.
## Editing participant details
You can update a participant's registration details — such as form answers or emergency contact information — after they have booked.
From the event Startlist, or from the participant's profile in the Customers tab, open their booking.
On the booking management page, click **Manage**. You are prompted to enter the participant's email address to confirm their identity before making changes.
Click **Edit your registration**. The registration form opens with the participant's current answers pre-filled. Update the fields you need to change and continue.
If you need to change a field that affects the price — such as a race category — contact Let's Do This support. Price-adjusting changes require LDT to process on your behalf.
## Resending confirmation emails and receipts
If a participant did not receive their booking confirmation or payment receipt — or needs either resent to a different address — you can action this from the booking.
From the booking management page or the event Startlist, select **Resend confirmation email** or **Resend receipt email**.
By default, the email is resent to the address on the booking. To send it to a different address — for example, if the participant has changed their email — check **Send to a different email** and enter the new address.
Click **Resend email**. A confirmation message appears when it has been sent.
## Participant email history
The Customers tab gives you a full record of every email your organization has sent to a participant — confirmations, campaigns, and other notifications — so you can see what they received and when.
Go to **Customers → All customers** and search by the participant's email address.
Select any email in the list to open it. The detail panel shows:
* The campaign name.
* Delivery tracking — whether the email was delivered, opened, or had any link clicks, with timestamps for each event.
* A full preview of the email as the participant received it.
If you need to forward a specific email to an alternative address — for example, after the participant updated their email — enter the new address in the **Send to** field and confirm.
# Deferring Bookings
Source: https://partner-help.letsdothis.com/docs/managing-participants/deferring
Set up deferral on your event so participants can move their entry to a future occurrence.
Deferral lets participants move their booking to a future occurrence of your event rather than withdrawing entirely. Once you configure the rules, participants can defer themselves — no manual intervention required from you.
## Setting up deferral
Deferral is configured per event in the participant settings.
In your dashboard, open the event and select **Participant settings** from the left-hand sidebar. Find the **Deferrals** section.
Toggle deferral on. Additional configuration fields appear.
Choose whether deferral applies to **all tickets** on the event or only **specific tickets**. If you choose specific tickets, select them — each ticket group can have its own deadline, reasons, and custom message.
Enter the latest date and time by which a participant can request a deferral. After this deadline, the option is no longer available to them.
The deadline only applies to participants deferring themselves. You can still defer an entry on a participant's behalf after the deadline has passed.
Link to a page on your site that explains your deferral policy. Participants see this when they go through the deferral flow.
Add the reasons participants can choose from when they defer. At least one reason is required — participants select one as part of the deferral flow.
Write a message to show participants when they defer their entry. It replaces the standard message at the top of the deferral page. We recommend keeping it short — a word counter helps you stay within the suggested 150 words.
Save the event settings. Participants can now defer their entries up to the deadline you set.
## Participant experience
Once deferral is configured, participants see the deferral option in their booking management page. The deferral page shows your custom message if you've set one, or a standard message otherwise. They select a reason, confirm, and their entry is marked as deferred.
## Deferred entries in the Startlist
Deferred entries appear in the event Startlist with a **Deferred** status. You can filter or export by status to get a list of all deferred participants at any time.
## Deferral and payment plans
An active payment plan should be resolved before a participant defers. The plan does not carry over to the new entry. If a participant on an active plan wants to defer, contact Let's Do This support before the deferral is processed.
# Refunding a Participant
Source: https://partner-help.letsdothis.com/docs/managing-participants/refunding
Issue a full or partial cash refund, or convert a booking to account credit.
You can refund a participant directly from their booking on the event Startlist. Two options are available: a standard refund that returns money to the original payment method, or a transfer to credit that converts the booking value into account credit the participant can use toward a future booking.
If you cannot see the refund option on a booking, contact Let's Do This
support. Some accounts require LDT to process refunds on your behalf.
## Standard refund
In your dashboard, open the event and go to **Entries → Startlist**. Find the participant's entry and open their booking.
From within the booking, select **Refund**. The refund form opens showing the participant's name, event, and ticket.
Choose a reason from the dropdown. The available options are:
* Withdrawal
* Customer satisfaction
* Duplicate booking
* Event cancelled
* Application unsuccessful
* Fundraising rebate
* Merchandise
* Other
You can also add an optional note for your own records.
Select how you want to refund:
* **Refund from total** — enter the amount to refund as a number or percentage of the total. An expandable breakdown shows how the total is composed.
* **Refund by line item** — set the refund amount per individual item (ticket, add-ons) and mark each one as canceled or kept.
When refunding from total, choose what happens to the entry and any add-ons:
* **Refund and cancel** — refunds the amount and cancels the registration.
* **Refund only** — refunds the amount without canceling the entry.
If the booking includes add-ons, you also choose whether to cancel or keep them.
Click **Confirm**. A summary modal shows the total to be refunded. Click the confirmation button to process. A confirmation message appears when the refund is complete.
## Refund to account credit
Instead of refunding to the original payment method, you can convert a booking's value to account credit. The participant can apply that credit toward a future booking with your organization. This is done through the Transfers tool.
From your organizer dashboard sidebar, select **Transfers**. The transfers homepage shows the available options.
Choose **Transfer to credit**. You are prompted to select the participant's booking.
The form shows the participant's current booking details and the total paid. You can:
* Choose which add-ons to include in the credit value.
* Optionally earmark the credit for a specific future event.
* Make adjustments to the credit amount if needed.
The **Total paid** and **Total credit** are displayed so you can confirm the values before proceeding.
Click **Next** to review the summary, then confirm. The booking is canceled and the credit is added to the participant's account.
## Limitations
**Refund Protect purchases** cannot be refunded through the organizer refund tool. If a booking includes Refund Protect and the participant needs a refund, they should claim directly through their Refund Protect provider if they are eligible.
**Payment plan bookings** cannot be refunded through the standard refund tool. To refund a participant on a payment plan, contact Let's Do This support with the booking ID. See [Payment Plans](/docs/event-setup/payment-plans#refunds) for details.
**Already-refunded bookings** show a warning if the full refundable amount has already been returned. No further refund is possible on that booking.
# Transfers
Source: https://partner-help.letsdothis.com/docs/managing-participants/transfers
Move a participant to a different race or event, hand their place to someone else, or convert their booking to account credit.
Transfers let you — or your participants — move a booking rather than cancel it. Three types are available:
* **Transfer to another race or event** — move the participant to a different race within the same event, or to a different event entirely.
* **Transfer to a friend** — hand the booking to another person.
* **Transfer to credit** — convert the booking value to account credit the participant can use toward a future booking.
All three can be initiated by you on behalf of a participant, or enabled as self-serve so participants can do it themselves. We recommend enabling self-serve — it reduces the volume of transfer requests you need to handle manually.
When self-serve is enabled, participants access these options from their booking management page. They can find it by logging in to their account, opening **My bookings**, and selecting the relevant entry. The available transfer options appear based on the settings you have configured.
Bookings with an active payment plan cannot be transferred. Resolve the plan
first before initiating any transfer.
## Setting up self-serve transfers
Self-serve transfer settings live in two places:
* **Organizer level** — go to **Settings → Participant self-serve**. These are your global defaults, applied to all events unless overridden.
* **Event level** — open an event and select **Participant settings** from the left-hand sidebar. Event-level settings override the organizer defaults for that event only.
Each transfer type has its own set of options:
### Transfer to another race or event
| Setting | What it controls |
| - | - |
| **Enable** | Toggle the transfer type on or off for participants. |
| **Admin fee** | A flat fee charged to the participant when they transfer. Set the amount and currency. |
| **Fee exemption** | Waive the fee if the participant transfers to a cheaper race/event, a more expensive one, or never waive it. |
| **Cut-off time** | The deadline for participants to self-serve transfer. At the organizer level, set a relative window (e.g. 4 weeks before the event starts). At the event level, set an absolute date. |
| **Ticket rules** | (Event level only) Restrict which tickets can be transferred, and which destination races or events they can transfer to. By default all tickets transfer to all available destinations. |
| **Bypass sold-out** | Allow transfers into races or events that are otherwise sold out. |
### Transfer to a friend
| Setting | What it controls |
| - | - |
| **Enable** | Toggle friend transfers on or off. |
| **Admin fee** | A flat fee charged for the transfer. |
| **Ticket discount** | Whether the recipient gets a discount: 100% off (they pay nothing) or a discount equal to the original purchase price. |
| **Cut-off time** | The deadline for self-serve friend transfers. At the organizer level, set a relative window. At the event level, set an absolute date. |
| **Ticket rules** | (Event level only) Restrict which tickets can be transferred to a friend. |
| **Bypass sold-out** | Allow transfers even when the ticket is no longer publicly available. |
### Transfer to credit
| Setting | What it controls |
| - | - |
| **Enable** | Toggle credit transfers on or off. |
| **Admin fee** | A percentage deducted from the credit amount (e.g., a 5% fee on a $100 booking gives the participant $95 in credit). |
| **Cut-off time** | The deadline for participants to self-serve convert to credit. At the organizer level, set a relative window. At the event level, set an absolute date. |
| **Credit expiry** | How long the credit lasts: 1 week, 1 month, 2 months, 6 months, 1 year, or never. Defaults to 1 year. |
| **Event restrictions** | Limit which future events the credit can be applied to. |
## Organizer-initiated transfers
You can initiate any transfer type on behalf of a participant regardless of whether self-serve is enabled. Organizer-initiated transfers are not subject to the cut-off time or fee settings.
### Transfer to another race or event
From your organizer dashboard sidebar, select **Transfers**. The transfers homepage shows the current booking details on the right.
Choose **Transfer to event**. The event selector opens.
Search for and select the event you want to move the participant to, then choose the race and ticket tier.
If the original booking includes add-ons, select which ones should transfer. Add-ons you do not include are canceled.
A summary modal shows the original booking alongside the destination. Click **Confirm** to complete. The original booking is canceled and a new entry is created at the destination.
You can also transfer multiple participants at once by selecting several entries from the Startlist before opening the Transfers tool.
### Transfer to a friend
From your organizer dashboard sidebar, select **Transfers**, then choose **Transfer to another person**.
Type the email address of the person who will receive the booking.
Select which add-ons should transfer to the new participant. Any not included are canceled.
Click **Next**. A confirmation modal summarizes the transfer. Click **Confirm** to complete.
The original participant's booking is canceled and the recipient receives a booking confirmation.
Friend transfers are per-booking only — bulk transfers to another person are not available.
### Transfer to credit
From your organizer dashboard sidebar, select **Transfers**, then choose **Transfer to credit**.
The form shows the participant's booking and the total paid. Choose which add-ons to include, optionally earmark the credit for a specific future event, and make any credit adjustments needed.
Click **Next** to review the summary, then confirm. The booking is canceled and the credit is added to the participant's account.
# Cross-domain tracking
Source: https://partner-help.letsdothis.com/docs/marketing/cross-domain-tracking
Keep UTM attribution intact when participants visit your own website before continuing to the Let's Do This checkout, so registrations trace back to the campaigns that drove them.
In December 2025 we launched [Marketing Links](/docs/marketing/marketing-links), which guides you to create links to your event with the right UTM parameters attached. Those UTMs unlock campaign-level insights inside Nova and the Marketing analytics dashboard.
Marketing Links work best when you send traffic straight to the Let's Do This checkout. But you don't always want to do that. Often you want to send participants to your own website first, then on to your event checkout. Cross-domain tracking is what preserves attribution across that hop.
Without it, UTM parameters can be lost when a visitor moves from your domain to ours. Registrations then can't be reliably matched back to the channels or campaigns that drove them. With cross-domain tracking in place, that attribution is preserved end to end.
For example, if you create a UTM-tagged link like:
```
www.your-event.com/register?utm_source=instagram&utm_campaign=earlybird
```
The script carries `utm_source=instagram&utm_campaign=earlybird` through to the Let's Do This checkout when a visitor clicks from your site. That registration is then correctly attributed back to your Instagram early bird campaign.
## Setup requirements
* UTM-tagged links pointing to your website.
* Access to edit your website, or a web team member who can do this for you.
## Setup
Copy the script below and paste it into the `` tag of any page on your site where you send paid or organic traffic on to Let's Do This.
```html theme={null}
```
We recommend testing on a single event page first, before adding the script to the rest of the pages on your website.
The script is self-contained and fails safe. If anything goes wrong it does nothing, so your visitors are never affected.
Once the script is live, click through from a UTM-tagged link to the page
where you added the script. Confirm that the UTM parameters carry through as
you continue on to the Let's Do This checkout. Your Technical Account Manager
can help you verify this if needed.
You can now see campaign-level attribution data in your Let's Do This dashboard, and within Nova or the Marketing analytics dashboard. This data can take up to an hour to sync.
Traffic, conversions, and registrations are tagged with the relevant UTM parameters. This lets you see which campaigns and channels are driving traffic and conversions.
## Script placement
Add the script to every page on your site that links out to Let's Do This. Start with one page and validate it before rolling it out to the rest.
## Good to know
### Performance and privacy
The script has no impact on your page load times. It is lightweight and self-contained. It does not store, create, or read any cookies, and it only rewrites links that point to Let's Do This. Every other link on your page is left untouched.
### Self-service setup
Let us know and we can talk through the options. In many cases you can add the script yourself through a website builder such as WordPress or Squarespace, without developer support.
### Supported channels
The script works with any paid or organic channel, carrying through any UTM-tagged link. Whether you're running Meta Ads, Google Ads, email campaigns, or anything else, the parameters are preserved as long as they are present in your links.
### Marketing Link compatibility
You don't need both, but they work well together. If someone arrives on your site through a UTM-tagged link, for example from a paid ad, those parameters are retained all the way through to the Let's Do This checkout. If someone arrives directly with no parameters, they pick up the fallback ones you set on your Marketing Link, for example a source of website and a medium of organic.
A simple rule: use Marketing Links when you send traffic straight to Let's Do This, and use cross-domain tracking when you send traffic to your own website first. When you have both, the parameters on your Marketing Links act as a safety net for untagged traffic.
# Growing your bookings
Source: https://partner-help.letsdothis.com/docs/marketing/growing-your-bookings
Nine features you can turn on today to increase registrations, boost revenue, and improve the experience for your participants.
Let's Do This gives you a set of tools to help you grow registrations, increase revenue, and make booking easier for your participants. Whether you're running a single 10K or managing a full race series, enabling the right features can improve your results. Most take a few minutes to set up.
## 1. Bulk buy discounts
Encourage group bookings by offering a discount when multiple tickets are bought in the same transaction — for example, buy 3 tickets and get 20% off. This makes it easier for participants to bring others along. It works well for running clubs, friends, or family groups.
You can enable bulk buy discounts directly from your dashboard. See [Bulk buy discounts](/docs/event-setup/bulk-buy-discount) for setup instructions.
## 2. Multibuy
Multibuy lets participants purchase multiple tickets in one transaction. They can mix and match ticket types — for example, booking both the 5K and 10K at the same event, or signing up for your September and October races at once. This lets you cross-sell your other events and saves participants time by making a single transaction rather than several.
Using multibuy and bulk buy discounts together can uplift total ticket revenue per transaction by up to 10%.
You can enable multibuy directly from your dashboard.
## 3. Price changes
Create different price levels for your tickets that change automatically over time — no manual updates needed. For example:
* Offer a **Super Early Bird** price for the first 100 registrations.
* Run a short-time sale to create urgency.
* Add a **Last Chance** price with a clear message at checkout to drive urgency.
You can trigger price changes based on a specific date, the number of tickets sold, or both. Once set up, everything happens automatically. Urgency banners appear during checkout to encourage participants to book sooner — these banners increase conversion by 1.62% compared to no banners.
## 4. Payment plans
Payment plans let participants spread the cost of their ticket over smaller monthly payments instead of paying everything upfront. For example, a £75 ticket could become three payments of £25. This makes your event more affordable and accessible, helping people commit earlier.
Turning on payment plans has increased conversions by 7%, and the uplift is even larger for higher-priced events.
See [Payment plans](/docs/event-setup/payment-plans) for full setup instructions, including how to set a maximum number of installments and a last payment date.
## 5. Refund Protect
Refund Protect is an optional add-on participants can purchase at checkout. It lets them claim a refund if they can't attend due to illness, injury, or travel disruption — they claim directly through Refund Protect, which means fewer refund requests landing with you.
You earn 25% of the protection fee every time a participant adds Refund Protect to their booking. Turning it on grows your revenue by an average of 1%.
You can enable Refund Protect directly from your dashboard.
## 6. Bundles
Bundles let you sell multiple events together as one package, often at a special price. For example, a "3-Race Series Pass — save 20%" where participants sign up for all three events in one go. Bundles help you sell more tickets, grow your event series, and let participants register for multiple events in a single transaction.
Organizers using bundles have increased tickets sold by 4–10% within one year.
See [Bundles](/docs/event-setup/bundles) for more information. To enable bundles on your events, contact [partnersuccess@letsdothis.com](mailto:partnersuccess@letsdothis.com).
## 7. Fast Checkout
Fast Checkout shortens the booking process by collecting only essential buyer and payment information upfront — participant details can be filled in later. This is especially useful for large group bookings, where requiring full details for every participant up front slows things down.
Fast Checkout makes group bookings up to 75% faster and drives 32% higher conversion for orders of 5 or more tickets.
You can enable Fast Checkout directly from your dashboard.
## 8. Marketing opt-ins
Collecting marketing permissions from new registrations helps you build a database of past and potential participants you can re-engage year after year — without starting from scratch each time you promote a new event. Growing your list builds a base of returning participants rather than one-off customers.
You can turn this on by updating your settings in the dashboard.
## 9. Marketing emails
The marketing email feature lets you create and send emails to participants who have opted in to hear from you, directly from Let's Do This — no need to export your data to a separate platform. You can choose who to send to using audience segmentation, use pre-built templates or build from scratch, schedule your sends, and track performance including how many recipients went on to book.
You can access marketing emails from your organizer dashboard.
***
These features cover a range of goals — from boosting sign-ups with bulk discounts to increasing revenue through bundles and payment plans. Most take a few minutes to set up, and some organizers see up to 10% more revenue per transaction.
Head to your Let's Do This dashboard or reach out to the [Partner Success
team](mailto:partnersuccess@letsdothis.com) to activate these features.
# Marketing links
Source: https://partner-help.letsdothis.com/docs/marketing/marketing-links
Create UTM-tagged tracking links for each of your marketing channels so you can see which campaigns drive registrations.
Marketing links are unique URLs for your event that include UTM parameters — labels that tell your analytics which campaign, channel, and source sent each participant. You create them from the event dashboard, share them through your marketing channels, and then review performance in the analytics view.
When you first open the **Marketing Links** tab for an event, eight default links are created automatically. These cover Website, Email, Facebook, and Instagram, each pointing to both the event page and ticket selection. Events with category selection enabled also get four category selection links. You can start sharing them immediately.
## Create links with Nova
Ask Nova to create marketing links for a named event and edition. For distance-specific links, say which races or ticket groups each link should show. Nova checks the races and tickets, then asks you to confirm any unclear edition, virtual grouping, hidden tickets, or meaning of an all-distances link. You also confirm each campaign name, source, and medium before Nova saves anything.
Nova can save up to six links in one request. It returns each saved URL with an event and distance label. If some links fail, Nova names those failures and returns only the URLs that were saved. Asking again with the same details reuses saved links.
An unrestricted all-tickets link is different from a link limited to selected tickets. Hidden tickets are excluded by default. Ask to reveal them only when you intend to give people with the URL access to those tickets.
## Setting up marketing links
Marketing links are per-event and managed from the **Marketing Links** tab of your event setup screen.
In your dashboard, open the event and navigate to **Event Setup** → **Marketing Links**.
The eight default links are created the first time you visit, with four more when category selection is enabled. To copy a URL, hover over it in the **URL** column and click the copy icon.
If your event is set to unlisted, marketing links still work and are the main way participants find it. The page displays a reminder so you don't share a link to an event participants can't search for.
Click **Create campaign link** to open the link builder.
Fill in the required fields:
* **Campaign name** — a label for this campaign (for example, "Spring newsletter" or "London Marathon expo").
* **Destination** — choose **Event page** to send participants to the event listing, or **Ticket selection** to take them directly to the checkout step.
* **Source** — where the link will appear: Email, Facebook, Google, Instagram, LinkedIn, Strava, TikTok, Website, or X.
* **Medium** — the channel type: Affiliate, CPC, Display, Email, Organic, Referral, or Social.
Click **Add** to add that source and medium combination to the campaign. You can add multiple source/medium pairs to the same campaign name before confirming — useful when one campaign runs across several channels at once.
Expand **Advanced options** to access additional settings:
* **Region** — pre-selects the regional checkout for participants landing through this link. Defaults to the region matching your account country. Available regions: United Kingdom, United States, Canada, Portugal, and Slovenia.
* **Tickets to display** — limit which tickets appear on the ticket selection page for participants arriving through this link. By default, all tickets are shown.
* **Reveal hidden tickets** — makes tickets marked as hidden visible to anyone arriving through this link. Use this to share access to a hidden early-bird or invitation-only ticket type.
* **Display unavailable tickets** — shows sold-out or closed tickets alongside available ones for participants arriving through this link.
Click **Confirm** to save the campaign. The new links appear in the table immediately.
To copy a link URL, hover over the **URL** column cell and click the copy icon. To get a QR code for a link, click **View** in the **QR Code** column — you can download it as an SVG or PNG file.
## Managing the links table
The table lists all marketing links for the event. The default "General" links are pinned to the top; custom campaigns appear below, sorted newest first.
From the table toolbar you can:
* **Search** by campaign name, source, medium, or destination.
* **Toggle columns** to show or hide Campaign, Source, Medium, Destination, URL, QR Code, and Created At.
* **Export** all visible links to a CSV file — useful for sharing with your marketing team or dropping into a spreadsheet.
## Viewing campaign performance
Click **View analytics** at the top of the page to open the marketing analytics view for this event. This shows how many sessions and registrations each campaign, source, and medium generated.
## Default links and the "General" campaign
The default links are grouped under the **General** campaign. There are eight for event page and ticket selection, plus four for category selection when that step is enabled.
Default links are always pinned to the top of the table regardless of when your custom campaigns were created.
## Unlisted events
If your event is set to unlisted (not discoverable through search), marketing links are the primary way participants find and book. The page shows a notice as a reminder. The links themselves work the same way — participants who have the URL can still reach the event and complete checkout.
# Webpages
Source: https://partner-help.letsdothis.com/docs/marketing/webpages
Build and publish your own webpages for campaigns, event launches, and sponsor pages, with Nova creating the first draft.
Webpages sits under **Marketing & Comms** in the dashboard sidebar, for anyone
with an organization-wide **Admin**, **Editor**, or **Editor (No Financials)**
role. Webpages is only for building pages, so read-only roles don't have
access: an organization-wide **Viewer** or **Viewer (No Financials)** role
sees no sidebar entry, and neither do event-scoped roles such as Event Editor.
See [User access](/docs/getting-started/user-access). Building a page with
Nova needs Nova access as well — see [Getting started with
Nova](/docs/nova/getting-started-with-nova).
A webpage is a page you build and host here, with its own public address, for
anything that doesn't fit on an event page: a campaign landing spot, a
pre-launch announcement, a sponsor thank-you, or a hub linking several races.
Pages aren't tied to one event, so a single page can point at as many events as
you like.
Start with Nova rather than a blank canvas. Describe the page you want and it
builds a complete draft — structure, copy, your logo, and working registration
buttons — in one go. Editing that draft is much faster than assembling a page
block by block. Then open the editor to fine-tune anything you want to change.
Use a webpage when you need a destination you control. If all you need is a
link to an existing event, link straight to the event page instead — a webpage
adds a step for your participants without adding anything for you.
Describe the page in a chat. Nova picks a layout, writes the copy, and wires
up the registration buttons.
Drag blocks onto the canvas, change the design, set your page address
settings, and publish when you're ready.
## Building a page with Nova
Click **Marketing & Comms** in the dashboard sidebar, then **Webpages**.
The list shows every page you've built, newest change first.
Nova opens with the request already started. Tell it what the page is for.
The more detail you give, the closer the first draft will be to what you
want: which event it's for, what you want the page to say, and anything
specific such as "put the sponsor logos at the bottom."
Nova chooses the layout that fits your request — a single event with a
countdown, a set of entry options side by side, or a series of dates and
locations — and fills it in. It adds your organizer logo automatically and
builds every registration button from the event itself, so you never need
to paste a booking link.
When the draft is ready, the editor opens on it.
Nova stays available from the editor — click the Nova button in the
toolbar. Ask for changes in plain language ("make the hero headline
shorter", "add a sponsors row under the tickets") and they appear on the
canvas as it works. You don't need to reload.
You can also ask Nova to rebuild a page you already have open. Say "rebuild
this page" or "apply the countdown layout to this page" and it replaces the
draft you're looking at instead of creating a second page. If your wording
could mean either, Nova asks first.
### Nova prompt guidance
Nova can create a page, add and change blocks, rewrite copy, set your fonts,
colors, logo, and browser-tab icon, and rebuild a website you name as a page of
your own. It can also take a page down from its public address.
It cannot publish a page, delete one, change a page's address, or set a
password. You do those in the editor.
## Editing a page
Click any row in the list to open that page in the editor. Four panels run down
the left of the screen, top to bottom.
**Settings** holds the page name shown to you, the title shown in a browser tab
and in search results, password protection, search indexing, the search listing
description, the canonical address, and the image used when someone shares the
page.
**Elements** holds the blocks you drag onto the canvas. Content blocks are
**Heading**, **Paragraph**, **Label**, **Button**, **Image**, **Gallery**,
**Sponsors**, and **HTML**. Layout blocks are **Hero**, **Container**,
**Columns**, **Spacer**, and **Divider**. Two blocks pull in live event data:
**Countdown**, which counts down to an event's start, and **Tickets**, which
shows races and ticket prices and keeps them current on its own.
**Layers** lists the blocks on the page so you can find and select ones nested
inside others. Selecting a block — on the canvas or in Layers — opens its
properties, where you can edit its content, move it, duplicate it, or delete
it.
**Design** controls the whole page: heading and body fonts, page colors, corner
rounding, and your logo. **Generate a new style** restyles the page in one
step, from your saved organizer branding or from another page you've already
built. There's no style-only option for copying a website: asking Nova to build
from a website address rebuilds the content as well as the design — a new page
by default, or over the draft you have open if you ask for that. See [Building
a page with Nova](#building-a-page-with-nova).
Ordinary edits to a draft save as you work — the toolbar shows **Auto-saved**.
The toolbar also has desktop and mobile preview, undo, and redo.
## Publishing
A page is a draft until you publish it. Drafts have no public address and
nobody outside your team can reach them.
The page goes live at its public address immediately. Its status in the
list changes from **Draft** to **Live**, and its address appears in the
**URL** column.
Copy the address from the **URL** column in the list, or from **Copy URL**
in the editor's **Publish** menu. **View** in the list, and **View live
page** in the same menu, open the live page in a new tab.
Every edit you make after publishing is held as a pending change. Use
**Publish** in the toolbar to push those changes live when you're happy
with them.
## Good to know
### Editing a live page
**What happens:** once a page is live, your edits — and Nova's — stop reaching
the public page. They're saved to the page and shown to you on the canvas, but
visitors keep seeing the last published version until you publish the updates.
Password protection is the one exception: it applies to the live page as soon
as you save it.
**Why:** it means you can rework a live page without half-finished copy
appearing in front of your participants.
**What to do:** when you're happy with the page, open the **Publish** menu in
the toolbar and publish the pending changes. If you want the page down
altogether rather than updated, use **Unpublish** in the same menu — that
removes it from its public address straight away and returns it to a draft. You
can publish it again later.
### Page addresses
**What happens:** the page's public address is generated from its title plus a
short unique code. A page still called **Untitled Page** takes its address from
the title it has at publish time instead, so give it the title you want before
you publish. Once it's live under a title of your own, the address is fixed:
nothing in the editor changes it, and Nova can't change it either.
**Why:** the address is part of every link you've shared, so it doesn't
change.
**What to do:** if you need a different address, build a new page with the
title you want. If the old one is already live, unpublish it so the two don't
compete in search results.
### Deleting a live page
**What happens:** you can't delete a page while it's live. Choosing **Delete**
on a live page opens **Unpublish before deleting** rather than deleting it.
**Why:** the live page is cached at its public address, and unpublishing from
the editor is what takes it down immediately.
**What to do:** click **Open in editor**, unpublish the page there, then delete
it from the list. Deleting a draft is permanent and can't be undone.
### Password protection
**What happens:** you can require a password to view a page from
**Settings > Password Protection** in the editor. Visitors then have to enter
it before the page loads. Nova can't set, change, or remove a page password.
Password changes don't wait for a publish. Setting, changing, or removing one
on a live page takes effect straight away, so visitors are locked out — or let
in — the moment you save it.
**Why:** the password is a credential, so it can only be set in the editor.
**What to tell participants:** if you've protected a page, send the password
with the link — there's no way for a visitor to request it from the page
itself.
### Registration buttons
**What happens:** when a button or hero registers people for an event, the
destination is built from the event you picked, not from a link you type.
**Why:** it means a button can't point at the wrong event or a stale link.
**What to watch for:** if the event is unlisted it has no public event page, so
a link to it shows visitors an error. The editor warns you when you choose one
— link to the ticket page instead. If you want a button to go somewhere else
entirely, such as your own website, enter that address yourself under **Other**.
One exception: when Nova builds a page from a website address, the button it
copies from that site arrives with its label but no destination — the original
site's destination isn't copied, so your visitors aren't sent to another
site's booking flow. Tell Nova which event it
should link to, or set the destination in the editor, before you publish.
### Text formatting
**What happens:** clicking into a heading, paragraph, or label gives you bold,
italic, and underline only. Size and color can't vary within a single line.
**Why:** the page keeps one consistent set of type styles, so it stays readable
on a phone.
**What to do:** to change size or color, select the block and set its text size
and color in the properties panel — that styles the whole block. If you ask
Nova to rewrite a block's wording, any bold or italic you applied to the old
words is cleared, so re-apply it after.
### Search engine visibility
**What happens:** **Settings > Search Indexing** controls whether search
engines list the page.
**Why:** a page built for one email campaign, or a page still being reviewed
internally, usually shouldn't turn up in search results.
**What to do:** turn indexing off for pages you only want reached through a
link you've shared. You can also set the description that appears in search
listings and a canonical address if the same content lives elsewhere.
### Duplicating a page
Use **Duplicate** from a page's row in the list to copy it. The copy arrives as
a draft named after the original with `(copy)` on the end, at the top of the
list, so the original stays untouched and live. Like any draft it has no public
address to share until you publish it, and it gets its own then rather than
taking the original's. This is the quickest way to run the same page shape for
next year's event or a second location — duplicate, open, and let Nova update
the wording and the event it points at.
The copy takes what the editor currently shows, so any changes you've made to a
live page but not yet published come across too. If the original was password
protected, the copy keeps the same password.
# Creating a membership
Source: https://partner-help.letsdothis.com/docs/memberships/creating-a-membership
Configure tiers, plans, pricing, and benefits for your membership program.
Your account manager creates the initial membership scheme and enables the
feature for your account. Contact them before starting setup.
Before configuring your membership, decide on the structure: how many pricing levels (tiers) you want, whether you need family or group plans, and what benefits members will receive. Changes to tiers and offerings after launch can affect existing members, so it is worth planning this upfront.
## Setting up tiers
A tier is a pricing level within your membership — for example, Standard and Premium. Each tier can carry a different price and a different set of benefits.
In your dashboard, navigate to **Memberships** and open your membership scheme.
Click **Add tier** and give it a name — for example, `Standard` or `Premium`. Add a short
description that participants will see when they are choosing a tier.
Add as many tiers as you need. Most programs work well with two or three — too many options can
slow down the purchase decision.
## Setting up plans
A plan defines the group structure of a membership — how many adults and children it covers. If you only sell individual memberships, you need one plan. For family or group memberships, create a plan for each structure you offer.
Click **Add plan** and give it a name — for example, `Individual`, `Couple`, or `Family`.
Enter the number of adults and children the plan covers. For family plans, you can also set a
maximum child age.
## Setting up offerings
An offering is the product participants actually buy — a specific combination of a tier and a plan, with a price and a purchase type. You need at least one offering before your membership can go on sale.
Click **Add offering** and select the tier and plan you want to combine.
Enter the price for this combination. Prices are set in your account's default currency.
Select **Subscription** if the membership should renew automatically each year, or **One-time**
if participants pay once for a fixed period with no automatic renewal.
For subscription offerings, set the date the membership renews each year — for example, the
start of your season or the calendar year.
## Adding benefits
Benefits are the perks members receive. You can add two types: discounts on event entries and guest passes.
### Discount benefit
A discount benefit reduces the price of event entries for members.
In your membership settings, go to **Benefits** and click **Add benefit**, then select
**Discount**.
Select one of three options:
* **Percentage discount** — a percentage off the ticket price (for example, 10% off).
* **Flat discount** — a fixed amount off the ticket price (for example, \$5 off).
* **Member price** — a fixed price members pay regardless of the public ticket price.
Enter the value for the discount type you selected.
By default, the discount applies to all your events. To limit it to specific events or
occurrences, add event restrictions in the benefit settings.
If you want to cap how many times a member can use the discount, enter a maximum number of uses.
Leave blank for unlimited uses.
### Guest pass benefit
A guest pass benefit lets members share a limited number of discounted tickets with friends or family.
Click **Add benefit** and select **Guest passes**.
Enter how many guest passes each member can create per period.
Enter the percentage discount applied to the guest's ticket price. Set to `100` to make guest
passes free.
Turn on **Resets on renewal** if you want members to receive a fresh allowance of guest passes
each year when their subscription renews. Leave it off to give members a lifetime total that
never resets.
## Offering the membership during event checkout
You can surface your membership to participants as they register for an event. Participants who do not yet hold an active membership will see a membership step during checkout. Existing active members skip this step automatically and receive their member discount on the ticket.
In your dashboard, go to the event you want to enable the upsell for and open its setup.
Find the **Membership** section in the event's setup and turn the upsell on. You can enable or
disable the upsell per event occurrence independently.
## Discount codes with memberships
Discount codes work on membership purchases. A 100% discount code makes the membership free at checkout; participants complete the standard purchase flow and receive a full membership record. Partial discount codes (for example, 50% off) reduce the purchase price by that amount.
# Managing memberships
Source: https://partner-help.letsdothis.com/docs/memberships/managing-memberships
Handle renewals, cancellations, member details, guest passes, and reporting for your membership program.
Once your membership program is live, you manage it from your dashboard. The primary member (the account holder) can manage their subscription, payment details, auto-renew settings, and guest passes from their membership account page. Secondary members — such as additional family or group members — can view their membership and use their benefits, but cannot change payment details or auto-renew settings. Secondary members who need billing changes should contact their primary member.
## Renewals and auto-renew
Subscription memberships renew automatically on the renewal date you configured for the offering. The platform sends participants an email notification before their renewal date so they can review their membership and update their payment details if needed.
Primary members can turn auto-renew off from their membership dashboard. When auto-renew is off, the membership stays active until its expiry date and then lapses — no charge is taken. Primary members can turn auto-renew back on at any time before the expiry date. Secondary members cannot change auto-renew settings — they should ask the primary member to make this change.
If a renewal payment fails, the participant is notified and prompted to update their payment card. The membership enters a **Past due** state and the participant has time to resolve the issue before the membership is canceled.
## Cancellations
Participants cancel their membership from their membership dashboard. They can choose to:
* **Cancel at the end of the billing period** — the membership stays active until the current period ends, then stops. No further charges are taken and the member keeps their benefits until expiry.
* **Cancel immediately** — the membership ends straight away.
The in-product cancellation flow displays a warning before the participant confirms, making clear that cancellation ends their access. If a participant only wants to update their payment card, they should use **Update payment details** instead — the warning directs them there.
When a membership is canceled, the member's discount and guest pass benefits stop applying. Any guest passes the member already created remain valid for the events they were issued for, until used or explicitly revoked by the member.
## Viewing and editing member details
To find a member's record, go to **Customers** in your dashboard, search by the member's email address, click their record, and select the membership from the **Memberships** section.
You can view member details — name, date of birth, phone number, address, and any custom form fields — from the membership record. The fields available to view and edit depend on the configuration of your membership scheme.
For family and group memberships, the primary member can add and edit secondary members (a partner, children, or other group members) from their dashboard. You can also view and edit secondary member details from your side. Secondary members can be removed if needed — removing a secondary member from a family plan frees up a slot but cannot be undone without re-adding the member's details.
## Guest passes
Guest passes are created and revoked by members from their membership dashboard. From your side you can see which passes have been created, the event they apply to, and their current status:
* **Active** — issued and not yet used.
* **Revoked** — canceled by the member before use.
If a participant asks about a missing or incorrect guest pass, check the **Guest Passes** section on their membership record to confirm the pass count, status, and the email it was sent to.
Members whose guest pass allowance resets on renewal receive a fresh allowance each year when their subscription renews. The counter shown to the member reflects passes used since the most recent reset.
## Memberships report
The **Memberships** report gives you a full list of your members with key details for each.
To open it, go to **Data & Insights → Reports** in your dashboard and select **Memberships**.
The report includes one row per membership, with columns for:
* Member name, email, date of birth, age, phone, and address
* Membership status, offering name, and price
* Policy ID and renewal status
* Expiry date
* Responses to any custom form fields
You can filter by email, name, created date, expiry date, status, and age. Export the report to cross-reference your member list against fulfillment records, eligibility lists, or your own CRM.
## Communicating with members
The memberships report is the main tool for reaching members outside the platform. Export it and use your email tool to send renewal reminders, event news, or benefit announcements.
For automated notifications — renewal reminders and failed-payment alerts — the platform emails members directly. You do not need to set these up.
If a member contacts you about a billing issue or failed renewal, direct them to their membership dashboard to update their payment details. For issues that cannot be resolved through the dashboard, contact your account manager.
## Membership status reference
| Status | What it means |
| - | - |
| **Active** | Membership is current and all benefits apply. |
| **Past due** | A renewal payment failed. The member has been notified and prompted to update their card. |
| **Canceled** | The membership has been canceled — either immediately or at the end of the billing period. No further benefits apply. |
| **Expired** | A one-time membership has passed its end date, or a subscription lapsed without renewal. |
# Memberships
Source: https://partner-help.letsdothis.com/docs/memberships/overview
Offer a recurring membership program that gives participants discounts, guest passes, and exclusive access across your events.
Setting up a membership program requires working with your account manager.
Contact them to get started.
A membership is a program you sell to participants — either as an annual subscription or a one-time purchase — that gives them ongoing benefits across your events. Benefits include discounted entries, guest passes, and early access. Memberships work best for multi-event organizers running a series, club, or seasonal program who want to build a loyal, returning participant base.
Annual subscription memberships generate predictable recurring revenue and reduce the cost of re-engaging participants for each event. One-time memberships suit seasonal passes or tour passes where participants pay once and benefit for a fixed period.
## Membership benefits
A membership program is made up of a few building blocks:
* **Tiers** — pricing levels within the program (for example, Standard and Premium). Each tier typically comes with a different price and benefits.
* **Plans** — the group structure of the membership (for example, Individual, Couple, or Family). Plans define how many adults and children are covered.
* **Offerings** — a specific combination of a tier and a plan, with a price. This is what a participant actually buys.
* **Benefits** — the perks attached to the membership, such as discounts on event entries or guest passes.
## Purchase types
Each offering is set up as either a subscription or a one-time purchase:
* **Subscription** — the membership renews automatically on a set date each year. Participants can turn auto-renew off or cancel at any time from their account.
* **One-time** — the participant pays once and the membership covers a defined period, with no automatic renewal.
## Benefits members receive
### Discounts on event entries
Members receive a discount on event registrations — either a percentage off the ticket price, a flat amount off, or a fixed member price. You can apply the discount to all your events or restrict it to specific ones.
### Guest passes
Members with a guest pass allowance can share a limited number of discounted tickets with friends or family for specific events. Each guest pass is single-use and is sent to the recipient's email address. Members manage their passes from their membership dashboard — they can create new passes and revoke unused ones. Guest pass allowances can reset yearly when a subscription renews, or accumulate over the life of the membership.
### Family and group memberships
Plans that cover more than one person (Couple, Family, and similar) let the primary member add secondary members — a partner or children — each with their own member details. Secondary members receive the same benefits as the primary member.
## Membership upsell during checkout
You can offer your membership during event registration so participants can join and register in a single checkout. Participants who already hold an active membership skip the upsell automatically and proceed straight to registration, receiving their member discount as normal.
## The membership dashboard
After purchasing, participants access their membership from their Let's Do This account. The dashboard shows:
* Current status, expiry date, and auto-renew setting
* Billing details and the payment card on file
* Secondary members (for family and group plans)
* Guest passes — available allowance, passes created, and revoked passes
* Events where their member benefits apply
## Next setup steps
Once your account manager has created your membership scheme, you configure the tiers, plans, pricing, and benefits yourself. See [Creating a membership](/docs/memberships/creating-a-membership) for a step-by-step guide, and [Managing memberships](/docs/memberships/managing-memberships) for ongoing administration.
# Taking action with Nova
Source: https://partner-help.letsdothis.com/docs/nova/actions
Ask Nova to edit bookings, resend confirmation emails, transfer entries, and manage discount codes. Nothing happens until you approve it.
Actions are available when your dashboard user has edit access for the
organization. If your access is view-only, Nova can still answer questions but
won't offer to make changes. See [User
access](/docs/getting-started/user-access) for how permissions work.
Nova can do more than answer questions. It can make changes for you, which is
useful when a participant emails you with a request: a typo in their name, a
missing confirmation email, or a transfer to a friend. Instead of finding the
booking and clicking through the dashboard, describe what you need in a Nova
chat and approve the change when Nova presents it.
Nova can take these actions today:
Fix a participant's name, date of birth, contact details, and more.
Send a booking confirmation to the participant again.
Start a transfer to a friend, another race, or another event.
Create new discount codes or delete existing ones.
Nova uses the same approval step for other changes it can make, such as
[setting goals](/docs/nova/goals), scheduling
[email digest reports](/docs/nova/email-digest-reports), and creating
[email campaigns](/docs/nova/email-campaigns).
## Approval process
Nova never acts on its own. When you ask for a change, it prepares the action
and shows you an approval card in the chat before anything happens.
The card is labeled **Approval required** and names the action, such as
**Edit Booking** or **Create Discount Code**. It lists exactly what is
changing, field by field, so you can check the details before committing.
Click **Approve** to run the action or **Reject** to stop it.
A few things to know:
* **Approval is per action.** If Nova proposes three changes, you get three
cards and decide on each one separately. There is no "always allow".
* **You can keep chatting first.** An unanswered card doesn't expire. You can
ask Nova follow-up questions and come back to approve or reject it later in
the conversation.
* **Rejecting is safe and reversible.** Nova is told you declined and won't
run the action. You can always ask again with different details.
* **The card stays in your history.** Approved and rejected cards remain in
the conversation, stamped with the decision, so you have a record of what
was changed and what wasn't.
For some actions, such as resending an email, the card first shows
`Checking what this would change…` while Nova looks up the exact record under
your permissions. If it can't find the record, the card tells you not to
approve and the **Approve** button is disabled. Ask Nova to look it up again.
## Editing a booking
Ask Nova to update a participant's details on a booking, for example "Change
the date of birth on booking ABC123 to 2 April 1990". Nova can edit:
* First name and last name
* Date of birth
* Gender
* Email address
* Phone number
* Address
* Emergency contact name and phone number
Nova can only edit fields that exist on that event's booking form, and a
gender value must match one of the options your form offers. If a booking has
several participants, Nova asks which participant you mean before proposing
the change.
Edits are recorded as made by you, the person who approved them. After an
edit, Nova's own reporting data can take up to around an hour to reflect the
change, so don't be surprised if a report you run straight afterwards still
shows the old value. The booking itself is updated immediately.
## Resending a booking confirmation email
Ask Nova to resend a booking confirmation, for example "Resend the
confirmation email for booking ABC123". The email always goes to the
participant's email address on file. It can't be redirected to you or anyone
else. If you don't name a specific participant, every participant on the
booking receives their own confirmation.
The approval card shows the exact recipient addresses before you approve, so
you can confirm the email is going to the right person.
Only booking confirmation emails can be resent through Nova. For other
transactional emails, see
[Transactional emails](/docs/email-communications/transactional-emails).
## Transferring an entry
Ask Nova to transfer a participant's entry. There are three kinds of transfer:
* **To a friend.** Nova needs the friend's first name and email address.
* **To another race** within the same event.
* **To another event.**
Nova starts the transfer. It doesn't complete it. The participant or the
person receiving the entry finishes the transfer through the normal transfer
flow, including paying any transfer fee you have configured. Your event's
transfer settings still apply, so the action fails with an explanation if that
transfer type is switched off, the transfer window has closed, or a transfer
is already in progress for the entry.
## Creating and deleting discount codes
Ask Nova to create a discount code, for example "Create a 20% code called
SPRING20 for the Spring Trail Run, valid until the end of March, limited to
100 uses". Nova can set:
* The code itself and a description
* A percentage discount or a fixed amount off
* A maximum discount value for percentage codes
* Total usage limit and per-person usage limit
* Whether the code is for first bookings only
* Start and expiry dates
* Which events or occurrences the code applies to
If you don't specify a usage limit, Nova creates the code with a limit of one
use in total. If you want a code many participants can use, say so, for
example "limited to 500 uses". Every code Nova creates has a total usage
limit. To create a code with unlimited uses, create it in the dashboard
instead.
Some discount code options can't be set through Nova, including affiliate
commission, stacking with other codes, per-entry discounts, restrictions to
specific ticket types, and bulk code generation. For those, manage your codes
directly in the dashboard. See [Discount codes](/docs/event-setup/discount-codes).
You can also ask Nova to delete discount codes, up to 50 at a time, by their
exact codes. Deleting a code stops it working immediately and removes it from
your active list.
Deleting a discount code can't be undone. There is no restore option, and you
can't create a new code with the same code string afterwards. If you only want
to stop a code temporarily, set an expiry date on it instead of deleting it.
Nova will remind you of this before it asks for your approval.
# Custom dashboards
Source: https://partner-help.letsdothis.com/docs/nova/custom-dashboards
Ask Nova to build a live, shareable dashboard from your event data, with no report configuration required.
A custom dashboard brings several visualizations together in one view that
updates itself as your data changes. Where a single chat answer gives you one
chart, a dashboard lets you keep the metrics you care about side by side and come
back to them any time. Build one by describing what you want to see, then tweak,
filter, and share it with your team.
Custom dashboards work well when you have a set of numbers you check regularly.
Good examples are a weekly view of sales pace across events, a marketing
performance board, or a sell-out tracker for a capacity-limited race.
## Building a dashboard
Ask Nova to create a dashboard and describe the data you want on it. If you're
not sure what to include, Nova can help you brainstorm.
* "Create a dashboard tracking registrations, revenue, and add-on attach rate for
my summer series."
* "Create me a dashboard and help me brainstorm the metrics that should go in it."
Nova assembles the dashboard and you can keep refining it in the conversation.
Add or remove charts, change what a widget shows, or adjust the layout. When it
looks right, save it. Your saved dashboards are available from your dashboard
list.
## Live updates
Dashboards refresh their own data. Once a dashboard is built, the numbers stay
current without you rebuilding it, so a board you set up today keeps showing
up-to-date figures the next time you open it.
## Adding filters
You can add drop-down filters to a dashboard so you can change what it shows
without leaving the page, such as a date range or a specific event. Ask Nova to
add them, and use the filters to narrow every widget on the dashboard at once.
* "Add filters to my custom dashboard for date range and event title."
## Sharing with your team
To share a dashboard, click **Share with team** to copy its link, then send it to
your team. Anyone on your team with Nova access can open it.
Your dashboard list shows at a glance which dashboards are visible only to you and
which are shared with your team, so you always know what your colleagues can see.
## Sharing externally
You can also share a dashboard with people outside your team who don't have Nova
access, such as a timing partner or a sponsor. Each external link is protected by
an access PIN, and you can revoke it at any time. An access PIN is an eight-digit
number that the recipient enters to open the dashboard.
External links give a read-only view. Recipients can change the dashboard filters
and export the data, but they can't edit the dashboard or use Nova. Opening a link
always pulls the current data, so the view stays up to date.
To create external links you need edit access to your team's dashboards, or
you need to be the person who created the dashboard. Share the dashboard with
your team first. External links are created from the same panel.
On the dashboard, click **Shared with team** to open the share panel. Below the
team-sharing options you'll find **Share dashboard externally**.
In **Who is this link for?**, enter a label so you can tell your links apart
later, for example `timing partner`. Each link gets its own PIN.
Click **Create link**. Nova generates the link and its **Access PIN** and shows
them to you once.
Click **Copy details** to copy the link and PIN together, then send both to your
recipient. For security, the access PIN is shown only once and can't be viewed
again. If you lose it, delete the link and create a new one.
### Recipient experience
When someone opens the link, they're asked to enter the eight-digit access PIN
before anything loads. Your name and logo appear on this screen so they know the
dashboard is from you, but none of the data is visible until they enter the
correct PIN.
After entering the PIN, they see a read-only version of the dashboard: its charts,
KPI widgets, filters, and an **Export** button for CSV or PDF. They can't edit the
dashboard or open Nova. If the PIN is wrong or you've deleted the link, they see
`That link or PIN is invalid, or access has been removed.`
### Revoking a link
Every link you've created is listed under **Existing external links**, each with a
**Delete** button. Deleting a link takes effect immediately. The next time anyone
tries to use it, they're locked out. Links don't expire on their own, so delete
them when a recipient no longer needs access. You can keep up to 20 external links
on a single dashboard.
### Dashboards with financial data
If a dashboard includes financial figures, the share panel warns you before you
create a link:
> Anyone with this link and access PIN will be able to view the financial data it
> contains. Only share it with people who should have access.
Only people with permission to see financial data can create a financial external
link, and PDF exports of that link are held to the same permission. Share these
links carefully, and delete them as soon as the recipient is done.
## Getting a dashboard by email
You can have a dashboard delivered to you on a schedule, so you stay on top of the
numbers without opening it. Set up a recurring email digest of the dashboard and
Nova emails you a summary at the frequency you choose. See
[Email digests](/docs/nova/email-digest-reports) to set one up.
# Custom instructions for Nova
Source: https://partner-help.letsdothis.com/docs/nova/custom-instructions
Give Nova standing instructions it applies to every conversation, so you don't have to repeat yourself.
Custom instructions are standing preferences Nova applies to every conversation.
Set them once and Nova follows them each time, so you don't have to restate how
you like your answers or explain the same context in every chat.
They work well for two things: shaping how Nova presents answers, and teaching
Nova shorthand for the way you group your events.
* **Formatting preferences:** tell Nova how you like summaries structured.
* **Your own labels:** map a name you use internally to the events it covers, so
Nova knows what you mean without you spelling it out each time.
## Setting your instructions
Open the **Instructions** section on the Nova page and write your instructions in
plain language. Nova applies them to every new conversation from then on. You can
update or remove them at any time.
## Examples
**Format an executive summary the way you want it:**
> When I ask for an executive summary, use 5 bullets maximum, include no more than
> 3 numbers, and clearly state the commercial impact.
**Define a label for a group of events:**
> When I mention the "Trail Series," run the analysis across both the Spring Trail
> Run and the Autumn Trail Run.
Once set, you can ask for "an executive summary" or reference the "Trail
Series," and Nova applies the instruction automatically.
# Downloadable reports from Nova
Source: https://partner-help.letsdothis.com/docs/nova/downloadable-reports
Ask Nova to generate a file or interactive report you can download or share.
When you ask Nova a question that involves a lot of data, it can generate a
report you can download or open in your browser — rather than just displaying the
numbers in the chat. This is useful when you want to share data with your team,
import it into a spreadsheet, or review a fuller picture than a chat response can
show.
## Requesting a report
Ask Nova directly:
* "Can you export this as a CSV?"
* "Generate a report of all registrations in the past 12 months."
* "Give me a downloadable breakdown of revenue by event."
When Nova generates a file, a **report card** appears in the chat with a download
link or a button to open the report in your browser.
## Report card details
The report card shows:
* The **file name** and format.
* When the report was **generated**.
* An **expiry date** — reports are available for a limited time after generation.
Download or open the report before it expires; after that, you can ask Nova to
generate a fresh one.
## Interactive HTML reports
Some reports open as an interactive page in your browser rather than a file you
download. These work the same way — Nova provides a link in the chat, and the
report is available until its expiry date.
# Building email campaigns with Nova
Source: https://partner-help.letsdothis.com/docs/nova/email-campaigns
Describe an audience and Nova builds the segment and drafts your email campaign, ready to preview and send from your dashboard.
Nova can draft a full Let's Do This email campaign from a single conversation.
Describe the audience you want to reach, and Nova builds the segment from your
registration and participant data, creates a draft campaign, and generates the
email content. When it's ready, Nova hands you off to your dashboard to preview
the campaign and send it. Nothing goes out automatically. Everything is created
as a draft, so you have the final say on when it sends.
This is useful when you want to reach a precise group that would be fiddly to
build by hand, such as past participants who haven't come back this year, or
everyone who bought a specific ticket.
## Building a campaign
Ask Nova to build a campaign and describe who you want to reach in plain
language. Nova translates that description into an audience segment using the data
it already knows about your participants.
* "Can you build an email marketing campaign for me?"
* "Email everyone who ran our half marathon last year but hasn't signed up this
year."
Nova builds the segment, creates a draft campaign with that audience already
selected, and drafts the email content. Review the segment and the copy in the
conversation and ask for any changes. You can widen or narrow who's included, or
rework the subject line and body until the message is right.
## Previewing and sending
When the draft is ready, Nova gives you a link to open the campaign in your
dashboard. There you can preview it, make any final edits, and send it. Because
Nova only ever creates a draft, the campaign never sends until you send it
yourself.
Campaigns you build with Nova use the same Let's Do This email system as
campaigns you create elsewhere in your dashboard, so delivery and reporting work
the way you're used to. You can then ask Nova how the campaign performed once it's
out.
* "What was the open rate for my last email campaign?"
# Email digest reports
Source: https://partner-help.letsdothis.com/docs/nova/email-digest-reports
Ask Nova to send you a regular email summary of your dashboard data — daily, weekly, or monthly.
Email digests are scheduled emails Nova sends you on a regular basis with a
summary of your dashboard data, so you don't need to log in to check your
numbers. You set the frequency and timing once, and the emails arrive
automatically.
## Scheduling a digest
Ask Nova to set up a digest in plain language:
* "Send me a weekly summary of my registrations every Monday morning."
* "Set up a daily email with my revenue figures at 8am."
* "Email me a monthly dashboard report on the 1st of each month."
Nova confirms the details before setting anything up.
## The digest preview card
After you describe what you want, Nova shows a preview card with:
* The **frequency** — daily, weekly, or monthly (and the day of the month for
monthly digests).
* The **first send date** — when the first email will arrive.
* The **timezone** used to schedule the sends.
Review the details. Click **Confirm** to save the schedule, or **Cancel** if you
want to change anything. You can also ask Nova to send you a preview email first
so you can see what the digest looks like before committing.
## Frequency options
| Frequency | When it sends |
| - | - |
| **Daily** | Every day at the time you choose |
| **Weekly** | On the day of the week you choose, at the time you choose |
| **Monthly** | On a specific day of the month (1st–28th) at the time you choose |
## Rescheduling a digest
To change the frequency, day, or time of an existing digest, ask Nova:
* "Change my weekly digest to Fridays instead."
* "Move my daily email to 9am."
Nova shows a new preview card with the updated schedule for you to confirm.
## Cancelling a digest
To stop receiving a digest, ask Nova to cancel it:
* "Cancel my weekly email digest."
* "Stop sending me the daily report."
Nova asks you to confirm before cancelling. Once confirmed, it replies to let you
know the digest has been stopped. If you change your mind at that point, Nova will
confirm whether the cancellation went through.
# Getting started with Nova
Source: https://partner-help.letsdothis.com/docs/nova/getting-started-with-nova
Ask Nova questions about your events, from registrations and revenue to ads, capacity, and race-day results, and get plain-language answers in seconds.
Nova needs to be enabled for your account before you can use it. If Nova
doesn't appear in your dashboard sidebar, contact your technical account
manager to get set up.
Nova is your AI assistant. Ask it questions about your events in plain language
and get clear answers without running a report. Nova draws on data from across
your account, including registrations, revenue, marketing, capacity, and
race-day results. You can go from a question to an answer in seconds. When Nova's
answer relates to a specific area of your dashboard, it may include a button to
take you there directly.
You can also [use Nova in Slack](/docs/nova/using-nova-in-slack) from a shared
channel between your team and Let's Do This.
## Opening Nova
There are two ways to open Nova in the dashboard:
* **Dedicated page:** click **Nova** in the dashboard sidebar to open the
full-page chat view.
* **AI Assistant:** on any event page, click the **AI Assistant** button to open
Nova as a panel on the right-hand side of the screen, so you can chat without
leaving the page you're on.
In the side panel, you can click **Expand fullscreen** to switch to the full-page
view, or **Dock to sidebar** to return to the panel. On mobile, Nova always opens
in fullscreen.
## Asking a question
When you start a new chat, Nova shows a few suggestion categories to help you get
going. Click a category to see a list of pre-written questions you can send with
one click. Or type your own question in the chat input and press **Enter**, or
click **Send**.
You can also tap the microphone icon to ask your question by voice. Once you
start typing, the microphone icon is replaced by the **Send** button.
## Supported questions
Nova connects data from across your account, so you can ask about far more than
headline numbers. It can also join data across areas in a single answer. For
example, you can ask how average order value differs by demographic, or whether a
recent email drove add-on sales.
* **Registrations:** sign-ups, sales pace, and year-over-year trends.
* **Revenue:** earnings, ticket performance, and average order value.
* **Demographics:** participant profile, gender split, age, and diversity.
* **Marketing and ads:** Meta Ads performance and ROAS, plus email campaign
results.
* **Capacity:** how close a race is to selling out and how many spaces remain.
Nova can also help with add-ons, race-day results, referrals, and much more.
## Proactive insights and follow-ups
Nova doesn't only answer when asked. On your home page, it surfaces proactive
insights each week across your events, drawing on registrations, ads, traffic,
discount code usage, and progress toward your goals.
You can also ask Nova to revisit an analysis later. It will check back in and let
you know what changed.
* "Analyze how my registration numbers are performing and follow up with me in a
week to let me know what has changed."
## Custom instructions
You can give Nova standing instructions it applies to every conversation. For
example, you can set a preferred format for summaries, or a label that maps to a
set of events you analyze together. See
[Custom instructions](/docs/nova/custom-instructions) to set them up.
## Managing your conversations
### Starting a new chat
Click the **Start new chat** icon in the Nova header to clear the current
conversation and begin a fresh one. Your previous conversation is saved
automatically.
### Viewing past conversations
Your past conversations are saved on the Nova page, sorted by date. A
**Starred** section surfaces conversations that contain messages you've starred,
so you can find key analyses again quickly.
### Renaming and deleting conversations
When you have a conversation open in fullscreen view, its title appears in the
header with a dropdown arrow. Click the arrow to rename or delete the
conversation.
## Giving feedback
**On a single response:** click the **thumbs up** or **thumbs down** icon that
appears below any Nova response. A modal opens where you can add a note
explaining your rating.
**On the overall conversation:** click **Feedback** in the Nova header at any
point during a chat to share broader thoughts on the experience.
# Tracking goals with Nova
Source: https://partner-help.letsdothis.com/docs/nova/goals
Ask Nova to set a registration goal for an event and track your progress toward it over time.
Goals let you set a registration target for an event and tell Nova when you want
to reach it. Once a goal is set, you can check back at any time and ask Nova how
you're tracking against it. Goals are a good way to keep a specific target front
of mind, for example, hitting a registration number before early-bird closes, or
reaching your target by event day.
## Setting a goal
Ask Nova to set a goal in plain language. You can be as specific or general as
you like. Nova will confirm the details before saving anything.
**Examples:**
* "Set a goal to reach 500 registrations for my triathlon by the end of August."
* "I want 2,000 sign-ups for my marathon before early-bird pricing ends."
Nova asks any clarifying questions it needs, then shows you a **goal preview
card** before saving.
## The goal preview card
The preview card shows:
* The goal's **title** and the event, race, or ticket it applies to.
* Your **current position** and the **target**, side by side.
* A **progress bar** showing how far along you are today.
* The **deadline** and how many days remain.
* A brief note on what's next or what progress means in context.
Review the details. If everything looks right, click **Save** to confirm the goal.
If you'd like to change anything, such as the target, the deadline, or the scope,
click **Cancel** and tell Nova what to adjust. Nova will propose a revised card.
Once you save, Nova confirms the goal is set and offers a link to view it on your
home page.
## Goal metrics
A goal tracks registrations, the number of participants signed up for an event.
You tell Nova the number you want to reach and the date you want to reach it by.
Every goal is scoped to a specific event, race, or ticket. Just tell Nova what it
applies to when you ask. You can set a goal at the race level within an event, so
a single triathlon or multi-distance race can track each distance separately.
Goals can't be set across your whole portfolio at once, because a target only
tracks accurately when it's tied to a specific event, race, or ticket.
* "Set a goal of 5,000 entries for the 10K by 1 July."
## Tracking goals on your home page
Once a goal is set, Nova shows a visual progress tracker on your home page. It
plots how far you are toward the target and compares your pace to the same point
last year, based on where you are in the event's life cycle. This makes it easy
to see at a glance whether you're ahead or behind.
You can also add a goal from the home page. Click **Add new goal** and describe
what you want to track.
## Checking progress
Ask Nova at any time how a goal is tracking:
* "How am I doing against my registration goal?"
* "Am I on track to hit my target for the summer series?"
Nova looks at your current data and gives you an up-to-date answer against the
goal you set.
# Proactive alerts
Source: https://partner-help.letsdothis.com/docs/nova/proactive-alerts
Ask Nova to watch your data and email you, either at a time you pick or when a number meets a condition you set.
Proactive alerts let you ask Nova to keep an eye on things for you and reach out
by email, instead of you having to log in and check. There are two kinds. A
**time-based alert** emails you at a moment you choose, like a scheduled
check-in. A **metric-based alert** watches one of your numbers and emails you
when it meets a condition you set. Both are set up in plain language inside a
Nova chat. Nova sets up the alert, then shows you a card confirming the details.
Use a time-based alert when you want a nudge at a set moment, for example the
morning early-bird pricing ends. Use a metric-based alert when you don't know
*when* something will happen but you know the number you care about. For example:
* A reserved entry group is close to using up its held-back capacity.
* The remaining inventory on an add-on drops below the point where you'd want to
restock or promote it.
* Your Meta Ads return on ad spend (ROAS), the revenue you make for every dollar
spent on ads, falls below a level you're no longer happy with.
You can set up as many of each as you need, within the limits described below.
Nova emails you at a time you choose, and can re-run an analysis so the
result is fresh when it lands.
Nova checks a number on a regular schedule and only emails you when it meets
the condition you set.
## Setting a time-based alert
Ask Nova to remind you at a specific time or after a delay, in plain language:
* "Remind me tomorrow at 9am to review my registration numbers."
* "Check back on this in two hours."
* "Re-run this analysis in three days and email me the result."
If you ask Nova to look into something and then set a reminder on it, the
reminder re-runs that same analysis when it fires, so the email you get contains
up-to-date figures rather than the numbers from when you first asked.
Nova shows a confirmation card with a **Reminder set** badge, the title of the
reminder, and when it will fire, shown both as a relative time ("in 3 days") and
a formatted date ("Thursday, 20 Jul"). The card also shows that you'll get an
email when it's ready.
Reminders are personal to you. They are tied to your own account, not shared with
anyone else on the event.
## Setting a metric-based alert
Ask Nova to watch a number and tell you when it meets a condition:
* "Email me when the reserved entries for my club group are 90% claimed."
* "Alert me when the remaining inventory on my shuttle add-on drops below 20."
* "Let me know when my Meta Ads ROAS falls under 3."
Nova works out the number you mean, the comparison ("below", "above", "under",
"over"), and how often to check. Once it sets up the alert, it shows a
confirmation card with an **Alert set** badge summarizing the details.
The card shows:
* The **condition** in plain language, for example `Email me when registrations
per day < 50`.
* The **schedule** — when the first check will happen (relative time plus a
formatted date) and how often it repeats after that.
The card confirms what Nova saved. If anything looks wrong, ask Nova to change or
cancel the alert.
### Watching a value versus watching a change
A metric-based alert can watch two different things:
* **A fixed value.** Nova compares the number to your threshold on every check
and emails you on the first check that meets your condition. "Email me when
registrations drop below 50" works this way. Nova emails you the first time a
check finds the number below 50, even if it was already below 50 when you set
the alert up.
* **A change.** Nova compares the number to what it was at the previous check and
emails you when the change is large enough. "Tell me if registrations fall by
more than 100 in a day" works this way.
When you ask Nova to watch a change, the first check just records a starting
point. The comparison begins from the second check onward, so the earliest you
could be emailed is after the second check.
## Check frequency
Nova checks a metric-based alert at most **once a day**. This means the number
you're watching has to be measured over a window of at least one day. If you ask
for something faster, such as "every hour" or "in real time", Nova will tell you
it can only check once a day and ask you to widen the window.
When you set the alert, you choose how often the check repeats (for example every
day, or every 3 days) and Nova keeps checking on that schedule until the alert
ends.
## Email content
You only get an email from a metric-based alert when the condition is actually
met. Until then, Nova checks quietly in the background and says nothing.
When the condition is met, the email:
* Has the subject line **From Nova – Threshold alert:** followed by the alert's
title.
* Tells you the current value and how it compares to your threshold. For a change
alert, it shows the amount it moved (from the previous value to the current
one).
* Includes a link back to Nova so you can explore the full picture.
If the alert was watching an analysis you asked Nova to run, Nova re-runs that
analysis and includes a short summary in the email.
Time-based reminders always send an email when they fire, prompting you to jump
back into Nova to pick up where you left off.
## Viewing and cancelling your alerts
Ask Nova to show you what's currently active:
* "What alerts do I have set up?"
* "List my reminders."
To stop one, ask Nova to cancel it:
* "Cancel my alert about registrations dropping below 50."
* "Stop the reminder you set for tomorrow morning."
## Limits
The following limits apply:
* You can have up to **52** active reminders at once.
* You can have up to **10** active metric-based alerts per event organizer.
* An alert can run for at most **one year**. Nova won't set up a schedule that
would keep checking beyond that.
If you're at a limit, Nova tells you and asks you to cancel an existing alert
before adding a new one.
## Automatic alert cancellation
**What happens:** Occasionally a metric-based alert stops before you cancel it,
and Nova emails you to explain why.
**Why:** There are two reasons this happens.
* **The number tracks financial data your account can no longer see.** If your
access to financial figures is removed after you set the alert, Nova can't keep
checking it, so the alert is cancelled and Nova lets you know.
* **The number can no longer be worked out.** If the underlying figure can't be
calculated any more, Nova cancels the alert rather than sending you broken
results, and emails you to say so.
**What to do:** If you still want the alert and the cause was a change in access,
ask whoever manages your team's permissions to restore your financial access,
then ask Nova to set the alert up again. Otherwise, ask Nova to help you track a
different number.
# Sharing a Nova conversation
Source: https://partner-help.letsdothis.com/docs/nova/sharing-conversations
Share a copy of a Nova conversation with others in your organization.
After a conversation with Nova, you can share it with anyone in your
organization. The recipient sees your conversation history and can ask their own
follow-up questions — those questions stay separate from your original chat, so
nothing they ask appears in your conversation.
Only users who belong to your organization can open a shared conversation link.
## Sharing a conversation
In the Nova header, click the **Share** icon. The share icon is only visible
once the conversation has at least one message and Nova has finished
responding.
Click **Copy share link**. The link is copied to your clipboard and a
confirmation appears.
Paste the link and send it to the recipient. Anyone without access to your
organization will not be able to view it.
Before sharing, use the star icon to highlight the most useful messages in the
conversation — it makes it easier for recipients to spot the key points.
## Recipient experience
When someone opens a shared link, they can scroll through the full conversation
history. They can ask their own follow-up questions, which branch off into a
separate thread — their messages and Nova's replies appear only in their copy,
not in yours.
## Requesting access to Nova
If you receive a shared conversation link but don't have Nova access on your
account yet, you'll see a prompt at the bottom of the conversation. Click
**Request access to Nova** to send a request. Once it's approved, you'll be able
to start your own conversations.
# Skills
Source: https://partner-help.letsdothis.com/docs/nova/skills
Teach Nova a multi-step workflow once, then run it any time with a single command.
Skills are available to everyone on your team who has access to Nova. If Nova
doesn't appear in your dashboard sidebar, see [Getting started with
Nova](/docs/nova/getting-started-with-nova).
Skills are reusable workflows that Nova follows when completing a specific
task, especially one involving multiple steps or specific requirements. If you
find yourself giving Nova the same detailed request every week, such as a
referral report formatted a particular way, save it as a skill. From then on
you can run the whole workflow with a single command, and everyone gets the
same consistent output every time.
Skills are different from [custom instructions](/docs/nova/custom-instructions).
Instructions are background preferences Nova applies to every conversation.
A skill is a playbook for one specific task that Nova only uses when that task
comes up.
## Creating a skill
Click **Nova** in the dashboard sidebar, then **Skills**. The page shows
**Your skills** (workflows you or your team have set up) and
**From Let's Do This** (built-in skills that are ready to use).
A panel opens with four fields:
* **Name this skill.** A short, plain name for the workflow, up to 80
characters.
* **Shortcut.** The command you type in a chat to run the skill straight
away, for example `referral-report`. Use lowercase letters, numbers, and
hyphens, between 2 and 40 characters.
* **When should Nova use this?** Describe the kind of workflow the skill
should handle, and include words someone might use when asking. Nova
reads this to detect when the skill is relevant. Between 20 and 500
characters.
* **What should Nova do?** Write out the steps Nova should follow. The
more specific you are, the better the result. Up to 5,000 characters.
Click **Save skill**. The skill is now live, and you can type its
`/shortcut` in any chat to run it.
Names and shortcuts must be unique across the skills you can see, so if a team
or built-in skill already uses a name, pick a different one. You can have up to
50 personal skills at a time.
### Drafting a skill with Nova
You don't have to write a skill by hand. Click **Create one with Nova** in the
create panel, or just ask Nova in a chat to help you make a skill. Nova may
also offer to save a workflow as a skill after you finish a multi-step task
together. When it does, a **New skill** card appears in the chat and you choose
**Save skill** or **Skip**. Nothing is saved until you approve it.
## Using a skill in a chat
There are two ways a skill gets used:
* **Type its shortcut.** Type `/` at the start of the chat input to see a list
of your skills with their descriptions. Pick one, or keep typing to filter.
You can send the shortcut on its own to run the skill, or mention it inside a
longer request.
* **Let Nova pick it.** Nova automatically uses a skill when your request
matches its description. That's why a clear "When should Nova use this?"
field matters.
When Nova uses a skill, the response shows a "skill used" note with the skill's
name, so you always know when a saved workflow shaped the answer. Once a skill
is active in a conversation, Nova keeps following it for your follow-up
messages in that thread. Nova can use up to 5 skills in a single response.
## Sharing a skill with your team
New skills are personal by default. Only you see them. To make one available to
everyone, open the skill's menu on the Skills page and choose
**Share with team**. Everyone in your organization can then use it in their
Nova chats, and anyone on your team who manages skills can edit or archive it.
Sharing moves the skill rather than copying it, so it stops being a personal
skill.
Each person on your team can turn any shared or built-in skill off for
themselves with **Disable for you** in the skill's menu. That only affects
them. The skill stays available to everyone else.
## Editing and archiving
Open a skill's menu and choose **Edit** to change any field. Built-in skills
from Let's Do This can't be edited, but you can disable them for yourself.
To remove a skill, choose **Archive**. Nova stops using it, but nothing is
deleted, and you can restore it from the **Archived skills** section later.
Archiving a team skill affects everyone on your team, so the confirmation
dialog will warn you first. If someone claimed the skill's name or shortcut
while it was archived, the restored skill gets a numbered variant of its old
name so nothing clashes.
## Rejected saves
**What happens:** you see a `Skill text rejected` message when saving.
**Why:** every skill is checked for text that reads like an attempt to change
how Nova fundamentally behaves, such as instructions to ignore its guidelines
or pretend to be something else. Occasionally a legitimate phrase can trip
this check.
**What to do:** reword the flagged part in plain terms, describing the task
rather than instructing Nova to take on a new persona, and save again.
## Concurrent edits
**What happens:** you see an `Out of date` message when saving, and the skill
list refreshes.
**Why:** a teammate changed the skill after you opened it, and saving would
have overwritten their edit.
**What to do:** reopen the skill and apply your change on top of the latest
version.
# Use Nova in Slack
Source: https://partner-help.letsdothis.com/docs/nova/using-nova-in-slack
Connect your Slack account to Nova and ask questions about your Let's Do This event data from a shared channel.
Nova must be added to a shared Slack channel between your team and Let's Do
This before you can connect. Ask your Technical Account Manager to create the
channel and add Nova. You also need a Let's Do This dashboard account with
access to [Nova](/docs/nova/getting-started-with-nova).
Use Nova in Slack when you want a quick answer while coordinating with your
team or Technical Account Manager. You can ask about registrations, revenue,
capacity, marketing, and other event data without leaving the conversation.
Each person connects their own Slack account to their own Let's Do This account.
Do not share your connection link with anyone else.
## Connecting your Slack account
Ask your Technical Account Manager to create a shared channel between your
Slack workspace and Let's Do This, and to add Nova to it.
If you already have a shared channel with your Technical Account Manager,
ask them to confirm that Nova has been added.
In the shared channel, tag **@Nova** and ask a question. For example:
> @Nova, how are registrations tracking for my next event?
If your Slack account is not connected yet, Nova replies with a personal
connection link that only you can see.
Open **Click this link to connect** within 10 minutes. Sign in to Let's Do
This if prompted.
The connection page shows the Slack account and Let's Do This account that
will be linked. Check both accounts before continuing.
Click **Connect these accounts**. When you see **Slack connected**, return
to the shared channel and ask your question again.
You only need to connect once for that Slack account. Other people in the
channel must connect their own accounts before they can use Nova.
## Access and privacy
Nova uses the organizer access you already have in your Let's Do This account.
Connecting Slack does not share your password, give other people access to your
dashboard, or let Nova answer questions about organizers you cannot access.
Nova's responses are visible to everyone in the shared channel. If an answer
includes financial data, Nova shows it to you first and asks what to do with it:
* **Share with channel** posts that answer to the channel.
* **Always share here** posts it, and sends future financial answers straight to
this channel. Other channels still check with you first.
* **Keep private** sends the answer to you as a direct message instead.
If you have access to more than one organizer, Nova chooses one as your default.
To change it, send Nova a message in this format:
> @Nova use organiser id 123456
Replace `123456` with the organizer ID you want Nova to use. The organizer must
also be available in the shared channel. Ask your Technical Account Manager if
you do not know the ID or cannot switch to it.
## Asking Nova questions
Tag **@Nova** whenever you start a new question in the shared channel. You can
ask the same kinds of questions you ask Nova in the dashboard, including:
* How registrations are tracking against last year.
* How much capacity remains for an event.
* Which tickets or add-ons are driving revenue.
* How your marketing campaigns are performing.
Keep follow-up questions in the same Slack thread so Nova has the context from
the conversation.
## Disconnecting your Slack account
Ask your Technical Account Manager if you need to disconnect your Slack account
from Nova. After it is disconnected, Nova can no longer use your Let's Do This
access from that Slack account. You can reconnect later by following the same
steps above.
## Good to know
### Expired connection links
**What happens:** the connection page says the link is invalid or has expired.
**What to do:** return to the shared Slack channel and tag **@Nova** again. Nova
sends you a new personal link. Open it within 10 minutes.
### Incorrect account details
**What happens:** the connection page shows a different Slack or Let's Do This
account from the one you want to use.
**What to do:** return to Slack and message Nova from the Slack account you want
to connect. Make sure you are signed in to the correct Let's Do This account
before opening the new connection link.
### Existing Slack connections
**What happens:** the connection page says that the Slack account is already
connected to someone else.
**What to do:** ask your Technical Account Manager to help disconnect the
existing link before you try again. A Slack account cannot be connected to two
Let's Do This accounts at the same time.
### Organizer access
**What happens:** Nova says you do not have access to the organizer, or it
cannot answer questions about that organizer in the shared channel.
**What to do:** check that you can open the organizer in your Let's Do This
dashboard. If you can open it but Nova still cannot use it, ask your Technical
Account Manager to check which organizers are available in the shared channel.
### No Nova response
Make sure you tagged **@Nova** in the shared channel. If Nova still does not
reply, ask your Technical Account Manager to confirm that Nova is in the channel.
# Payments & Financial Operations
Source: https://partner-help.letsdothis.com/docs/payments/payments-and-financial-operations
How payments flow to you, how refunds and chargebacks work, and the optional financial protection services available for your events.
Payments from participants are processed by **Stripe**, Let's Do This's payment processor partner. You receive **net proceeds** — the total registration fees and add-on purchases collected, minus LDT's commission and any applicable fees — paid out to your connected Stripe account on your agreed payout schedule.
Before you can receive payments, you need to connect a Stripe account. See [Connecting Stripe](/docs/getting-started/connecting-stripe) for setup instructions.
## Payment flow
Every participant payment goes through Stripe. LDT facilitates the transaction, deducts commission and fees, and transfers your net proceeds to your Stripe account. Timing and payout schedules are controlled by Stripe.
LDT does not convert currencies. Registration fees and add-on purchases collected in one currency are paid out to you in that same currency.
## Refunds
You can issue a refund from within a participant's booking in your organizer dashboard. When you initiate a refund, you choose whether to absorb the LDT commission that was charged on the original transaction or return it to the participant.
Refunds are executed by Stripe and typically appear on the participant's card within 5–10 business days, depending on their bank.
Partial refunds are supported — you can refund an individual add-on without canceling the entire booking.
**Payment plan bookings.** The organizer-facing refund tool cannot process refunds on payment-plan bookings. To refund a participant on a payment plan, contact LDT support with the booking ID and the amount to refund. Only amounts already collected can be refunded — future installments have not been charged.
## Chargebacks
A chargeback occurs when a participant disputes a transaction directly with their bank or card network. As the event organizer, you are responsible for all chargeback costs — including the disputed amount, network fees, and any re-presentment fees.
LDT will manage and dispute chargebacks on your behalf where it is commercially reasonable to do so. If a dispute is lost, you are still required to reimburse LDT for the full cost. To support a dispute, LDT may ask you to provide evidence such as booking confirmations, participant communications, or your event terms.
## Refund Protection
Refund Protection is an optional insurance service, powered by **Protect Group**, that lets participants protect their registration cost if they can't attend due to a covered reason — such as illness, injury, bereavement, or transport disruption. Participants choose whether to add it at checkout; you don't process claims on their behalf.
Refund Protection must be enabled for your account before it appears in
checkout. Contact your account manager or LDT support to set it up.
### Coverage
Refund Protection covers a participant's full registration cost when they need to cancel for a reason listed in Protect Group's policy. Coverage is dynamically priced — the cost varies based on the registration total — and the participant pays for it at checkout.
### Participant experience
After filling in their details, participants see a dedicated **Refundable Registration** step in checkout. They choose whether to add protection before proceeding to payment. The cost is shown before they confirm.
Once purchased, participants can view their protection details and file a claim directly through Protect Group's portal. A link to their claim portal and the policy terms appears in their booking management page.
### Revenue share
You receive a share of each Refund Protection fee sold on your event. The exact percentage is set out in your Event Organizer Agreement.
### Payment plan interactions
When a participant is on a payment plan, the full cost of Refund Protection is charged as part of the first installment — it is not spread across monthly payments.
## Event Cancellation Protection
Event Cancellation Protection (also called Race Day Insurance) is an optional program that refunds participants if your event is canceled due to circumstances outside your control. It is provided through **Adventure Advocates** or another provider selected by LDT.
Event Cancellation Protection is elected and purchased as part of your Event
Organizer Agreement. Contact your account manager to find out whether your
event qualifies and to arrange coverage.
### Coverage
If your event is canceled due to a covered circumstance — extreme weather, a natural disaster, or an act of terrorism — Adventure Advocates (or the applicable provider) refunds the registration cost directly to each affected participant. Coverage is subject to the provider's qualification criteria and program terms, which are provided in your Event Organizer Agreement.
### Automatic enrollment
Once purchased for an event, Event Cancellation Protection covers every participant who registers. There is no action required at checkout — participants are enrolled automatically from the moment they register.
If a covered cancellation occurs, participants file claims directly through the insurance provider. You do not process the refunds yourself.
# Event Performance
Source: https://partner-help.letsdothis.com/docs/reports/event-performance
Track registrations, revenue, add-on sales, and team growth across your event portfolio using the analytics reports.
The **Portfolio Performance** report requires financials access on your
account. If you cannot see it, ask your account owner to grant you the
necessary permissions.
The analytics reports give you a portfolio-wide view of how your events are performing — registrations sold, revenue generated, add-on take-up, and the growth of team entries. Use these alongside the day-to-day operational reports to understand not just what is happening at an individual event level, but how your portfolio is trending over time.
Open **Reports** from the left navigation in your organizer dashboard. The analytics reports are tagged with the **Analytics** category badge on the **Let's Do This Reports** tab.
## Portfolio Performance
Portfolio Performance is your top-level view of ticket sales and revenue across all events.
You can view the data three ways:
| View | What it shows |
| - | - |
| **By event** | Total ticket count and revenue per event occurrence |
| **By day** | Ticket count and revenue for each calendar day |
| **By month** | Ticket count and revenue for each calendar month |
Use **By event** to compare individual events side by side. The **By day** and **By month** views are useful for spotting sales velocity patterns — for example, whether registrations are clustering around price-change dates or spreading more evenly across the selling window.
## Add-on Performance
The **Add-on Performance** report shows how well your add-ons are selling, broken down by add-on type per event. Each row shows the total units sold and the revenue generated.
Use this report to identify which add-ons are most popular, see which events have the strongest add-on uptake, and inform decisions about what to offer at future events.
## Team Performance
The **Team Performance** report tracks team creation and membership growth. You can view data by month or by event occurrence.
Use this report to understand the group dynamic at your events — whether teams are forming early, and whether group registrations are growing across your portfolio.
## Filtering, saving, and exporting
All analytics reports support column selection and filtering. Use the filter controls to narrow the data to a specific event occurrence, date range, or other dimension.
To save a filtered or customized view for repeated use, choose **Save as a Custom Report** and give it a name. It appears in your **Custom Reports** tab and opens with the same columns and filters already applied.
To download the data, click **Export** to get a CSV of the current view.
# Exports & Custom Reports
Source: https://partner-help.letsdothis.com/docs/reports/exports-and-custom-reports
Download report data as a CSV and save filtered views as named custom reports for reuse.
Every report in the Reports library can be exported as a CSV and saved as a custom report. Exports give you the data in a format you can open in a spreadsheet or import into another tool. Custom reports let you save a filtered, column-adjusted view so you can return to the same setup without rebuilding it each time.
## Exporting data
Open any report in the **Let's Do This Reports** tab, apply any filters or column selections you want, then click **Export**. A CSV file downloads immediately, containing exactly the rows and columns visible in the current view.
Exports respect everything you have applied — date range filters, column selections, status filters, and any other active filters. Filter first, then export, if you want a narrower data set.
## Filtering reports
Most columns support filters, and combining them lets you narrow a report down to exactly what you need. Filters work the same way across all reports — apply them before exporting or before saving as a custom report.
The filter types available depend on the column:
| Filter type | When it applies | Example |
| - | - | - |
| **Equals** | Text, numbers, dates | Event Title **equals** Summer 5K 2025 |
| **Does not equal** | Text, numbers | Status **does not equal** Cancelled |
| **Contains** | Text columns | First Name **contains** Smith |
| **Any of** | Text, status columns | Event Title **any of** Summer 5K 2025, Charity Half Marathon |
| **Before / After** | Date columns | Transaction Date **after** 1 January 2025 |
| **Between** | Date columns | Event Start Date **between** 1 June 2025 and 30 June 2025 |
| **Greater than / Less than** | Number and currency columns | Number of Tickets Sold **greater than** 100 |
| **Is empty** | Any column | Partner Name **is empty** |
A few examples of what you can do:
* Filter the **Reserved Entry Group Performance** report by **Partner Name equals** a specific charity to see only their allocation.
* Filter **Portfolio Performance** by **Event Title any of** to compare two or three events side by side.
* Filter the **Financial** report by **Transaction Date after** the start of your financial year to see revenue within a period.
* Use **Remaining Capacity greater than 0** to find reserved entry groups that still have places to fill.
* Use **Partner Name is empty** to find reserved entry groups that have not been assigned to a partner yet.
## Saving a custom report
A **custom report** is a saved version of any report with your chosen columns and filters baked in. Opening it later puts you straight into that view without needing to re-apply your settings.
On the **Let's Do This Reports** tab, click the report you want to save. Use the column picker to show or hide columns and apply any filters you want to preserve.
Click **Save as a Custom Report**. A dialog opens asking you to name the report. Enter a name and click **Save**.
The report is added to your **Custom Reports** tab.
Go to the **Custom Reports** tab in **Reports**. Your saved reports appear here, listed by name. Click any row to open it — the report loads with your saved columns and filters already applied.
## Saved report settings
When you save a custom report, the following are preserved:
* Your column selection — which columns are visible
* Any active filters — date ranges, status, event occurrence, and other filter values
The data in a custom report is always live. Opening it shows the most current data matching your saved filters, not a snapshot from when you saved it.
Custom reports are shared across your whole organization — anyone on your account can see, open, and edit them. The **Custom Reports** tab shows who created each report and when, so your team can see at a glance what views already exist before building new ones.
Date range filters use **UTC**. If your events run in a different timezone,
keep this in mind when filtering by date — a day boundary in UTC may not match
midnight in your local time.
## Deleting a custom report
To remove a custom report you no longer need, open the **Custom Reports** tab, find the report in the list, and delete it. Deleting a custom report permanently removes it and cannot be undone.
Deleting a custom report does not affect the underlying data or the original pre-built report it was based on.
If you want to update the filters or columns on an existing custom report,
open it, make your changes, and choose **Save to this report** to overwrite
the previous settings, or **Save as a new report** to create a separate
version.
# Financial Reporting
Source: https://partner-help.letsdothis.com/docs/reports/financial-reporting
Revenue and payment reports covering transactions, payouts, line-item breakdowns, and invoices.
## Overview
Financial reports give you a detailed view of the money flowing through your
events — every payment taken, every payout sent, and a granular breakdown of
how revenue is split. They are available to users with **financials access** on
the organizer account.
All financial reports are found in the **Reports** area of your organizer
dashboard, tagged with the **Financials** category badge.
## Access
Financial reports — **Line Items**, **Transactions**, **Payouts**, **VAT
Invoices**, and **Portfolio Performance** — are only visible to account users
who have been granted the financials read permission. If you cannot see these
reports, ask your account owner to update your access.
## The financial reports
### Transactions
The **Transactions** report shows every payment event against your account: a
purchase, an installment, a refund. Each row includes:
* The transaction date and payment status.
* The booker name and payment reference.
* The total amount charged, any discounts or credits applied, and the net
amount paid.
* How the amount splits between the organizer and Let's Do This.
* The associated payout ID, so you can trace a transaction to a specific
payout.
Use Transactions to investigate a specific payment, reconcile refunds, or audit
a date range of activity.
### Line Items
The **Line Items** report breaks revenue down to the individual item level —
one row per ticket, add-on, fee, or discount line. Each row shows:
* The line item type and name.
* The total amount, the organizer share, the Let's Do This share, and the
currency.
Use Line Items to understand exactly what you earned from each component of a
booking — helpful for accounting exports and financial reconciliation.
### Payouts
The **Payouts** report lists every payout sent to your account. Each row
shows:
* The payout ID and currency.
* The gross amount before deductions.
* Any discount amounts and credit amounts applied.
* The final amount paid to you and the Let's Do This fee.
Use Payouts to reconcile bank deposits against your event revenue.
### VAT Invoices
The **VAT Invoices** report shows monthly invoices for the Let's Do This
platform fee. Each row covers one billing month and shows:
* The LDT fee amount excluding tax.
* The tax amount applied to the fee.
* The total LDT fee amount including tax.
Use VAT Invoices to retrieve the documentation you need for tax purposes.
### Portfolio Performance
The **Portfolio Performance** report summarizes ticket sales across your entire
portfolio. You can view sales:
* **By event** — total ticket count and revenue per event occurrence.
* **By day** — ticket count and revenue for each day.
* **By month** — ticket count and revenue for each calendar month.
Use Portfolio Performance to spot sales trends, compare event performance, and
track revenue over time.
## Filtering and exporting
Every financial report supports column selection, filters (date range, status,
currency, and more), CSV export, and saving as a Custom Report. The export
respects any filters and column selections you have applied.
To trace a specific booking to a payout: open **Transactions**, filter by
booker name or payment reference, and note the **Payout ID**. Then open
**Payouts** and filter by that ID.
**Transactions vs. Line Items:** Transactions shows one row per payment event
— a purchase, installment, or refund — with totals. Line Items breaks each
transaction into individual rows per ticket, add-on, or fee. Use Transactions
for payment-level reconciliation and Line Items for item-level accounting.
# Reports
Source: https://partner-help.letsdothis.com/docs/reports/overview
A library of pre-built and custom reports that help you understand your events, track participant activity, and manage your data.
## Overview
The **Reports** area of your organizer dashboard gives you ready-to-use reports
covering registrations, finances, transfers, teams, add-ons, and more. Every
report can be filtered, sorted, and exported, and you can save your own
customized views for reuse.
## Finding reports
Open **Reports** from the left navigation in your organizer dashboard. The page
has two tabs:
| Tab | What it shows |
| - | - |
| **Let's Do This Reports** | The full library of pre-built reports, organized by category |
| **Custom Reports** | Reports you have saved with your own column selections and filters |
Use the search bar on each tab to find a report by name.
## Report categories
Every pre-built report is tagged with one of three categories:
| Category | What it covers |
| - | - |
| **Analytics** | Performance data — ticket sales trends, team growth, add-on revenue, reserved entry fill rates |
| **Operational** | Day-to-day management — participant lists, teams, transfers, discount code usage, payment plan status |
| **Financials** | Revenue and payment data — transactions, payouts, and line-item breakdowns. Requires financials access on your account. |
## Available reports
### Analytics
| Report | What it shows |
| - | - |
| **Add-on Performance** | Total add-on sales and revenue per event, broken down by add-on type |
| **Portfolio Performance** | Ticket sales totals by event, by day, and by month. Requires financials access. |
| **Reserved Entry Performance** | Fill rate, total capacity, and remaining places for each reserved entry group |
| **Team Performance** | Team creation and membership growth, viewable by month or by event |
### Operational
| Report | What it shows |
| - | - |
| **Registrations** | All participant registrations: attendance status, ticket type, contact details |
| **Add-on Allocations** | Each add-on purchase: allocation status, item, variant, purchaser details |
| **Teams** | All teams and their members, with filters for large groups and teams with missing member details |
| **Discount Codes** | Discount code usage, type, percentage, and expiration |
| **Payment Plans** | Payment plan status, installment progress, amounts, and next payment date |
| **Price Changes** | All price tiers: current status, tickets sold, tickets remaining, and upcoming tier details |
| **Transfers** | Participant-to-participant transfers, event transfers, and race transfers |
### Financials
| Report | What it shows |
| - | - |
| **Line Items** | A granular breakdown of every revenue line: type, name, organizer amount, and currency |
| **Transactions** | Every payment transaction with status, amounts, payout reference, and booker details |
| **Payouts** | All payouts: gross amount, deductions, and the net amount paid to your account |
| **VAT Invoices** | Monthly invoices showing the fee amounts and applicable taxes for your account |
Financial reports — Line Items, Transactions, Payouts, VAT Invoices, and
Portfolio Performance — are only visible to users with financials access on
the account. If you cannot see these reports, ask your account owner to grant
you the necessary permissions.
## Using a report
On the **Let's Do This Reports** tab, click a report card to open it.
Some reports are event-specific — Registrations, Add-on Allocations, Add-on
Performance, Price Changes, Teams, and Transfers — and clicking the card
opens a picker so you can choose which event occurrence to run the report
for.
Use the column picker to show or hide columns. Use the filter controls to
narrow the data — for example, filter registrations to a specific ticket
type, or transactions to a date range.
* **Export** — download the current view as a CSV file.
* **Save as a Custom Report** — name the report and save it with your
current columns and filters intact. It appears in the **Custom Reports**
tab and can be reopened at any time with the same setup.
Most reports reflect bookings and transactions as they happen. Where data may
be delayed, the report description notes how long the delay can be.
# Reserved Entry Reporting
Source: https://partner-help.letsdothis.com/docs/reports/reserved-entry-reporting
Track how reserved entry groups are filling up across your events, with capacity and partner-level breakdowns.
## Overview
The **Reserved Entry Performance** report shows how reserved entry groups
across your events are filling up. A reserved entry is a block of places held
for a specific partner — a charity, a corporate sponsor, or another
organization — who commits to filling those spots.
The report answers two key questions: how much of each group's capacity has
been claimed, and which partners still have places left to fill.
## Opening the report
From your organizer dashboard, go to **Reports**, find **Reserved Entry
Performance** in the report library, and click it. The report opens with the
**Reserved Entry Group Performance** template loaded by default.
## Report templates
The Reserved Entry Performance report comes with three built-in templates.
Switch between them using the template selector at the top of the report.
### Reserved Entry Group Performance
One row per reserved entry group. Use this view to see each group's fill
status at a glance. Columns include:
| Column | What it shows |
| - | - |
| **Reserved Entry Code** | The reservation code for the group |
| **Reserved Entry Name** | The group name |
| **Reserved Entry Type** | The reserved entry type |
| **Event Title** | The event the group is linked to |
| **Event Start Date** | The start date of the event occurrence |
| **Partner Name** | The partner associated with this group, if any |
| **Max Capacity** | The total number of places allocated to the group |
| **Used Capacity** | Places that have been claimed |
| **Remaining Capacity** | Places still available within the group's allocation |
### Reserved Entry Event Performance
One row per event occurrence. Use this view for an event-level summary of all
reserved entry activity. Columns include:
| Column | What it shows |
| - | - |
| **Event Title** | The event occurrence name |
| **Event Start Date** | The start date of the event occurrence |
| **Reserved Entry Groups Count** | Total number of reserved entry groups for the event |
| **Reserved Entry Groups Completed Count** | Groups that have reached their full capacity |
| **Max Capacity** | Combined total places across all groups |
| **Used Capacity** | Combined claimed places |
| **Remaining Capacity** | Combined remaining places |
### Reserved Entry Partner Performance
One row per partner. Use this view to compare how well different partners are
filling their allocations. This template automatically filters to groups that
have a partner assigned. Columns include:
| Column | What it shows |
| - | - |
| **Partner Name** | The partner name |
| **Reserved Entry Groups Count** | Number of reserved entry groups assigned to the partner |
| **Reserved Entry Groups Completed Count** | Groups that have reached their full capacity |
| **Max Capacity** | Total places across all the partner's groups |
| **Used Capacity** | Places claimed across all the partner's groups |
| **Remaining Capacity** | Places still available across all the partner's groups |
## Filtering and exporting
You can filter any template further — for example, to a specific event or
partner — using the filter controls. To see reserved entry performance for a
single event, open the **Reserved Entry Group Performance** or **Reserved Entry
Event Performance** template and filter by event occurrence.
Export the current view as a CSV using the export control. To save a filtered
or customized view, choose **Save as a Custom Report** and give it a name — it
will appear in your **Custom Reports** tab.
The **Partner Performance** template automatically filters to groups with a
partner assigned. To see all groups regardless of partner, use the **Group
Performance** template instead.
# Shareable Reports
Source: https://partner-help.letsdothis.com/docs/reports/shareable-reports
Give external viewers a live, read-only link to a saved report — protected by an access pin.
You can only create a share link for a **saved custom report**. If you have
not yet saved the report as a custom report, or if you have unsaved changes,
the share option will not be available. Save or save-update the report first,
then share it.
Shareable reports let you give someone outside your team — a sponsor, a charity partner, or a colleague without a dashboard login — a live view of a saved report. Each share link comes with an **access pin**. The person you share with needs both the link and the pin to open the report.
The report always shows current data, not a snapshot from when you created the link. You can create multiple share links for the same report — one per person or audience — and revoke any of them individually without affecting the others.
## Creating a share link
Go to the **Custom Reports** tab in **Reports** and click the custom report you want to share. The report opens with your saved columns and filters applied.
Click the share button on the report. The share modal opens, showing any links you have already created for this report.
Click to create a new link. You are prompted to enter a name — this is for your reference only, to help you tell links apart (for example, the name of the person or team you're sharing with). Enter a name and confirm.
The new link and its access pin appear in the list.
Click **Copy details** to copy both the link and the access pin to your clipboard in a ready-to-send format. Paste and send them to the recipient.
The recipient needs **both** the link and the access pin. The pin protects the report — the URL alone is not enough to open it.
## Recipient experience
The share link opens the report in a read-only view. The recipient can see the rows and columns as you configured them in the saved report. They can export the data as a CSV, but they cannot change filters, add or remove columns, edit the report, or access any other part of the dashboard.
Because the report is live, the data updates as new registrations, transactions, or other activity comes in. You do not need to send a fresh link each time the data changes.
## Revoking access
To revoke access for a specific recipient, open the share modal on the report, find their link in the list, and click **Delete**. The link stops working immediately. Any other share links you have created for the same report are not affected.
Deleting a share link does not affect the report itself or its data.
# Learn & Level Up: Creating an Event
Source: https://partner-help.letsdothis.com/docs/webinars/creating-an-event
Watch our webinar recording covering everything you need to know to set up an event on Let's Do This.
In this webinar, we walk through the full process of setting up an event on Let's Do This, from initial creation through to final pre-launch checks.
Whether you're building your first event or duplicating an existing one, this session shows exactly what to review before hitting Ready to launch.
## 🎥 [Watch our full webinar here](https://watch.getcontrast.io/watch/letsdothis-learn-level-up-back-to-basics)
## 1. Creating your event: choosing the right starting point
The session begins with the three ways you can create an event and when to use each one:
* **Start from scratch** – Best for first-time events or when you're creating a completely different format.
* **Repeat an event** – Ideal when the same event is running again on a new date. This copies everything across, making it the fastest option for annual events.
* **Make a copy** – Best for similar events that need changes (such as name, date, or location). Some elements won't carry over, including reviews, capacities, and event-specific discount codes.
Avoid updating the date on an old event, as this can mix previous participants into a new event's start list.
## 2. Pre-launch setup
Once your event is created, the webinar demos the key areas to review in **Manage event**, including:
* **Event details & event page content:** Images, descriptions, logistics, FAQs, tags, and terms & conditions.
* **Races:** Setting up multiple distances or activities, each with its own start time.
* **Tickets:** Pricing, open and close dates, booking fees, purchase limits, fast checkout, and age restrictions.
* **Booking forms:** Required for each ticket to be bookable.
* **Custom booking questions:** Created as booking form fields and then added to the relevant booking form.
## 3. Common setup issues
The most common reasons tickets aren't bookable, including:
* Event details not updated after copying or repeating an event
* Tickets still marked as sold out
* Booking forms missing or not live
* Ticket availability dates left in the past
These are quick fixes once you know where to look.
# Learn & Level Up: Customer Support
Source: https://partner-help.letsdothis.com/docs/webinars/customer-support
Watch our webinar recording covering everything you need to know to manage your participants on Let's Do This.
In this recorded webinar, we walk through how to quickly find and manage bookings, handle cancellations, refunds, transfers and payment plans, and enable self-serve tools that reduce inbound queries. Watch the recording below to see how to handle support tasks and give participants more control over their bookings.
For more complex queries, including help with refunds, Refund Protect cases, or payment plan issues, please contact our customer support team at [support@letsdothis.com](mailto:support@letsdothis.com).
## 🎥 [Watch our full webinar here](https://watch.getcontrast.io/register/letsdothis-learn-level-up-customer-support)
## 1. Finding bookings
You can search in two ways:
* **Organizer level** – Use **All bookings** or **All customers** to search across all events by booking ID or name. Participant profiles include an AI summary, event history, payment timeline, notes, and marketing preferences.
* **Event level** – Use the **Start list** within a specific event to search by booking ID or name and view entry details.
## 2. Managing bookings
Once inside a booking, you can:
* **Cancel entries** (does not automatically refund)
* **Request refunds** (automatically cancels the entry and is processed by LDT Customer Support Team, unless you have refund permissions)
* **Transfer entries** (to another race, event, or person, or refund to credit)
* **Resend confirmation or receipt emails**
## 3. Enabling self-serve (reduce inbound queries)
Self-serve settings can be applied at event or organizer level and allow participants to manage their own booking:
* Edit booking details
* Purchase add-ons after registration
* Transfer to another race, event, or person (with rules, fees, and cutoffs)
* Cancel for refund to credit (with optional admin fee)
## 4. Payment plans
Best suited for higher-priced tickets:
* Participants pay monthly after an initial payment.
* Failed payments are retried automatically.
* If all retries fail, the entry is canceled.
* Participants must rebook, but previous payments can be refunded to credit.
## 5. Refund Protect
An optional add-on (\~10% of ticket price) that allows participants to claim a refund for eligible reasons (e.g. injury or travel disruption).
* Managed by Protect Group, not the organizer.
* Participants apply via unique link on their manage booking page.
* The fee is non-refundable.
* 25% of the add-on revenue goes to the organizer.
# Learn & Level Up: How to Set Up Register Your Interest and Waitlists
Source: https://partner-help.letsdothis.com/docs/webinars/register-your-interest-and-waitlists
Watch our webinar to learn how Register Your Interest and Waitlists work on Let's Do This, and how to use each feature to capture demand before and after your event sells out.
Register Your Interest and Waitlists help you capture demand at different stages of the event lifecycle.
* **Register Your Interest** is for events that aren't on sale yet, helping you collect interest before entries open.
* **Waitlists** are for sold-out events, allowing you to capture ongoing demand and automatically fill places as they become available.
## 🎥 [Watch the full webinar here](https://watch.getcontrast.io/videos/3349b10f-3075-4091-9109-bdb461c57e66)
## Webinar topics
In this session, we cover:
* The key differences between Register Your Interest and Waitlists
* When to use each feature
* How to set them up on the Let's Do This platform
* The participant journey and communications involved
* How applications and waitlists are managed behind the scenes
* Best practices for getting the most value from both tools
Both features help you capture registrations, maintain engagement, and make sure demand isn't lost.
# Learn & Level Up: Sending Emails on Let's Do This
Source: https://partner-help.letsdothis.com/docs/webinars/sending-emails
Watch our webinar recording covering everything you need to know to send marketing and transactional emails on Let's Do This.
Learn how email works on the Let's Do This dashboard, including marketing and transactional emails, audience building, personalization, branding, and confirmation emails.
Whether you're driving registrations, sharing event information, or keeping participants informed, the Let's Do This dashboard includes dedicated tools for email creation, audience management, personalization, branding, and performance tracking.
### 🎥 [Watch the full webinar here](https://watch.getcontrast.io/videos/4262ced3-25f2-4edd-aa21-3778d2726d5c)
## 1. Two email types
* **Transactional emails** cover event-critical information that participants need to receive to take part, such as event guides, kit lists, and parking information. Transactional emails sit inside the **event** under **transactional emails**.
* **Marketing emails** support registrations and engagement, such as discount codes, merchandise, or partner promotions. Marketing emails only go to people who opt in or do not opt out. Marketing emails sit in the **marketing** section at organizer level.
## 2. Building an email
* You can create a **scheduled** email or a **triggered** email.
* You can start from a template, edit content blocks, and add images, text, titles, and buttons.
* You can insert personal attributes such as **first name** and other custom fields. You can use the **add more** option to access additional booking form fields and copy snippets into the email.
* You can preview in web and mobile views and send a test email to yourself.
## 3. Branding
* You can create a **brand theme** with custom logo, colors, fonts, and background images.
* A brand theme changes the look of the email so it matches event branding.
## 4. Audience building
* **Transactional emails:** Transactional emails can go to the full start list or to a filtered subset. You can filter by event data such as race title or custom questions.
* **Marketing emails:** You can import a **CSV** segment using email addresses. You can build audiences using filters such as past event participation, city, or age on race day. Opt-ins must be enabled in **settings** under **booking form fields and marketing opt-ins**.
## 5. Custom confirmation emails
* You can customize confirmation emails per event.
* These emails can include event information and FAQs, but not marketing content.
* If you update a confirmation email and resend it, recipients receive the new version.