API-integration
TikTok Posting API för kösäker distribution över flera konton
Leverera arbetsflöden för TikTok-publicering med explicit statusspårning, retry-säker orkestrering och moderationsmedveten hantering för team i produktionsskala.
Problem
I stor skala fallerar distribution där publicering fortfarande sker manuellt: åtgärder för upload/publicering blir sköra över många konton, scheman och moderationstillstånd.
Resultat med Ssemble
Ssemble stöder innehållsgenerering och statusorkestrering medan ditt TikTok-publiceringslager utför kontrollerade publiceringar med idempotency, retries och spårbara jobbtillstånd.
Grunder för implementation
Bas-URL: https://aiclipping.ssemble.com/api/v1 (+ TikTok Open API for publish)
Integrationsarkitektur (ingest → bearbeta → poll/webhook → publicera)
1) Ingest
Lagra käll-URL/fil-URL + destinationskonto + scheduleAt + idempotency-nyckel i din publiceringsjobbmodell.
2) Bearbeta
Anropa POST /shorts/create, spara requestId och koppla det till efterföljande publiceringsjobb.
3) Poll / Webhook
Flytta jobb genom processing/ready/failed-tillstånd med GET /shorts/:id/status och event-fallbacks.
4) Publicera
Utlös TikTok-publicering med concurrency-tak per konto, retry-policy och slutlig statusavstämning.
Exempel på endpoints
POST /shorts/create— Generera resurs för kortformat före publiceringGET /shorts/:id/status— Spåra bearbetningslivscykel och failureReasonGET /shorts/:id— Hämta metadata för färdig output inför publicering
Vägledning för autentisering
Använd X-API-Key server-side för Ssemble och håll TikTok OAuth-tokens isolerade i din publiceringstjänst. Rotera varje nyckeluppsättning oberoende per miljö.
Rate limits och retries
Behandla generering och publicering som separata budgetar. Serialisera muterande anrop per destinationskonto och vid 429 respektera reset/retryAfter med exponentiell backoff + jitter.
Exempel på request
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"
}Exempel på response
200 OK
{
"jobId": "job_01HT...",
"state": "publish_processing",
"publishId": "v_inbox_file~v2.123456789",
"nextCheckAt": "2026-03-10T18:00:30Z"
}Exempel på felscenario
429 Too Many Requests
{
"error": {
"code": "rate_limit_exceeded",
"message": "Per-account posting throttle reached",
"details": { "retryAfter": "2026-03-10T18:01:00Z" }
}
}Versionshantering
Fäst endpoint-versioner och logga versionsmetadata från uppströms per request så att integrationsregressioner går att spåra.
Support
För incidentsortering, spara requestId + publish_id + account id + error.code + upstream log_id i en enda sökbar post.
Snabbstart
- Skapa SSEMBLE_API_KEY och lagra i backend-secrets.
- Anropa POST /shorts/create och spara requestId i din jobbtabell.
- Polla GET /shorts/:id/status var 10:e sekund tills terminalt tillstånd.
- Vid completed, publicera till TikTok via din serverkö.
- Hantera 429/5xx med begränsade retries och stabila idempotency-nycklar.
Arbetsflöde i 3 steg
- Generera resurser för kortformat och lagra requestId plus publiceringskontext i din jobbtabell.
- Spåra bearbetning via statuspolling eller webhooks och flytta jobb till ready/failed-tillstånd deterministiskt.
- Publicera till TikTok med throttlekontroll per konto, idempotency-nycklar och avstämningsloggar.
Varför team väljer Ssemble
- Byggt för team som distribuerar över flera konton, där kötillförlitlighet är viktigare än enstaka framgång.
- Separerar rendering och publicering så att fel isoleras och kan återställas.
- Stöder moderationsmedveten tillståndshantering: slutförd upload är inte alltid slutgiltig offentlig tillgänglighet.
Nästa steg
Vanliga frågor
Kan vi behandla lyckad upload som publicerad?
Inte alltid. Håll separata tillstånd för uploaded, submitted, publish_complete och publicly_available för att undvika falska positiva.
Vilket steg måste vara idempotent?
Minst initiering av publicering. Använd en stabil idempotency-nyckel per jobb så att retries inte skapar dubbletter.
Polling eller webhooks: vilket bör vi använda?
Använd webhooks som primär metod när det är möjligt och behåll polling som fallback för avstämning och missade event.
Hur undviker vi 429-toppar över många konton?
Sharda köer per destinationskonto och tillämpa concurrency-gränser per konto istället för en global topp-kö.
Vilka loggar är obligatoriska för incidenthantering?
Registrera requestId, publish_id, account id, statusövergångar och error code för att stödja deterministisk felsökning.
Garanterar detta tid för slutförd moderation?
Nej. Moderationsfönster varierar, så produktionssystem bör behandla slutlig tillgänglighetstidpunkt som asynkron och variabel.
