Preflight QC

Preflight QC is a premium add-on that gives you professional release QC. Submit a release and Preflight QC analyzes it end to end: metadata, release dates, audio, artwork, AI content, catalog identifiers, prior distribution, and licensing documentation. You get a clear, actionable quality report. Fix what it flags on your own timeline, then confirm the release into review when you’re satisfied.

For labels and API integrators, Preflight QC works as a building block. Pull the quality report programmatically, wire it into your own QA pipeline, gate your internal approval process on it, and confirm releases into review automatically. Your team sets the quality bar, and Preflight QC does the analysis.

A release that arrives clean moves through review fast. Preflight QC gets you there before you submit.

What Preflight QC is

With Preflight QC enabled on your account, submitting a release for distribution doesn’t send it straight into the review queue. Instead, the release enters a pre-review hold (“pending your review”) while Preflight QC runs its quality analysis: metadata, release dates, audio, artwork, AI content, catalog identifiers, prior distribution, and licensing documentation. The result is a quality report, and what you build on it is up to you:

• Your own QA workflow (API). Run your catalog through the quality analysis, pull the report programmatically into your own QA pipeline, gate your internal approval process on the results, and confirm each release into review only once it clears your bar. See Using the API for integrations.
• The app workflow. Read the report on the release page, fix what it flags, and confirm when you’re happy.

Either way, confirming is what moves the release into the normal review queue: nothing enters review until you’ve signed off.

Preflight QC adds a quality stage before review. It doesn’t change what happens after: once you confirm, your release goes through the same validation and review process as any other release.

How to get Preflight QC

Preflight QC is a premium add-on enabled per account by our team. To turn it on for your account, contact our sales team and let them know you’d like Preflight QC.

Once it’s enabled, you’ll see the new hold-and-confirm step the next time you submit a release for distribution.

The Preflight QC workflow

Here’s the full path a release takes with Preflight QC enabled, from submit to review.

1. Submit your release for distribution

Create and complete your release as usual, then submit it for distribution. With Preflight QC enabled, this does not queue the release for review straight away. Instead, the release moves onto a pre-review hold and is marked pending your review.

2. The quality analysis runs

While your release is on hold, Preflight QC analyzes the release end to end. It covers:

• Metadata: titles, artists, credits, and other release and track details
• Release dates: your release date setup and versions
• Audio: your uploaded audio files
• Artwork: your cover image
• AI content: whether AI involvement is declared, and AI-generated music or covers we detect
• Catalog identifiers: whether your ISRCs are valid, and whether a recording has already been claimed by another rights holder
• Prior distribution: whether the release or its tracks are already on stores through another distributor
• Licensing: where a cover, sample, or similar needs supporting documentation

The analysis typically finishes a few minutes after your upload and transcoding complete. While it’s still running, the quality report shows that checks are in progress and doesn’t list any issues yet.

3. Read your quality report

Once the analysis finishes, open the release’s quality report to see what, if anything, needs your attention. You can read it in two places:

• Via the public API, for your own QA pipeline; see Using the API below.
• In the app, on the release page.

The report lists each issue with a clear title and a message describing what to fix. See Understanding the quality report for how to read the fields.

4. Fix what’s flagged

Work through the issues in your report:

• Metadata issues: edit the release or track details.
• Audio or artwork issues: replace the affected file.
• Issues that ask for feedback: reply in the notes thread on the issue, or upload the requested document (for example, a licence for a cover or sample).

Editing your release while it’s on hold marks the current report as stale: the findings no longer reflect the latest state of your release. Edit as much as you like, then request a fresh analysis, from the release page in the app or via the refresh endpoint for integrations. The analysis re-runs and the report refreshes with the new results. You can go around this loop as many times as you need, within a fair-use limit on how many fresh analyses you can start per release per hour.

5. Confirm the release

When your report is clean, or you’ve addressed everything you need to, confirm the release. In the app this is a confirm button on the release; for integrations it’s the confirm endpoint.

Confirming moves the release out of the hold and into the normal review queue. Confirmation requires a completed, up-to-date analysis: if you edited the release after the last run, the report is stale, so request a fresh analysis and let it finish before confirming.

6. Normal review

After you confirm, your release is reviewed exactly like any other release. For what happens during review, review timing, and possible outcomes, see Validation and Review.

Understanding the quality report

The quality report has two parts: a list of issues and a small block of report details about the run itself.

Issues

Each issue in the report describes one thing to look at. The fields you’ll work with:

Field	What it tells you
Title	A short, plain-language name for the issue.
Message	What the issue is and what to do about it.
Severity	How important the issue is, to help you prioritise.
Blocking	Whether the issue must be resolved before you can confirm (see below).
Requires feedback	Whether the issue needs a written reply or an uploaded document from you.
Custom description	Extra detail specific to your release, when it’s available.
Affected tracks	Which tracks the issue applies to. Release-level issues don’t list specific tracks.
Evidence	On date, duplicate, and prior-distribution issues, the matching releases we found, so you can check the conflict yourself (see below).

Blocking vs. informational

