> ## Documentation Index > Fetch the complete documentation index at: https://partner-help.letsdothis.com/llms.txt > Use this file to discover all available pages before exploring further. # Get reserved entry participant import status > 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. ## OpenAPI ````yaml /openapi.json get /v0/reserved-entries/participants/import/{jobId} openapi: 3.1.0 info: title: Let's Do This API version: 0.1.0 description: > The full reference — getting started, pagination, error responses, rate limits and the changelog — lives at [partner-help.letsdothis.com/api-reference](https://partner-help.letsdothis.com/api-reference/overview). This page is the interactive OpenAPI view of the same specification. # Authentication Create an API key from **Settings** → **Credentials** in your Let's Do This account and send it as a bearer token: ```bash curl --request GET \ --url "https://api.letsdothis.com/v0/participants" \ --header "Authorization: Bearer YOUR-API-KEY" ``` Keep the key secret: it identifies your organization, so do not ship it in a website or native app. If a key is exposed, revoke it from the same section and create a replacement. # OpenAPI schema Download the [OpenAPI schema](https://api.letsdothis.com/documentation/json) to use with Postman or an OpenAPI client generator. servers: - url: https://api.letsdothis.com description: Production - url: https://api.staging.letsdothis.com description: Staging security: - bearerAuth: [] tags: - name: Events x-group: Events description: Events that participants can register for. - name: EventOccurrences x-group: Event occurrences description: >- Event occurrences scoped to the organizer associated with your Public API credentials. Unlike the public Events catalog, results are limited to your own events. - name: Races x-group: Races description: >- Races within an event occurrence. An event occurrence may have one or more races, for example a 5K and a 10K within the same race day. - name: Tickets x-group: Tickets description: Tickets that are available for events. - name: BookingForms x-group: Booking forms description: >- Booking forms define the questions a booker answers when registering for a ticket. A ticket usually references a single booking form, so expect zero or one, while a booking form may be shared across multiple tickets. - name: BookingFormFields x-group: Booking form fields description: >- Booking form fields are the individual questions on a booking form — their type, label, options, and whether an answer is required. A field can be reused across multiple forms. - name: Bookings x-group: Bookings description: >- Bookings are the transaction record for a registration. A booking may contain one or more participants (entries). - name: Participant x-group: Participants description: Participants are users who successfully booked an event. - name: LineItem x-group: Line items description: Financial details related to individual items within transactions. - name: AddOns x-group: Add-ons description: >- Organizer-owned products that can be purchased and allocated to participants. Imported products retain stable external identities. - name: DiscountCodes x-group: Discount codes description: >- Discount codes participants enter at checkout to reduce the price of a booking. - name: Credits x-group: Credits description: >- Credits are balances participants can spend at checkout, identified by their email address. - name: Referrals x-group: Referrals description: >- Referral programs, the referrers registered on them, and asynchronous imports of historical referrals. - name: Application x-group: Applications description: >- Applications are created when a user applies for tickets that are set up to require an application process, such as balloted or "Good For Age" entries. - name: Partner x-group: Partners description: >- Partners that were created by the organization who can have Reserved Entries assigned to them. - name: ReservedEntries x-group: Reserved entries description: >- Reserved Entries are entries that are reserved for a partner. After being assigned, the partner can then allocate these entries to participants. - name: Timing x-group: Timing description: >- Timing providers push bib numbers and bib-pack shipments back to Let's Do This for the startlist entries they received. Available to select timing partners only. paths: /v0/reserved-entries/participants/import/{jobId}: get: tags: - ReservedEntries summary: Get reserved entry participant import status description: >- 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. parameters: - schema: type: string in: path name: jobId required: true responses: '200': description: Default Response content: application/json: schema: $ref: '#/components/schemas/ReservedEntryParticipantImportJobStatus' '400': description: Bad request content: application/json: schema: description: Bad request type: object properties: statusCode: type: number enum: - 400 error: type: string message: type: string components: schemas: ReservedEntryParticipantImportJobStatus: title: ReservedEntryParticipantImportJobStatus type: object properties: jobId: type: string status: type: string enum: - queued - processing - completed - cancelled counts: $ref: '#/components/schemas/ReservedEntryParticipantImportJobCounts' rowCounts: $ref: '#/components/schemas/ImportRowCounts' results: type: array items: $ref: '#/components/schemas/ReservedEntryParticipantImportResult' capacityChanges: type: array items: $ref: '#/components/schemas/ReservedEntryParticipantImportCapacityChange' description: >- The capacity raises this job made, empty unless the request set `expandCapacity`. Accumulates alongside `results`. required: - jobId - status - counts - rowCounts - results - capacityChanges additionalProperties: false description: >- The state of an asynchronous reserved entry participant import. `results` accumulates as the job's tasks complete, so a `processing` job reports the assignments finished so far; poll until `status` is `completed`. `results` is the outcome: one entry per submitted row, carrying that row's own `status` and `errors`. It is the only field that reports whether any data landed, so decide what to action from it. `status` and `counts` describe progress, and neither reports success. `status` is `completed` once the work finished, including work whose every row was rejected, and `counts` is of internal work units rather than rows. `rowCounts` totals the result outcomes in `results` and accumulates the same way, so a non-zero `rowCounts.failed` is the signal to inspect `results`. Results are per participant, so a submitted row covering a booking's participants yields several, and `rowCounts.total` can exceed the submitted row count. example: jobId: 664a4b5c6d7e8f901a2b3c4d status: completed counts: pending: 0 processing: 0 success: 1 failure: 0 cancelled: 0 total: 1 rowCounts: succeeded: 1 alreadyImported: 0 failed: 1 total: 2 results: - rowIndex: 0 reservedEntryGroupId: 65a2b3c4d5e6f708192a3b4c bookingId: 65a1b2c3d4e5f60718293a4b entryId: 65b3c4d5e6f708192a3b4c5d participantId: 8c11d86e-a472-4d4a-b1aa-0a816f715f21 individualReservedEntryId: 65c4d5e6f708192a3b4c5d6e status: succeeded errors: [] - rowIndex: 1 reservedEntryGroupId: 65a2b3c4d5e6f708192a3b4c status: failed errors: - code: NO_CAPACITY_REMAINING message: >- Group VIP has 0 free places but the batch assigns 1. Set expandCapacity to raise it. capacityChanges: [] ReservedEntryParticipantImportJobCounts: title: ReservedEntryParticipantImportJobCounts type: object properties: pending: type: number processing: type: number success: type: number failure: type: number cancelled: type: number total: type: number required: - pending - processing - success - failure - cancelled - total additionalProperties: false description: >- Progress counts for an import job, tracking internal work units rather than rows. One unit covers a server-side chunk of the submitted batch, so `total` does not correspond to the number of rows submitted, and a unit that runs to completion counts as `success` even when every one of its rows failed validation. Per-row outcomes, including failures, are reported in `results`, not here. ImportRowCounts: title: ImportRowCounts type: object properties: succeeded: type: number description: Results whose data landed. alreadyImported: type: number description: Results that matched an existing import, so nothing was applied. failed: type: number description: Results that failed; each carries its errors in `results`. total: type: number description: Results reported so far, across all outcomes. required: - succeeded - alreadyImported - failed - total additionalProperties: false description: >- Outcome totals for an import job, folded from `results`: one count per reported result, not per submitted row. Most imports report one result per submitted row, but an endpoint can report several — a reserved-entry participant row covering a booking reports one result per participant — so `total` can legitimately exceed the submitted row count and is not a reconciliation check against it. The totals accumulate the same way `results` does: a `processing` job counts the results reported so far. A non-zero `failed` is the signal to inspect `results` and act on the failures. ReservedEntryParticipantImportResult: title: ReservedEntryParticipantImportResult type: object properties: rowIndex: type: number description: The zero-based position of the row in `assignments` this came from. reservedEntryGroupId: type: string description: The reserved entry group the entry was assigned to. bookingId: type: string description: >- The booking the entry belongs to. Present on `succeeded` and `alreadyImported`; absent on a `failed` assignment whose row could not be resolved to a participant at all, where there is nothing to echo. entryId: type: string description: >- The start list entry assigned. Present on the same results as `bookingId`. participantId: type: string description: >- The participant assigned. Present on the same results as `bookingId`: the reserved entry is linked by participant, so this is the durable id to store, whichever form the row supplied. individualReservedEntryId: type: string description: >- The reservation the participant now holds in the group — or, for `alreadyImported`, the one they already held. Absent on `failed`. status: type: string enum: - succeeded - failed - alreadyImported description: >- `alreadyImported` means this participant was already assigned to this group and nothing was applied. Finer failure causes — an exhausted group, or a participant claimed by another group first — are reported as codes in `errors`. errors: type: array items: $ref: '#/components/schemas/ReservedEntryParticipantImportErrorDetail' description: Why the assignment failed; empty otherwise. required: - rowIndex - reservedEntryGroupId - status - errors additionalProperties: false description: >- The outcome of one assignment. Results are per assignment, not per submitted row: a row naming a `bookingId` produces one of these per participant on that booking, all sharing its `rowIndex`. The reconciliation ids are required on any result that resolved to a participant, so a partner can always reconcile a `succeeded` or `alreadyImported` assignment on whichever id it holds. Expressed as a conditional rather than by splitting this into resolved and failed variants, which keeps the shape symmetrical with `BookingImportRowResult`. if: properties: status: enum: - succeeded - alreadyImported then: required: - bookingId - entryId - participantId ReservedEntryParticipantImportCapacityChange: title: ReservedEntryParticipantImportCapacityChange type: object properties: reservedEntryGroupId: type: string description: The group that was raised. previousMaxCapacity: type: number description: Its capacity before this job ran. newMaxCapacity: type: number description: >- Its capacity afterwards. The difference is the places the job created. required: - reservedEntryGroupId - previousMaxCapacity - newMaxCapacity additionalProperties: false description: >- A group whose `maxCapacity` the job raised to fit the batch, reported so the resulting block sizes can be reconciled without re-reading every group. ReservedEntryParticipantImportErrorDetail: title: ReservedEntryParticipantImportErrorDetail type: object properties: code: type: string message: type: string required: - code - message additionalProperties: false description: >- One occurrence of a validation error. `code` names the cause so it can be acted on without reading the message. `INVALID_ASSIGNMENT` means the assignment itself was not usable, so resubmitting it unchanged cannot succeed, and `INTERNAL` means the cause could not be named. The others describe the state that blocked the assignment, which may no longer hold: `NO_CAPACITY_REMAINING` clears when a place frees or the group is raised, so whether a retry can help depends on the code. `BOOKING_SPANS_SEVERAL_GROUPS` means one booking's participants were assigned to different reserved entry groups. A booking records one group, so resubmitting it unchanged cannot succeed: split those participants across separate bookings, or send them to one group. securitySchemes: bearerAuth: type: http scheme: bearer bearerFormat: JWT ````