API-integratie

TikTok Posting API voor wachtrij-veilige distributie over meerdere accounts

Lever TikTok-postingworkflows met expliciete statustracking, retry-veilige orchestratie en moderatiebewuste afhandeling voor teams op productieschaal.

Probleem

Op schaal loopt distributie vast waar posten nog handmatig gebeurt: upload-/publiceeracties worden fragiel over veel accounts, schema's en moderatiestatussen.

Resultaat met Ssemble

Ssemble ondersteunt contentgeneratie en statusorchestratie terwijl je TikTok-postinglaag gecontroleerde publicaties uitvoert met idempotency, retries en controleerbare jobstatussen.

Implementatie-essentials

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

Integratiearchitectuur (ingest → verwerking → polling/webhook → publiceren)

1) Ingest

Sla de source URL/file URL + doelaccount + scheduleAt + idempotency key op in het jobmodel van je publisher.

2) Verwerking

Roep POST /shorts/create aan, persisteer de requestId en koppel deze aan de vervolgpostingjobs.

3) Poll / Webhook

Verplaats jobs door de statussen processing/ready/failed met GET /shorts/:id/status en event-fallbacks.

4) Publiceren

Trigger de TikTok-publicatie met concurrency-limieten per account, een retry-beleid en reconciliatie van de definitieve status.

Endpoint-voorbeelden

POST /shorts/create— Genereer de short-form asset vóór het posten
GET /shorts/:id/status— Volg de verwerkingslevenscyclus en de failureReason
GET /shorts/:id— Haal de metadata van de voltooide output op voor het posten

Authenticatierichtlijnen

Gebruik de X-API-Key server-side voor Ssemble en houd de TikTok-OAuth-tokens geïsoleerd in je postingservice. Roteer elke set sleutels onafhankelijk per omgeving.

Rate limits en retries

Behandel generatie en posten als aparte budgetten. Serialiseer muterende calls per doelaccount en respecteer bij een 429 reset/retryAfter met exponentiële backoff + jitter.

Voorbeeld van een 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"
}

Voorbeeld van een response

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

Voorbeeld van een foutscenario

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

Versiebeheer

Pin de endpointversies en log per request de upstream-versiemetadata, zodat integratieregressies traceerbaar zijn.

Support

Persisteer voor incidenttriage requestId + publish_id + account id + error.code + upstream log_id in één opvraagbaar record.

Quickstart

Maak een SSEMBLE_API_KEY aan en sla deze op in de backend-secrets.
Roep POST /shorts/create aan en persisteer de requestId in je jobtabel.
Poll GET /shorts/:id/status elke 10 seconden tot de terminale status.
Post bij completed naar TikTok via de wachtrij van je server.
Handel 429/5xx af met begrensde retries en stabiele idempotency keys.

TikTok-postingdocumentatie openen

Integratie starten

1) Authenticatie

API key-formaat en afhandeling van authenticatiefouten

2) Endpointreferentie

Contracten voor create/status/list/delete

3) Foutafhandeling

Patronen voor retryable versus terminale fouten

4) Codevoorbeelden

Direct implementeerbare integratiesnippets

Workflow in 3 stappen

Genereer short-form assets en sla de requestId plus publicatiecontext op in je jobtabel.
Volg de verwerking via statuspolling of webhooks en verplaats jobs deterministisch naar ready-/failed-statussen.
Publiceer naar TikTok met throttlecontrole per account, idempotency keys en reconciliatielogs.

Waarom teams voor Ssemble kiezen

Gebouwd voor distributieteams met meerdere accounts, waar betrouwbaarheid van de wachtrij belangrijker is dan eenmalig succes.
Scheidt rendering en posten, zodat fouten geïsoleerd en herstelbaar blijven.
Ondersteunt moderatiebewuste statusafhandeling: het voltooien van een upload is niet altijd de definitieve publieke beschikbaarheid.

Volgende stap

TikTok-posting-quickstart openen Prijzen bekijken Ontwikkelaarsdocumentatie

FAQ

Mogen we een geslaagde upload als gepubliceerd behandelen?

Niet altijd. Houd aparte statussen aan voor uploaded, submitted, publish_complete en publicly_available om valse positieven te voorkomen.

Welke stap moet idempotent zijn?

Minimaal het initiëren van de publicatie. Gebruik één stabiele idempotency key per job, zodat retries geen duplicaten aanmaken.

Polling of webhooks: wat moeten we gebruiken?

Gebruik webhooks als primaire optie wanneer beschikbaar en houd polling als fallback voor reconciliatie en gemiste events.

Hoe voorkomen we 429-pieken over veel accounts?

Shard de wachtrijen per doelaccount en handhaaf concurrency-limieten per account in plaats van één globale piekwachtrij.

Welke logs zijn verplicht voor incidentrespons?

Leg requestId, publish_id, account id, statustransities en error code vast om deterministische debugging te ondersteunen.

Garandeert dit de moderatievoltooiingstijd?

Nee. Moderatievensters variëren, dus productiesystemen moeten de timing van de definitieve beschikbaarheid als asynchroon en variabel behandelen.