Intégration API
API de publication TikTok pour une distribution multi-comptes fiable en file d'attente
Déployez des workflows de publication TikTok avec un suivi de statut explicite, une orchestration compatible avec les retries et une gestion tenant compte de la modération pour les équipes à l'échelle de la production.
Problème
À grande échelle, la distribution échoue là où la publication reste manuelle : les actions d'upload/publication deviennent fragiles à travers de nombreux comptes, plannings et états de modération.
Résultat avec Ssemble
Ssemble prend en charge la génération de contenu et l'orchestration des statuts pendant que votre couche de publication TikTok exécute des publications contrôlées avec idempotence, retries et états de job auditables.
Éléments essentiels d'implémentation
URL de base: https://aiclipping.ssemble.com/api/v1 (+ TikTok Open API for publish)
Architecture d'intégration (ingestion → traitement → polling/webhook → publication)
1) Ingestion
Stockez l'URL source/URL de fichier + le compte de destination + scheduleAt + l'idempotency key dans votre modèle de job de publication.
2) Traitement
Appelez POST /shorts/create, persistez le requestId et rattachez-le aux jobs de publication en aval.
3) Polling / Webhook
Faites transiter les jobs à travers les états processing/ready/failed via GET /shorts/:id/status et des fallbacks d'événements.
4) Publication
Déclenchez la publication TikTok avec des plafonds de concurrence par compte, une politique de retry et une réconciliation du statut final.
Exemples d'endpoint
POST /shorts/create— Générer un asset au format court avant la publicationGET /shorts/:id/status— Suivre le cycle de vie du traitement et failureReasonGET /shorts/:id— Récupérer les métadonnées de sortie finalisées pour la publication
Recommandations d'authentification
Utilisez X-API-Key côté serveur pour Ssemble, et gardez les tokens OAuth TikTok isolés dans votre service de publication. Effectuez la rotation de chaque jeu de clés indépendamment par environnement.
Rate limits et retries
Traitez la génération et la publication comme des budgets distincts. Sérialisez les appels mutateurs par compte de destination et, en cas de 429, respectez reset/retryAfter avec un backoff exponentiel + jitter.
Exemple de requête
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"
}Exemple de réponse
200 OK
{
"jobId": "job_01HT...",
"state": "publish_processing",
"publishId": "v_inbox_file~v2.123456789",
"nextCheckAt": "2026-03-10T18:00:30Z"
}Exemple de scénario d'erreur
429 Too Many Requests
{
"error": {
"code": "rate_limit_exceeded",
"message": "Per-account posting throttle reached",
"details": { "retryAfter": "2026-03-10T18:01:00Z" }
}
}Gestion des versions
Épinglez les versions d'endpoint et loggez les métadonnées de version upstream par requête afin que les régressions d'intégration soient traçables.
Support
Pour le triage d'incidents, persistez requestId + publish_id + account id + error.code + upstream log_id dans un seul enregistrement interrogeable.
Démarrage rapide
- Créez SSEMBLE_API_KEY et stockez-la dans les secrets backend.
- Appelez POST /shorts/create et persistez le requestId dans votre table de jobs.
- Effectuez un polling de GET /shorts/:id/status toutes les 10 secondes jusqu'à l'état terminal.
- Une fois completed, publiez sur TikTok via votre file d'attente serveur.
- Gérez les 429/5xx avec des retries bornés et des idempotency keys stables.
Workflow en 3 étapes
- Générez des assets au format court et stockez le requestId ainsi que le contexte de publication dans votre table de jobs.
- Suivez le traitement via le polling de statut ou les webhooks et faites passer les jobs aux états ready/failed de manière déterministe.
- Publiez sur TikTok avec un contrôle de throttle par compte, des idempotency keys et des logs de réconciliation.
Pourquoi les équipes choisissent Ssemble
- Conçu pour les équipes de distribution multi-comptes où la fiabilité de la file d'attente compte plus qu'un succès ponctuel.
- Sépare les responsabilités de rendu et de publication afin que les échecs soient isolés et récupérables.
- Prend en charge une gestion d'état tenant compte de la modération : la fin de l'upload ne signifie pas toujours la disponibilité publique définitive.
Étape suivante
FAQ
Peut-on considérer la réussite de l'upload comme une publication ?
Pas toujours. Conservez des états distincts pour uploaded, submitted, publish_complete et publicly_available afin d'éviter les faux positifs.
Quelle étape doit être idempotente ?
Au minimum, le lancement de la publication. Utilisez une idempotency key stable par job afin que les retries ne créent pas de doublons.
Polling ou webhooks : lequel utiliser ?
Utilisez les webhooks en priorité lorsqu'ils sont disponibles et conservez le polling comme fallback pour la réconciliation et les événements manqués.
Comment éviter les rafales de 429 sur de nombreux comptes ?
Répartissez les files d'attente par compte de destination et appliquez des limites de concurrence par compte plutôt qu'une seule file d'attente globale en rafale.
Quels logs sont obligatoires pour la réponse aux incidents ?
Enregistrez requestId, publish_id, account id, les transitions de statut et le code d'erreur pour permettre un débogage déterministe.
Cela garantit-il le délai de fin de modération ?
Non. Les fenêtres de modération varient, les systèmes de production doivent donc considérer le délai de disponibilité finale comme asynchrone et variable.
