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, 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, 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
• 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 re-runs the relevant parts of the analysis, and the report refreshes with the new results. You can go around this loop as many times as you need.

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 the analysis to be complete: if you edited the release after the last run, wait for the refreshed report 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.

Blocking vs. informational

• Blocking issues need to be resolved before you can confirm the release for review. Fix what they describe, let the analysis re-run, 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.

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.
hold	Whether the release is currently on the pre-review hold.
review_status	The release’s current review status.
profile	The quality profile applied to this release.

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 two endpoints for this, both 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.

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 code (a stable string; see Working with issue codes), title, message, severity, is_blocking, requires_feedback, custom_description, and affected_tracks.
• report: generated_at, checks_in_progress, hold, review_status, and profile.

While the analysis is still running, the report returns checks_in_progress: true with an empty issues list. Poll the endpoint until generated_at is set, typically a few minutes after upload and transcoding finish, then read the issues.

An example response once the analysis has finished:

{
  "issues": [
    {
      "code": "example.issue-code",
      "title": "Short issue title",
      "message": "What to fix and how.",
      "severity": "…",
      "is_blocking": true,
      "requires_feedback": false,
      "custom_description": null,
      "affected_tracks": [456]
    }
  ],
  "report": {
    "generated_at": "2026-07-07T12:00:00Z",
    "checks_in_progress": false,
    "hold": true,
    "review_status": "…",
    "profile": "…"
  }
}

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 the analysis to be complete. If the release was edited after the last run, the report is regenerating, and the endpoint returns a conflict. When that happens, re-fetch the quality report, wait until generated_at is set again, and retry the confirm.

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, 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, and requires_feedback. 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, and via the API you can poll until generated_at is set.

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

Yes. Editing a release on the pre-review hold re-runs the relevant parts of the analysis and refreshes the report, so you can fix issues and see the updated results without leaving the hold. Just remember that after an edit you’ll need to wait for the refreshed report 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.