API-integration

TikTok Posting API til køsikker distribution på tværs af flere konti

Levér workflows til TikTok-publicering med eksplicit statussporing, retry-sikker orkestrering og moderationsbevidst håndtering til teams i produktionsskala.

Problem

I stor skala fejler distribution der, hvor publicering stadig er manuel: handlinger til upload/publicering bliver skrøbelige på tværs af mange konti, tidsplaner og moderationstilstande.

Resultat med Ssemble

Ssemble understøtter indholdsgenerering og statusorkestrering, mens dit TikTok-publiceringslag udfører kontrollerede publiceringer med idempotency, retries og sporbare jobtilstande.

Grundlæggende ved implementering

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

Integrationsarkitektur (ingest → behandl → poll/webhook → publicér)

1) Ingest

Gem kilde-URL/fil-URL + destinationskonto + scheduleAt + idempotency-nøgle i din publiceringsjobmodel.

2) Behandl

Kald POST /shorts/create, gem requestId, og knyt det til efterfølgende publiceringsjobs.

3) Poll / Webhook

Flyt jobs gennem processing/ready/failed-tilstande ved hjælp af GET /shorts/:id/status og event-fallbacks.

4) Publicér

Udløs TikTok-publicering med concurrency-lofter pr. konto, retry-politik og endelig statusafstemning.

Eksempler på endpoints

  • POST /shorts/createGenerér asset til kortformat før publicering
  • GET /shorts/:id/statusSpor behandlingslivscyklus og failureReason
  • GET /shorts/:idHent metadata for færdigt output til publicering

Vejledning til autentificering

Brug X-API-Key server-side til Ssemble, og hold TikTok OAuth-tokens isoleret i din publiceringstjeneste. Rotér hvert nøglesæt uafhængigt pr. miljø.

Rate limits og retries

Behandl generering og publicering som separate budgetter. Serialisér muterende kald pr. destinationskonto, og respektér ved 429 reset/retryAfter med eksponentiel backoff + jitter.

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

Eksempel på response

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

Eksempel på fejlscenarie

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

Versionsstyring

Fastlås endpoint-versioner, og log versionsmetadata fra upstream pr. request, så integrationsregressioner kan spores.

Support

Til incidenttriage skal du gemme requestId + publish_id + account id + error.code + upstream log_id i én søgbar post.

Hurtig start

  1. Opret SSEMBLE_API_KEY, og gem i backend-secrets.
  2. Kald POST /shorts/create, og gem requestId i din jobtabel.
  3. Poll GET /shorts/:id/status hvert 10. sekund, indtil terminaltilstand.
  4. Ved completed, publicér til TikTok via din serverkø.
  5. Håndtér 429/5xx med begrænsede retries og stabile idempotency-nøgler.
Åbn dokumentation til TikTok-publicering

Start integration

Workflow i 3 trin

  1. Generér assets til kortformat, og gem requestId plus publiceringskontekst i din jobtabel.
  2. Spor behandling via statuspolling eller webhooks, og flyt jobs til ready/failed-tilstande deterministisk.
  3. Publicér til TikTok med throttlekontrol pr. konto, idempotency-nøgler og afstemningslogs.

Hvorfor teams vælger Ssemble

  • Bygget til teams, der distribuerer på tværs af flere konti, hvor køpålidelighed er vigtigere end enkeltstående succes.
  • Adskiller rendering og publicering, så fejl isoleres og kan genoprettes.
  • Understøtter moderationsbevidst tilstandshåndtering: fuldført upload er ikke altid endelig offentlig tilgængelighed.

Næste trin

Ofte stillede spørgsmål

Kan vi behandle vellykket upload som publiceret?

Ikke altid. Hold separate tilstande for uploaded, submitted, publish_complete og publicly_available for at undgå falske positiver.

Hvilket trin skal være idempotent?

Som minimum initiering af publicering. Brug én stabil idempotency-nøgle pr. job, så retries ikke opretter dubletter.

Polling eller webhooks: hvad bør vi bruge?

Brug webhooks som primær metode, når det er muligt, og behold polling som fallback til afstemning og mistede events.

Hvordan undgår vi 429-spidser på tværs af mange konti?

Shard køer pr. destinationskonto, og håndhæv concurrency-grænser pr. konto i stedet for én global spidskø.

Hvilke logs er obligatoriske til incidenthåndtering?

Registrér requestId, publish_id, account id, statusovergange og error code for at understøtte deterministisk fejlfinding.

Garanterer dette tidspunktet for fuldført moderation?

Nej. Moderationsvinduer varierer, så produktionssystemer bør behandle det endelige tilgængelighedstidspunkt som asynkront og variabelt.

Relaterede ressourcer