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/create— Generér asset til kortformat før publiceringGET /shorts/:id/status— Spor behandlingslivscyklus og failureReasonGET /shorts/:id— Hent 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
- Opret SSEMBLE_API_KEY, og gem i backend-secrets.
- Kald POST /shorts/create, og gem requestId i din jobtabel.
- Poll GET /shorts/:id/status hvert 10. sekund, indtil terminaltilstand.
- Ved completed, publicér til TikTok via din serverkø.
- Håndtér 429/5xx med begrænsede retries og stabile idempotency-nøgler.
Workflow i 3 trin
- Generér assets til kortformat, og gem requestId plus publiceringskontekst i din jobtabel.
- Spor behandling via statuspolling eller webhooks, og flyt jobs til ready/failed-tilstande deterministisk.
- 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.
