Preflight QC

Preflight QC är ett premiumtillägg som ger dig professionell release-QC. Skicka in en release så analyserar Preflight QC den från början till slut: metadata, releasedatum, ljud, omslag, AI-innehåll, katalogidentifierare, tidigare distribution och licensdokumentation. Du får en tydlig, användbar kvalitetsrapport. Åtgärda det den flaggar i din egen takt och bekräfta sedan releasen för granskning när du är nöjd.

För bolag och API-integratörer fungerar Preflight QC som en byggsten. Hämta kvalitetsrapporten programmatiskt, koppla in den i din egen QA-pipeline, låt din interna godkännandeprocess styras av den och bekräfta releaser för granskning automatiskt. Ditt team sätter kvalitetsribban, och Preflight QC gör analysen.

En release som kommer in ren går snabbt genom granskningen. Preflight QC tar dig dit innan du skickar in.

Vad Preflight QC är

Med Preflight QC aktiverat på ditt konto går en release som skickas in för distribution inte direkt in i granskningskön. I stället hamnar releasen i ett vänteläge före granskning (“väntar på din genomgång”) medan Preflight QC gör sin kvalitetsanalys: metadata, releasedatum, ljud, omslag, AI-innehåll, katalogidentifierare, tidigare distribution och licensdokumentation. Resultatet är en kvalitetsrapport, och vad du bygger på den är upp till dig:

• Ditt eget QA-flöde (API). Kör din katalog genom kvalitetsanalysen, hämta rapporten programmatiskt i din egen QA-pipeline, låt din interna godkännandeprocess styras av resultaten och bekräfta varje release för granskning först när den klarar din ribba. Se Använda API:et för integrationer.
• Flödet i appen. Läs rapporten på releasesidan, åtgärda det den flaggar och bekräfta när du är nöjd.

I båda fallen är det bekräftelsen som flyttar releasen till den vanliga granskningskön: inget går in i granskning förrän du gett klartecken.

Preflight QC lägger till ett kvalitetssteg före granskningen. Det ändrar inget i vad som händer efteråt: så snart du bekräftar går din release genom samma validerings- och granskningsprocess som vilken annan release som helst.

Så får du Preflight QC

Preflight QC är ett premiumtillägg som vårt team aktiverar per konto. För att slå på det för ditt konto, kontakta vårt säljteam och meddela att du vill ha Preflight QC.

När det är aktiverat ser du det nya vänte- och bekräftelsesteget nästa gång du skickar in en release för distribution.

Arbetsflödet i Preflight QC

Här är hela resan för en release med Preflight QC aktiverat, från insändning till granskning.

1. Skicka in din release för distribution

Skapa och färdigställ din release som vanligt och skicka sedan in den för distribution. Med Preflight QC aktiverat placerar detta inte releasen i granskningskön direkt. I stället går releasen till ett vänteläge före granskning och markeras som väntar på din genomgång.

2. Kvalitetsanalysen körs

Medan din release är i vänteläge analyserar Preflight QC den från början till slut. Analysen täcker:

• Metadata: titlar, artister, medverkande och andra uppgifter om releasen och spåren
• Releasedatum: dina datuminställningar och releaseversioner
• Ljud: de ljudfiler du har laddat upp
• Omslag: din omslagsbild
• AI-innehåll: om användning av AI har angetts, och AI-genererad musik eller omslag som vi upptäcker
• Katalogidentifierare: om dina ISRC-koder är giltiga och om en inspelning redan har hävdats av en annan rättighetshavare
• Tidigare distribution: om releasen eller dess spår redan finns i butikerna via en annan distributör
• Licenser: när en cover, ett sample eller liknande behöver styrkande dokumentation

Analysen är oftast klar någon minut efter att uppladdningen och transkodningen har slutförts. Medan den fortfarande pågår anger kvalitetsrapporten att kontrollerna pågår och listar ännu inga problem.

3. Läs din kvalitetsrapport

När analysen är klar öppnar du releasens kvalitetsrapport för att se vad som, om något, behöver din uppmärksamhet. Du kan läsa den på två ställen:

• Via det publika API:et, för din egen QA-pipeline; se Använda API:et nedan.
• I appen, på releasesidan.

Rapporten listar varje problem med en tydlig titel och ett meddelande som beskriver vad som ska åtgärdas. Se Förstå kvalitetsrapporten för hur du läser fälten.

4. Åtgärda det som flaggas

Gå igenom problemen i din rapport:

• Metadataproblem: redigera uppgifterna för releasen eller spåret.
• Ljud- eller omslagsproblem: byt ut den berörda filen.
• Problem som ber om återkoppling: svara i problemets anteckningstråd, eller ladda upp det begärda dokumentet (till exempel en licens för en cover eller ett sample).

