A Buzzsprout API már epizódot is publikál, webhook viszont továbbra sincs

|Szerző: A QUASA szerkesztősége|5 perc olvasás
A Buzzsprout API már epizódot is publikál, webhook viszont továbbra sincs

A Buzzsprout a 2026. október 9-i API-bővítésével lehetővé tette, hogy külső alkalmazások epizódot töltsenek fel, átiratot szerkesszenek és podcastkatalógusok adatait kezeljék. Az epizód létrehozása után a publikálás is elvégezhető az API-n keresztül. A média feldolgozását és a későbbi állapotváltozásokat azonban a kliensnek kell lekérdezésekkel követnie.

A RYM Magazine október 14-i beszámolója szintén az epizódfeltöltést, az átiratszerkesztést és a katalóguskezelést nevezi meg a bővítés részeként. A podcastkészítő számára a változás lényege, hogy a privát epizód létrehozásától a nyilvános megjelenésig összekapcsolhatók a műveletek. A feltöltött fájl feldolgozása közben ugyanakkor külön ellenőrzési pont marad.

Privát epizódból lesz publikált adás

A folyamat a podcast azonosítójának lekérésével és egy privát epizód létrehozásával indul. A létrehozáshoz cím szükséges; a leírás, az epizódszám és más adatok ekkor vagy egy későbbi frissítéskor is megadhatók. A privát állapot lehetőséget ad arra, hogy az epizód már rendelkezzen saját azonosítóval a további műveletekhez, miközben a hallgatók számára még nem jelenik meg.

A hang- vagy videófájl csatolása külön feltöltési folyamat. Az alkalmazás először közli a fájl nevét, méretét és médiatípusát, majd a kapott feltöltési címre küldi a fájl bájtjait. Ezután le kell zárnia a feltöltést: ez a művelet kapcsolja a médiát az epizódhoz és indítja el a feldolgozást. A bájtok sikeres átküldése önmagában tehát még nem jelenti azt, hogy a média az epizód része vagy már lejátszható.

A feltöltési címre küldött kérésnél a Buzzsprout API-tokenjét sem kell továbbítani. A token az API-hívások hitelesítésére szolgál, míg a fájl a feltöltés megkezdésekor visszakapott címre kerül. A kliensnek a ténylegesen elküldött bájtok számát is a korábban megadott fájlmérethez kell igazítania, mert eltérés esetén a feltöltés lezárása hibával végződhet.

A lezárás után a média feldolgozása aszinkron módon történik. Az epizód lekérésével ellenőrizhető, hogy az időtartam mező már pozitív értéket mutat-e; ez a dokumentált jelzés arra, hogy a kódolás befejeződött. Ezután következhet a privát epizód adatainak ellenőrzése, szükség esetén a borítókép, a fejezetek vagy a közreműködők hozzáadása, végül a privát jelölés feloldása. A publikálás jövőbeli időpontra is ütemezhető a publikálási idő megadásával.

Az átirat két külön erőforrás lehet

Az átirat szerkesztése attól függ, milyen változat tartozik az epizódhoz. A Buzzsprout által létrehozott részletes átirat időbélyegzett szegmensekből áll; ezek szövege lekérhető és módosítható. Az API ezt a változatot nem tudja önállóan létrehozni. Ha az epizódhoz még nem tartozik ilyen átirat, a szegmensek frissítésére irányuló művelet sem pótolja az átírás elkészülését.

A készítő saját nyilvános átiratfájlt is feltölthet vagy lecserélhet. Ez külön erőforrás: a saját fájl feltöltése nem indítja el a Buzzsprout átírását, eltávolítása pedig nem törli a szolgáltatás által készített szegmenseket. A nyilvános átirat lekérése a megjelenített változatra vonatkozik, míg a részletes, szerkeszthető szegmensekhez másik API-művelet tartozik. Egy automatizált szerkesztési folyamatban ezért számít, hogy a végleges, közönségnek szánt fájlt vagy az időzített szövegrészeket módosítja az alkalmazás.

A két változat elválasztása a privát ellenőrzésnél is hasznos. A feldolgozás után a szerkesztő javíthatja a rendelkezésre álló szegmenseket, vagy feltöltheti a már véglegesített nyilvános átiratot, mielőtt az epizód megjelenik. A hangfájl feltöltése és az átirat kezelése így ugyanannak a publikálási folyamatnak a része lehet, de egyik művelet sikere nem igazolja automatikusan a másik eredményét.

A katalógusba küldés a podcast állapotától függ

A katalóguskezelés a teljes podcastra vonatkozik, nem az adott epizód publikálási kapcsolójára. Az API-val lekérhető, hogy egy műsor mely katalógusokban szerepel, melyekbe küldték már be, és hol maradt listázatlan vagy sikertelen a folyamat. A megfelelő jogosultságú fióktulajdonos vagy adminisztrátor elindíthatja a még elérhető, automatikusan beküldhető katalógusokba történő beküldést.

A beküldési kérés elfogadása nem jelent azonnali listázást. A későbbi állapotot újabb lekérdezés mutatja meg; a kézi eljárást igénylő katalógusokat az automatikus művelet nem intézi el. Ez különösen egy új műsornál lényeges, mert a beküldéshez publikált epizód, borítókép, leírás, szerző és kategória is szükséges. Ha ezek közül valamelyik hiányzik, a katalógusművelet nem válthatja ki a podcast adatainak befejezését.

Az állapotkövetés a külső alkalmazás feladata

A Buzzsprout API-oldala szerint a hozzáférés minden csomag része, epizódok automatikusan létrehozhatók és frissíthetők, webhook azonban nincs: az állapotkövetés lekérdezéssel működik. Az API használatához podcasttal rendelkező Buzzsprout-fiók és ahhoz kötött token szükséges. Így a publikálási művelet elindítható külső rendszerből, de a feldolgozás befejezéséről nem érkezik külön eseményértesítés ugyanoda.

A kliens a feltöltés lezárása után ismételten lekérheti az epizódot, amíg az időtartam alapján a média elkészültnek nem tekinthető. Hasonló lekérdezésre van szükség a katalógusba küldés későbbi eredményének megállapításához. A két várakozás különböző erőforrásra vonatkozik: az egyik az epizód médiájának feldolgozását, a másik a podcast katalógusállapotát figyeli. Ettől függ, hogy az automatizálás melyik művelet után léphet tovább.

A lekérdezések terhelését feltételes HTTP-kérések mérsékelhetik. Ha egy válasz ETag vagy Last-Modified fejlécet tartalmaz, a kliens ezt felhasználhatja a következő kérésben; változatlan erőforrás esetén nem kell ismét letöltenie a teljes választ. A lekérdezések között várakozni is célszerű, különösen a média aszinkron feldolgozásakor. Az automatizálás megbízhatósága végül azon múlik, hogy a külső rendszer a feldolgozás tényleges befejezéséhez, majd a privát jelölés tudatos feloldásához köti-e a megjelenést.

Olvassa el ezt is:

Megosztás:

Kapcsolódó cikkek

Iratkozzon fel hírlevelünkre

A legfrissebb Web3-, MI- és kriptohírek egyenesen a postafiókjába.

0