API-integráció

TikTok Posting API a sorbiztos, több fiókos terjesztéshez

Készíts TikTok-közzétételi munkafolyamatokat explicit állapotkövetéssel, retry-biztos orkesztrációval és moderációtudatos kezeléssel, éles, nagy léptékű csapatok számára.

Probléma

Nagy léptékben a terjesztés ott bukik el, ahol a közzététel még manuális: a feltöltési/publikálási műveletek törékennyé válnak sok fiók, ütemezés és moderációs állapot között.

Eredmény a Ssemble segítségével

A Ssemble támogatja a tartalomgenerálást és az állapot-orkesztrációt, miközben a TikTok-közzétételi réteged kontrollált publikálásokat hajt végre idempotenciával, újrapróbálkozásokkal és auditálható feladatállapotokkal.

Megvalósítási alapok

Base URL: https://aiclipping.ssemble.com/api/v1 (+ TikTok Open API for publish)

Integrációs architektúra (betöltés → feldolgozás → poll/webhook → publikálás)

1) Betöltés

Tárold a forrás URL-t/fájl URL-t + célfiókot + scheduleAt-et + idempotency key-t a publisher feladatmodellben.

2) Feldolgozás

Hívd meg a POST /shorts/create-et, tárold a requestId-t, és csatold a downstream közzétételi feladatokhoz.

3) Poll / Webhook

Mozgasd a feladatokat processing/ready/failed állapotokon keresztül a GET /shorts/:id/status és event fallbackek segítségével.

4) Publikálás

Indíts TikTok-publikálást fiókonkénti konkurenciakorlátokkal, retry-szabályzattal és végleges állapot-egyeztetéssel.

Endpoint-példák

POST /shorts/create— Rövid formátumú tartalom generálása közzététel előtt
GET /shorts/:id/status— A feldolgozási életciklus és a failureReason követése
GET /shorts/:id— A befejezett kimenet metaadatainak lekérése közzétételhez

Hitelesítési útmutató

Használj X-API-Key-t szerveroldalon a Ssemble-höz, és tartsd a TikTok OAuth tokeneket izoláltan a közzétételi szolgáltatásodban. Rotáld az egyes kulcskészleteket egymástól függetlenül, környezetenként.

Rate limit-ek és újrapróbálkozások

Kezeld a generálást és a közzétételt külön keretként. Sorosítsd a módosító hívásokat célfiókonként, és 429 esetén tartsd be a reset/retryAfter értéket exponenciális backoff + jitter mellett.

Kéréspélda

POST /api/publish/tiktok
{
  "jobId": "job_01HT...",
  "requestId": "665a1b2c3d4e5f6a7b8c9d0e",
  "tiktokAccountId": "acct_kor_store_03",
  "scheduleAt": "2026-03-10T18:00:00Z",
  "idempotencyKey": "2f182b63-312f-4290-9222-7cf6f7f8f12d"
}

Válaszpélda

200 OK
{
  "jobId": "job_01HT...",
  "state": "publish_processing",
  "publishId": "v_inbox_file~v2.123456789",
  "nextCheckAt": "2026-03-10T18:00:30Z"
}

Hibaforgatókönyv-példa

429 Too Many Requests
{
  "error": {
    "code": "rate_limit_exceeded",
    "message": "Per-account posting throttle reached",
    "details": { "retryAfter": "2026-03-10T18:01:00Z" }
  }
}

Verziókezelés

Rögzítsd az endpoint-verziókat, és naplózd az upstream verzió-metaadatokat kérésenként, hogy az integrációs regressziók nyomon követhetők legyenek.

Támogatás

Incidensek osztályozásához tárold a requestId + publish_id + account id + error.code + upstream log_id értékeket egyetlen lekérdezhető rekordban.

Gyors kezdés

Hozz létre egy SSEMBLE_API_KEY-t, és tárold a backend secrets között.
Hívd meg a POST /shorts/create-et, és tárold a requestId-t a feladattábládban.
Poll-ozd a GET /shorts/:id/status-t 10 másodpercenként a végállapotig.
A completed állapotnál publikálj a TikTokra a szerveroldali soron keresztül.
Kezeld a 429/5xx eseteket korlátozott újrapróbálkozásokkal és stabil idempotency key-ekkel.

TikTok-közzétételi dokumentáció megnyitása

Integráció indítása

1) Hitelesítés

API-kulcs formátuma és hitelesítési hibakezelés

2) Endpoint-referencia

Create/status/list/delete szerződések

3) Hibakezelés

Újrapróbálható vs. végleges hibaminták

4) Kódpéldák

Megvalósításra kész integrációs kódrészletek

3 lépéses munkafolyamat

Generálj rövid formátumú tartalmakat, és tárold a requestId-t, valamint a publikálási kontextust a feladattábládban.
Kövesd a feldolgozást állapot-pollinggal vagy webhookokkal, és mozgasd a feladatokat ready/failed állapotokba determinisztikusan.
Publikálj a TikTokra fiókonkénti throttle-vezérléssel, idempotency key-ekkel és egyeztetési naplókkal.

Miért a Ssemble-t választják a csapatok

Több fiókos terjesztési csapatoknak készült, ahol a sor megbízhatósága fontosabb, mint az egyszeri siker.
Elkülöníti a renderelést és a közzétételt, így a hibák izoláltak és helyreállíthatók.
Moderációtudatos állapotkezelést támogat: a feltöltés befejeződése nem mindig jelenti a végleges nyilvános elérhetőséget.

Következő lépés

TikTok-közzétételi gyors kezdés megnyitása Árazás megtekintése Fejlesztői dokumentáció

GYIK

Tekinthetjük a feltöltés sikerét publikáltnak?

Nem mindig. Tarts külön állapotokat az uploaded, submitted, publish_complete és publicly_available számára, hogy elkerüld a téves pozitívokat.

Melyik lépésnek kell idempotensnek lennie?

Minimum a publikálás indításának. Használj egyetlen stabil idempotency key-t feladatonként, hogy az újrapróbálkozások ne hozzanak létre duplikátumokat.

Polling vagy webhookok: melyiket használjuk?

Használd a webhookokat elsődlegesként, ha elérhetők, és tartsd meg a pollingot fallbackként az egyeztetéshez és az elmulasztott eseményekhez.

Hogyan kerüljük el a 429-es kilengéseket sok fiók között?

Shardold a sorokat célfiókonként, és érvényesíts fiókonkénti konkurenciakorlátokat egyetlen globális kilengő sor helyett.

Milyen naplók kötelezők az incidenskezeléshez?

Rögzítsd a requestId-t, publish_id-t, account id-t, az állapotátmeneteket és a hibakódot a determinisztikus hibakeresés támogatásához.

Garantálja ez a moderáció befejezésének idejét?

Nem. A moderációs ablakok változóak, ezért az éles rendszereknek a végleges elérhetőség időzítését aszinkronként és változóként kell kezelniük.