Att redigera din release medan den är i vänteläge markerar den aktuella rapporten som inaktuell: resultaten återspeglar inte längre releasens senaste tillstånd. Redigera så mycket du vill och begär sedan en ny analys, från releasesidan i appen eller via uppdaterings-endpointen för integrationer. Analysen körs om och rapporten uppdateras med de nya resultaten. Du kan gå detta varv så många gånger du behöver, inom en fair use-gräns för hur många nya analyser du kan starta per release och timme.

5. Bekräfta releasen

När din rapport är ren, eller du har åtgärdat allt du behövde, bekräftar du releasen. I appen är det en bekräfta-knapp på releasen; för integrationer är det bekräftelse-endpointen.

Bekräftelsen tar releasen ur väntläget och flyttar den till den vanliga granskningskön. Bekräftelse kräver en färdig, aktuell analys: om du har redigerat releasen efter den senaste körningen är rapporten inaktuell, så begär en ny analys och låt den slutföras innan du bekräftar.

6. Vanlig granskning

Efter bekräftelsen granskas din release precis som vilken annan som helst. För vad som händer under granskningen, hur lång tid den tar och de möjliga utfallen, se Validering och granskning.

Förstå kvalitetsrapporten

Kvalitetsrapporten har två delar: en lista med problem och ett litet block med rapport-detaljer om analyskörningen.

Problem

Varje problem i rapporten beskriver något att titta på. Fälten du kommer att arbeta med:

Fält	Vad det säger dig
Titel	Ett kort, lättbegripligt namn på problemet.
Meddelande	Vad problemet är och vad du ska göra åt det.
Allvarlighetsgrad	Hur viktigt problemet är, för att hjälpa dig prioritera.
Blockerande	Om problemet måste lösas innan du kan bekräfta (se nedan).
Kräver återkoppling	Om problemet behöver ett skriftligt svar eller ett uppladdat dokument från dig.
Anpassad beskrivning	Extra detaljer som är specifika för din release, när sådana finns.
Berörda spår	Vilka spår problemet gäller. Problem på releasenivå listar inga specifika spår.
Underlag	Vid problem om datum, dubbletter och tidigare distribution, de matchande releaser vi hittade, så att du kan kontrollera konflikten själv (se nedan).

Blockerande eller informativt

• Blockerande problem måste lösas innan du kan bekräfta releasen för granskning. Åtgärda det de beskriver, kör en ny analys, så försvinner de från din rapport.
• Informativa problem finns där för att flagga något som är värt en titt, men de hindrar dig inte från att bekräfta. Titta igenom dem och bekräfta när du är redo.

Problem som kräver återkoppling

Vissa problem går inte att lösa enbart genom att redigera: de behöver något från dig, som en skriftlig förklaring eller ett styrkande dokument (till exempel en licens för en cover eller ett sample). De är markerade som kräver återkoppling. För att lösa ett sådant, svara i problemets anteckningstråd eller ladda upp det begärda dokumentet innan du bekräftar.

Underlag för ett problem

Vissa problem innehåller underlag så att du kan kontrollera en flagg utan gissningar: de befintliga releaser vi matchade mot din. Du ser det vid problem om datum, dubbletter och tidigare distribution. Varje matchning visar det matchande spårets titel och artist, dess releasetitel, releasedatum och ISRC, plus en länk till en butik där den releasen är live, och vilket av dina spår den berör. Upp till tre matchningar listas per spår. Använd underlaget för att bekräfta om konflikten är verklig (till exempel en tidigare uppladdning av dig själv) innan du bestämmer hur du ska svara.

Rapportdetaljerna

Vid sidan av problemen innehåller rapporten några detaljer om analyskörningen:

Fält	Vad det säger dig
generated_at	När den aktuella rapporten togs fram. Det är tomt medan den första analysen fortfarande pågår.
checks_in_progress	true medan analysen fortfarande pågår; problemlistan är tom tills den är klar.
stale	true när du har redigerat releasen (eller något av dess spår) efter den senaste slutförda analysen, så att resultaten inte längre återspeglar det aktuella tillståndet. Varje redigering räknas. Begär en ny analys för att uppdatera rapporten.
hold	Om releasen just nu är i väntläget före granskning.
review_status	Releasens aktuella granskningsstatus.
release_status	Releasens övergripande status i sig, vid sidan av den granskningsspecifika statusen.
profile	Den kvalitetsprofil som tillämpas på den här releasen, med dess namn och version.

Använda API:et för integrationer

