> ## 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 discount code import status > 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. ## OpenAPI ````yaml /openapi.json get /v0/discount-codes/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/discount-codes/import/{jobId}: get: tags: - DiscountCodes summary: Get discount code import status description: >- 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. parameters: - schema: type: string in: path name: jobId required: true responses: '200': description: Default Response content: application/json: schema: $ref: '#/components/schemas/DiscountCodeImportJobStatus' components: schemas: DiscountCodeImportJobStatus: title: DiscountCodeImportJobStatus type: object properties: jobId: type: string status: type: string enum: - queued - processing - completed - cancelled counts: $ref: '#/components/schemas/ImportJobCounts' rowCounts: $ref: '#/components/schemas/ImportRowCounts' results: type: array items: $ref: '#/components/schemas/DiscountCodeImportRowResult' required: - jobId - status - counts - rowCounts - results additionalProperties: false description: >- The state of an asynchronous discount code import. `results` accumulates as the job's tasks complete, so a `processing` job reports the rows 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 row outcomes in `results` and accumulates the same way, so a non-zero `rowCounts.failed` is the signal to inspect `results`. example: jobId: 661718293a4b5c6d7e8f901a 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: - code: WELCOME20 discountCodeId: 65d5e6f708192a3b4c5d6e7f status: succeeded errors: [] - code: WELCOME20 status: failed errors: - code: DUPLICATE_CODE message: code appears more than once in this batch ImportJobCounts: title: ImportJobCounts 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. DiscountCodeImportRowResult: title: DiscountCodeImportRowResult type: object properties: code: type: string description: The `code` of the row, uppercased. discountCodeId: type: string description: >- The created discount code — or, for `alreadyImported`, the existing code the row matched. status: type: string enum: - succeeded - failed - alreadyImported description: >- `alreadyImported` means a code with this `code` already exists for your organizer and nothing was applied. errors: type: array items: $ref: '#/components/schemas/DiscountCodeImportErrorDetail' description: Why the row failed; empty otherwise. required: - code - status - errors additionalProperties: false description: The outcome of one imported row. DiscountCodeImportErrorDetail: title: DiscountCodeImportErrorDetail type: object properties: code: type: string fieldId: type: string message: type: string required: - code - message additionalProperties: false description: One occurrence of a validation error. securitySchemes: bearerAuth: type: http scheme: bearer bearerFormat: JWT ````