• Blocking issues need to be resolved before you can confirm the release for review. Fix what they describe, run a fresh analysis, and they’ll clear from your report.
• Informational issues are there to flag something worth a look, but they don’t stop you from confirming. Review them, and confirm when you’re ready.

Issues that require feedback

Some issues can’t be cleared by editing alone: they need something from you, such as a written explanation or a supporting document (for example, a licence for a cover or sample). These are marked as requires feedback. To resolve one, reply in the notes thread on the issue or upload the requested document before you confirm.

Evidence on an issue

Some issues include evidence to help you check a flag without guesswork: the existing releases we matched against yours. You’ll see it on date, duplicate, and prior-distribution issues. Each match shows the matched track’s title and artist, its release title, release date, and ISRC, plus a link to a store where that release is live, and which of your tracks it affects. Up to three matches are listed per track. Use the evidence to confirm whether the conflict is real (for example, an earlier upload of your own) before you decide how to respond.

The report details

Alongside the issues, the report includes a few details about the run:

Field	What it tells you
generated_at	When the current report was produced. It’s empty while the first analysis is still running.
checks_in_progress	true while the analysis is still running; the issue list will be empty until it finishes.
stale	true when you’ve edited the release (or any of its tracks) after the last completed analysis, so the findings no longer reflect the current state. Any edit counts. Request a fresh analysis to update the report.
hold	Whether the release is currently on the pre-review hold.
review_status	The release’s current review status.
release_status	The overall status of the release itself, alongside the review-specific status.
profile	The quality profile applied to this release, with its name and version.

Using the API for integrations

If you build on the LabelGrid public API, you can wire Preflight QC into your own pipeline: run each release through the quality analysis, pull the report into your own QA workflow, gate your internal approval process on it, and confirm into review from your own tooling. Preflight QC provides three endpoints for this, all using the same Bearer-token authentication as the rest of the public API. For the full, always-current request and response schemas, see the API reference.

Webhook: know when the report is ready

Rather than poll for results, you can have LabelGrid tell you the moment a report is ready. Subscribe to the release.preflight.report_ready webhook event: it fires as soon as Preflight QC finishes analyzing a release on the pre-review hold, including each time a re-analysis you request completes. You get exactly one event per analysis cycle.

Subscribe the same way you subscribe to LabelGrid’s other release webhook events, from your webhook settings in the app or via the API. Each event carries a compact summary of the run, never the issues themselves:

• Release identifiers: release_id, label_id, release_cat, and release_title.
• generated_at: when this report was produced. It matches the report’s own generated_at.
• profile: the quality profile the counts were computed through, as {name, version}.
• counts: the blocking, informational, and requires_feedback totals. The requires_feedback count overlaps the other two.

Use the counts to decide whether you need to act, then fetch the report itself for the detail. The recommended integration pattern:

1. Subscribe to release.preflight.report_ready.
2. On each event, call Get the quality report to read the full set of issues.
3. Fix and re-run: after editing a held release, call the refresh endpoint to start a fresh analysis; the webhook fires again when it completes.
4. Decide and confirm from your own tooling once the release clears your bar.

For the full payload reference and webhook mechanics (signing, retries, and the envelope), see Webhooks.

Get the quality report

GET /v4/public/releases/{id}/quality-report
Authorization: Bearer YOUR_API_TOKEN

Returns the current quality report for the release. The response carries:

• issues[]: one entry per issue, each with id, code (a stable string; see Working with issue codes), title, message, status, severity, is_blocking, requires_feedback, custom_description, and affected_tracks. On date, duplicate, and prior-distribution issues, the entry also carries an evidence array (see below).
• report: generated_at, checks_in_progress, stale, hold, review_status, release_status, and profile (an object with name and version). stale is true when the release or any of its tracks was edited after the last completed analysis; re-run the analysis with the refresh endpoint before confirming.

While the analysis is still running, the report returns checks_in_progress: true with an empty issues list. If you prefer not to use webhooks, poll this endpoint until generated_at is set, typically a few minutes after upload and transcoding finish, then read the issues. To be told the moment the report is ready instead, use the report-ready webhook.

An example response once the analysis has finished:

{
  "issues": [
    {
      "id": "12345",
      "code": "example.issue-code",
      "title": "Short issue title",
      "message": "What to fix and how.",
      "status": "confirmed",
      "severity": "…",
      "is_blocking": true,
      "requires_feedback": false,
      "custom_description": null,
      "affected_tracks": [456],
      "evidence": [
        {
          "affected_track_id": 456,
          "track_title": "Matched track title",
          "artist": "Matched artist",
          "release_title": "Matched release",
          "release_date": "2024-03-01",
          "isrc": "USRC12345678",
          "store_url": "https://…"
        }
      ]
    }
  ],
  "report": {
    "generated_at": "2026-07-07T12:00:00Z",
    "checks_in_progress": false,
    "stale": false,
    "hold": true,
    "review_status": "…",
    "release_status": "…",
    "profile": { "name": "quality_report", "version": 2 }
  }
}