Om du bygger på LabelGrids publika API kan du koppla in Preflight QC i din egen pipeline: kör varje release genom kvalitetsanalysen, hämta rapporten i ditt eget QA-flöde, låt din interna godkännandeprocess styras av den och bekräfta för granskning från dina egna verktyg. Preflight QC tillhandahåller tre endpoints för detta, alla med samma Bearer-token-autentisering som resten av det publika API:et. För de fullständiga och alltid aktuella request- och response-scheman, se API-referensen.

Webhook: få veta när rapporten är klar

I stället för att polla efter resultat kan du låta LabelGrid meddela dig i samma stund som en rapport är klar. Prenumerera på webhook-händelsen release.preflight.report_ready: den utlöses så snart Preflight QC är klar med att analysera en release i vänteläget före granskning, inklusive varje gång en omanalys som du begär slutförs. Du får exakt en händelse per analyscykel.

Prenumerera på samma sätt som du prenumererar på LabelGrids andra release-webhook-händelser, från dina webhook-inställningar i appen eller via API:et. Varje händelse bär med sig en kompakt sammanfattning av körningen, aldrig själva problemen:

• Release-identifierare: release_id, label_id, release_cat och release_title.
• generated_at: när denna rapport togs fram. Den matchar rapportens egen generated_at.
• profile: kvalitetsprofilen som antalen beräknades genom, som {name, version}.
• counts: totalsummorna för blocking, informational och requires_feedback. Antalet requires_feedback överlappar de andra två.

Använd antalen för att avgöra om du behöver agera, och hämta sedan själva rapporten för detaljerna. Det rekommenderade integrationsmönstret:

1. Prenumerera på release.preflight.report_ready.
2. Vid varje händelse anropar du Hämta kvalitetsrapporten för att läsa hela uppsättningen problem.
3. Åtgärda och kör om: efter att du redigerat en release i vänteläge anropar du uppdaterings-endpointen för att starta en ny analys; webhooken utlöses igen när den slutförs.
4. Besluta och bekräfta från dina egna verktyg när releasen klarar din ribba.

För den fullständiga payload-referensen och webhook-mekaniken (signering, återförsök och kuvertet), se Webhooks.

Hämta kvalitetsrapporten

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

Returnerar releasens aktuella kvalitetsrapport. Svaret innehåller:

• issues[]: en post per problem, var och en med id, code (en stabil sträng; se Arbeta med problemkoder), title, message, status, severity, is_blocking, requires_feedback, custom_description och affected_tracks. Vid problem om datum, dubbletter och tidigare distribution bär posten även med sig en evidence-array (se nedan).
• report: generated_at, checks_in_progress, stale, hold, review_status, release_status och profile (ett objekt med name och version). stale är true när releasen eller något av dess spår redigerades efter den senaste slutförda analysen; kör analysen på nytt med uppdaterings-endpointen innan du bekräftar.

Medan analysen fortfarande pågår returnerar rapporten checks_in_progress: true med en tom issues-lista. Om du hellre slipper webhooks kan du polla den här endpointen tills generated_at är satt, vanligtvis någon minut efter att uppladdningen och transkodningen är klara, och sedan läsa problemen. För att i stället få veta i samma stund som rapporten är klar, använd report-ready-webhooken.

Ett exempelsvar när analysen är klar:

{
  "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 }
  }
}

Varje evidence-objekt beskriver en befintlig release som matchade din: affected_track_id (vilket av dina spår matchningen gäller), det matchande track_title, artist, release_title, release_date och isrc, samt en store_url som pekar på en butikssida där matchningen är live. Högst tre matchningar listas per spår, och nyckeln finns bara på ovanstående problemtyper.

Begär en ny analys

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

Startar en ny Preflight QC-analyscykel för en release i vänteläge. Att redigera en release i vänteläge kör inte om kontrollerna av sig självt: det markerar bara den aktuella rapporten som inaktuell (report.stale: true). När du är klar med att redigera, anropa den här endpointen för att köra om analysen; när cykeln slutförs utlöses report-ready-webhooken och report.stale återgår till false.

Ett lyckat anrop returnerar 202 Accepted:

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

Anropet är idempotent medan en cykel pågår: att anropa det igen returnerar samma pågående svar, köar inte en andra analys och räknas inte mot ditt budget. Andra svar du bör hantera:

• 409 not_in_customer_review_hold: releasen är för närvarande inte i vänteläge för din Preflight QC-granskning.
• 409 refresh_coalesced: en analys för den här releasen slutfördes nyss, så ingenting köades. Försök igen efter Retry-After-headern (sekunder).
• 429 preflight_recheck_limit_reached: du har nått fair use-budgeten på 6 startade analyscykler per release per rullande timme. Retry-After-headern (sekunder) talar om när nästa uppdatering är tillåten. Att polla en pågående analys är gratis; bara att starta en ny cykel förbrukar budget.
• 403 RELEASE_NOT_VALIDATED: releasen måste klara valideringen innan en omanalys kan starta (samma regel som vid distribution); kör valideringen först.
• 403 pre_review_qc_not_enabled: Preflight QC är inte aktiverat för det ägande kontot.

