Skip to main content

Repost System

This guide explains the repost orchestration system that enables users to automatically republish content from source platforms to configured destination platforms.

Overview​

The repost system allows users to:

  • Designate platforms as repost sources (where content originates)
  • Enable platforms as repost destinations (where content gets republished)
  • Automatically fan out reposts to all enabled destinations

Architecture​

The system consists of:

  • Repost Orchestrator: Central coordinator for repost jobs
  • Platform Configuration: Per-user settings for repost behavior
  • Queue System: Reliable delivery via Cloud Tasks

Current Single-Source Flow (2024)​

  1. Organic triggers – apps/functions/integrations/tiktok/organic-post-trigger.js and .../instagram/organic-post-trigger.js watch users/{uid}/organicPosts/{postId}. Each trigger filters by source_platform, stamps the organic post with status: 'reposting_initiated', and enqueues repostOrchestrator.
  2. Global target resolution – repost-orchestrator.js scans every provider under users/{uid}/integrations/*/accounts where enabled_for_repost == true, regardless of which source account produced the organic post. This yields a single destination list for all repost jobs.
  3. Repurpose templates – trigger-templates.js fan-outs template automations for any account that has enable_text_repurpose_target or enable_image_repurpose_target toggled on. repurposeLinks documents do not distinguish source platforms, so all detected organic content is eligible if the destination toggle is set.
  4. Idempotency – The orchestrator short-circuits when it finds an existing postSubmissions document for the organic post or when the organic post is already marked as status: 'reposted'.

Limitations Today​

  • Single source assumption – Because targets are derived solely from enabled_for_repost, every organic TikTok post fans out to every enabled destination, even when a user only wants specific TikTok accounts to trigger automations.
  • No workflow scoping – Template automations cannot encode “TikTok Account A → Instagram Account A” vs “TikTok Account A → LinkedIn Account B” as independent workflows. All automations share the same toggles and repurpose-link collection.
  • Per-source feature flags missing – There is no place to express “platform A1 reposts when content matches template T1 but platform A2 does not.” Users must manually toggle destination accounts, which affects every source.
  • Limited observability – organicPosts only tracks a single status. We cannot see which destinations succeeded or failed per organic post without inspecting multiple postSubmissions, making partial reruns brittle.
  • Scalability blockers – Adding another source (e.g., Instagram) requires duplicating trigger logic and still funnels into the same global destinations, so per-source/per-workflow business rules would require ad hoc conditionals spread across functions.

Configuration Fields​

Each integration document includes repost configuration:

  • enabled_for_repost: boolean - Platform accepts reposts as destination
  • can_be_source: boolean - Platform can trigger reposts (future)

Currently configured in auth flows:

  • Facebook: enabled_for_repost: true, can_be_source: false
  • Instagram: enabled_for_repost: true, can_be_source: false
  • Threads: enabled_for_repost: true, can_be_source: false
  • X: enabled_for_repost: true, can_be_source: false
  • TikTok: enabled_for_repost: true, can_be_source: false
  • YouTube: enabled_for_repost: true, can_be_source: false
  • LinkedIn: enabled_for_repost: true, can_be_source: false

Soku-Published Post Guard​

By default, posts published through the Soku API or UI are not fed into the repost/repurpose workflow. When pollers detect a post that was already published by Soku, the organic post trigger checks for a matching system post document (users/{uid}/posts/{docId}) and skips workflow dispatch.

This prevents duplicate processing: if you publish a video to X via the API, the X poller won't accidentally repurpose that same video through your automation workflows.

Opting into repurposing​

Users can override this behavior by setting enableRepurposing: true on their post request. When this flag is set:

  1. The post is published to the selected platforms as normal.
  2. The enableRepurposing flag is stored on both the post submission and the system post document.
  3. When the poller later detects the post and the organic post trigger fires, it reads the system post and sees enableRepurposing: true.
  4. Instead of skipping, the trigger allows the organic post to proceed through the normal workflow dispatch.

This is useful when a user wants to publish to one platform through Soku and have their automation workflows repurpose the content to additional platforms.

Repost Orchestrator​

Entry: apps/functions/repost-orchestrator.js

Input: { userId, postId }

Flow:

  1. Query user's integrations collection
  2. Filter by enabled_for_repost: true
  3. Check against supported destinations (currently: instagram, youtube)
  4. Enqueue repost tasks to platform-specific queues
  5. Return job count and target list

Supported Destinations​

Current repost destinations:

  • Instagram: Reposts via repost-instagram queue
  • YouTube: Reposts via repost-youtube queue

Future destinations (configured but not active):

  • Facebook, Threads, X, TikTok, LinkedIn

Queue Configuration​

Repost queues follow the pattern repost-{platform}:

# Create repost queues
gcloud tasks queues create repost-instagram --location=us-central1
gcloud tasks queues create repost-youtube --location=us-central1

Data Flow​

  1. Trigger: External system calls repost orchestrator with userId and postId
  2. Discovery: Orchestrator reads user's integration settings
  3. Filtering: Only platforms with enabled_for_repost: true are considered
  4. Validation: Check against list of actively supported destinations
  5. Dispatch: Enqueue tasks to platform-specific repost handlers
  6. Execution: Platform handlers fetch original post and republish

Error Handling​

  • Missing or invalid userId/postId: Return 400 error
  • No enabled destinations: Return success with zero jobs
  • Queue failures: Logged and surfaced via Cloud Tasks retry

Future Enhancements​

The system is designed to support:

  • Source Detection: can_be_source platforms triggering automatic reposts
  • Conditional Logic: User-defined rules for when to repost
  • Content Filtering: Platform-specific content adaptation
  • Schedule Delays: Time-based repost scheduling
  • Cross-Platform Analytics: Tracking repost performance

API Response​

{
  "ok": true,
  "jobsCreated": 2,
  "targets": ["instagram", "youtube"]
}

Integration​

The repost orchestrator is typically called by:

  • Webhook handlers detecting new posts on source platforms
  • Manual repost triggers from admin interfaces
  • Scheduled jobs for batch repost processing