Each evidence item describes one existing release that matched yours: affected_track_id (which of your tracks the match applies to), the matched track_title, artist, release_title, release_date, and isrc, and a store_url pointing to a store page where the match is live. At most three matches are listed per track, and the key is present only on the issue kinds above.

Request a fresh analysis

POST /v4/public/releases/{id}/quality-report/refresh
Authorization: Bearer YOUR_API_TOKEN

Starts a fresh Preflight QC analysis cycle for a held release. Editing a held release does not re-run the checks on its own: it only marks the current report as stale (report.stale: true). When you’ve finished editing, call this endpoint to re-run the analysis; when the cycle completes, the report-ready webhook fires and report.stale returns to false.

A successful call returns 202 Accepted:

{
  "status": "refreshing",
  "checks_in_progress": true,
  "review_status": "pending_customer_review",
  "release_status": "to_review"
}

The call is idempotent while a cycle is running: calling it again returns the same in-progress body, doesn’t queue a second analysis, and doesn’t count against your budget. Other responses you should handle:

• 409 not_in_customer_review_hold: the release isn’t currently held for your Preflight QC review.
• 409 refresh_coalesced: an analysis for this release completed moments ago, so nothing was queued. Retry after the Retry-After header (seconds).
• 429 preflight_recheck_limit_reached: you’ve hit the fair-use budget of 6 started analysis cycles per release per rolling hour. The Retry-After header (seconds) tells you when the next refresh is allowed. Polling an in-progress analysis is free; only starting a new cycle spends budget.
• 403 RELEASE_NOT_VALIDATED: the release must pass validation before a re-analysis can start (the same rule as distributing); run validation first.
• 403 pre_review_qc_not_enabled: Preflight QC isn’t enabled for the owning account.

Confirm the release for review

POST /v4/public/releases/{id}/confirm-review
Authorization: Bearer YOUR_API_TOKEN

Moves the release off the hold and into the normal review queue: the API equivalent of the confirm button in the app.

Confirmation requires a completed, up-to-date analysis. Two conflicts to handle:

• 409 checks_in_progress: the analysis is still running. Wait for the report-ready webhook (or poll until generated_at is set), then retry.
• 409 checks_stale: the release was edited after the last completed analysis (report.stale is true). Call the refresh endpoint, wait for the fresh report, then retry the confirm.

Note

While a release is on the pre-review hold, submitting it through the normal distribute path returns 409 preflight_recheck_required: a held release exits the hold only through the refresh-and-confirm flow described here.

Working with issue codes

If you build logic on top of the quality report, key it on the issue code:

• code is a stable string in slug format (for example, audio.trailing-silence). It’s safe to map codes in your system and build logic on them.
• Titles and messages are human-facing copy. They may be refined over time, so never key logic on the text; use it for display only.
• New codes can appear as Preflight QC’s coverage expands. Handle codes you don’t recognize generically: render the title and message from the payload instead of failing.
• Your reports teach you the codes that matter. As you run releases through Preflight QC, the codes relevant to your catalog surface naturally in your own quality reports.
• What the analysis covers. Issues fall into these categories: release & track metadata, release dates & versions, audio quality, artwork, AI content, catalog identifiers, prior distribution, and licensing & documentation.

The issue catalog

To map issues when building your own QA workflow, retrieve the complete issue catalog programmatically:

GET /v4/public/issue-definitions
Authorization: Bearer YOUR_API_TOKEN

This returns every issue that can appear in a quality report, keyed by its stable string code, with the title, message template, severity, blocking flag, requires_feedback, and its category (type). The response also carries the quality profile the catalog was computed through, as {name, version}. The endpoint is available only to accounts with the Preflight QC add-on.

FAQ

What if the analysis is still running?

The report will show checks_in_progress: true with no issues listed yet. This is normal right after you submit. Give it a few minutes after your upload and transcoding finish, then check again: in the app the report refreshes on its own. Via the API you can subscribe to the report-ready webhook to be pushed a notification the moment it’s ready, or poll until generated_at is set.

Can I edit my release while it’s on hold?

Yes, edit as freely as you like: a release on the pre-review hold stays fully editable. Editing doesn’t re-run the checks by itself; it marks the current report as stale. When you’ve finished your changes, request a fresh analysis (from the release page in the app, or the refresh endpoint for integrations) to see the updated results without leaving the hold. The fresh analysis needs to complete before you can confirm.

What happens after I confirm?

Your release leaves the hold and joins the normal review queue, where it’s reviewed like any other release. See Validation and Review for how review works, how long it takes, and the possible outcomes.

Can I take a release back to draft?

Yes: while your release is on the pre-review hold and you haven’t confirmed it yet, it hasn’t entered review, so you’re free to keep editing it or leave it as a draft and come back later. It only enters the review queue once you confirm.

Do I have to fix every issue before confirming?

You must resolve blocking issues before you can confirm. Informational issues don’t stop you from confirming, but they’re worth a look: clearing up as much as you can before review is the quickest route to approval.

---

Questions about Preflight QC? Contact our team. We’re happy to help.