Bekräfta releasen för granskning

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

Tar releasen ur väntläget och flyttar den till den vanliga granskningskön: API-motsvarigheten till bekräfta-knappen i appen.

Bekräftelse kräver en färdig, aktuell analys. Två konflikter att hantera:

• 409 checks_in_progress: analysen pågår fortfarande. Vänta på report-ready-webhooken (eller polla tills generated_at är satt) och försök sedan igen.
• 409 checks_stale: releasen redigerades efter den senaste slutförda analysen (report.stale är true). Anropa uppdaterings-endpointen, vänta på den nya rapporten och försök sedan bekräfta igen.

Note

Medan en release är i vänteläget före granskning returnerar ett försök att skicka in den via det vanliga distributionsflödet 409 preflight_recheck_required: en release i vänteläge lämnar det bara via det uppdatera-och-bekräfta-flöde som beskrivs här.

Arbeta med problemkoder

Om du bygger logik ovanpå kvalitetsrapporten, basera den på problemets code:

• code är en stabil sträng i slug-format (till exempel audio.trailing-silence). Du kan tryggt mappa koderna i ditt system och bygga logik på dem.
• Titlar och meddelanden är texter för människor. De kan finslipas över tid, så basera aldrig din logik på texten; använd den bara för visning.
• Nya koder kan tillkomma i takt med att Preflight QC:s täckning utökas. Hantera okända koder generiskt: visa title och message från svaret i stället för att fallera.
• Dina rapporter lär dig vilka koder som räknas. I takt med att du kör releaser genom Preflight QC dyker de koder som är relevanta för din katalog upp naturligt i dina egna kvalitetsrapporter.
• Vad analysen täcker. Problemen faller inom dessa kategorier: release- och spårmetadata, releasedatum och versioner, ljudkvalitet, omslag, AI-innehåll, katalogidentifierare, tidigare distribution samt licenser och dokumentation.

Problemkatalogen

För att mappa problemen när du bygger ditt eget QA-flöde, hämta hela katalogen programmatiskt:

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

Den returnerar varje problem som kan dyka upp i en kvalitetsrapport, nycklat på sin stabila strängkod, med titel, meddelandemall, allvarlighetsgrad, blockeringsflagga, requires_feedback och dess kategori (type). Svaret innehåller även kvalitetsprofilen som katalogen beräknades genom, som {name, version}. Endpointen är bara tillgänglig för konton med Preflight QC-tillägget.

Vanliga frågor

Vad händer om analysen fortfarande pågår?

Rapporten visar checks_in_progress: true utan några problem listade ännu. Det är normalt precis efter att du skickat in. Vänta någon minut efter att uppladdningen och transkodningen är klara och titta sedan igen: i appen uppdateras rapporten av sig själv. Via API:et kan du prenumerera på report-ready-webhooken för att få en avisering pushad i samma stund som den är klar, eller polla tills generated_at är satt.

Kan jag redigera min release medan den är i väntläge?

Ja, redigera precis så fritt du vill: en release i vänteläget före granskning förblir helt redigerbar. Redigering kör inte om kontrollerna av sig självt; den markerar den aktuella rapporten som inaktuell. När du är klar med dina ändringar, begär en ny analys (från releasesidan i appen, eller uppdaterings-endpointen för integrationer) för att se de uppdaterade resultaten utan att lämna vänteläget. Den nya analysen måste slutföras innan du kan bekräfta.

Vad händer efter att jag bekräftat?

Din release lämnar väntläget och ansluter sig till den vanliga granskningskön, där den granskas som vilken annan som helst. Se Validering och granskning för hur granskningen fungerar, hur lång tid den tar och de möjliga utfallen.

Kan jag ta tillbaka en release till utkast?

Ja: så länge din release är i väntläget före granskning och du inte har bekräftat den ännu har den inte gått in i granskning, så du är fri att fortsätta redigera den eller lämna den som utkast och återkomma senare. Den går in i granskningskön först när du bekräftar den.

Måste jag åtgärda varje problem innan jag bekräftar?

Du måste lösa blockerande problem innan du kan bekräfta. Informativa problem hindrar dig inte från att bekräfta, men de är värda en titt: att röja undan så mycket som möjligt före granskningen är den snabbaste vägen till godkännande.

---

Frågor om Preflight QC? Kontakta vårt team. Vi hjälper dig gärna.