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/createGenerera resurs för kortformat före publicering
  • GET /shorts/:id/statusSpåra bearbetningslivscykel och failureReason
  • GET /shorts/:idHä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

  1. Skapa SSEMBLE_API_KEY och lagra i backend-secrets.
  2. Anropa POST /shorts/create och spara requestId i din jobbtabell.
  3. Polla GET /shorts/:id/status var 10:e sekund tills terminalt tillstånd.
  4. Vid completed, publicera till TikTok via din serverkö.
  5. Hantera 429/5xx med begränsade retries och stabila idempotency-nycklar.
Öppna dokumentation för TikTok-publicering

Starta integration

Arbetsflöde i 3 steg

  1. Generera resurser för kortformat och lagra requestId plus publiceringskontext i din jobbtabell.
  2. Spåra bearbetning via statuspolling eller webhooks och flytta jobb till ready/failed-tillstånd deterministiskt.
  3. 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.

Relaterade resurser