I recently built a content syndication plugin for EmDash that automatically distributes blog posts to Dev.to, LinkedIn, Medium, Hacker News, and email newsletters from a single publish action. Here's how the architecture works and what I learned about multi-platform API orchestration.

The Problem: Format Fragmentation and Timing Drift

Manual cross-posting breaks down in practice because each platform expects different formats and has different constraints:

• Format fragmentation — HTML on your site, Markdown on Dev.to, rich text on LinkedIn, plain text for HN, HTML for email
• Timing drift — manual workflows slip by days or weeks, defeating the purpose of coordinated launches
• Metadata mismatch — canonical URLs, tags, and excerpts need to be correct per platform for SEO
• No centralized tracking — you can't measure which channel drives the most traffic without a unified analytics layer

Architecture Overview

The pipeline runs entirely on Cloudflare Workers via EmDash's plugin system with four components:

No external cron jobs or queue infrastructure needed — Workers' Queues (or KV with TTL) handles the orchestration.

Step 1: The Publish Hook

The plugin registers a middleware that fires on afterPostSave when status flips to 'published':

// emdash-plugin-syndication/hooks.js
export default {
  async afterPostSave(post, context) {
    if (post.status === 'published' && post.wasDraft) {
      await context.env.SYNDICATION_QUEUE.put(
        `syndicate:${post.slug}`,
        JSON.stringify({
          slug: post.slug,
          title: post.title,
          body: post.body,
          excerpt: post.excerpt,
          tags: post.tags,
          publishedAt: post.published_at,
          channels: ['devto', 'linkedin', 'medium', 'hn']
        }),
        { expirationTtl: 86400 }
      );
    }
    return post;
  }
};

Key design decision: using post.wasDraft prevents re-syndication on edits to already-published posts. Without this guard, every content update would re-trigger the pipeline and duplicate content across platforms.

Step 2: Format Adapter Pattern

Each platform gets its own adapter that converts the internal HTML body to the target format:

const adapters = {
  devto: (post) => ({
    body_markdown: htmlToMarkdown(post.body),
    tags: post.tags.slice(0, 4),  // Dev.to max 4 tags
    canonical_url: `https://ai-kit.net/blog/${post.slug}`,
    published: true
  }),
  linkedin: (post) => ({
    commentator: 'urn:li:person:ai-kit',
    content: {
      article: {
        title: post.title,
        description: post.excerpt,
        source: 'https://ai-kit.net',
        thumbnailUrl: `https://ai-kit.net/og/${post.slug}.png`,
        canonicalUrl: `https://ai-kit.net/blog/${post.slug}`
      }
    },
    distribution: {
      feedDistribution: 'MAIN_FEED',
      targetEntities: []
    }
  }),
  medium: (post) => ({
    title: post.title,
    contentFormat: 'markdown',
    content: htmlToMarkdown(post.body),
    tags: post.tags.slice(0, 3),  // Medium max 3 tags
    publishStatus: 'public',
    canonicalUrl: `https://ai-kit.net/blog/${post.slug}`
  })
};

Platform-specific quirks I ran into:

• LinkedIn strips code blocks — their rich text API doesn't support <pre><code>. I convert code blocks to inline code spans, which is imperfect but preserves readability
• Medium expects Gist embeds for code — plain code fences in Medium import create formatting issues. The adapter optionally wraps code blocks as Gist URLs
• Dev.to loves code fences — standard triple-backtick fences work perfectly with syntax highlighting
• Hacker News is plain text only — 2000 character limit, no markup, no images. Append the original story URL for context
• LinkedIn API has rate limits — 100 posts per 24 hours, ~1 post per 14 minutes sustained

Step 3: Token Refresh Pattern

OAuth tokens expire and each platform handles expiry differently. Here's the refresh wrapper I built:

async function getValidToken(channel, context) {
  const token = await context.env.SECRETS.get(`${channel}_token`);
  const expiresAt = await context.env.SECRETS.get(`${channel}_expires_at`);

  if (token && expiresAt && Date.now() < parseInt(expiresAt)) {
    return token;
  }

  // Refresh token
  const refreshToken = await context.env.SECRETS.get(`${channel}_refresh_token`);
  const response = await refreshAccessToken(channel, refreshToken);

  await context.env.SECRETS.put(`${channel}_token`, response.access_token);
  await context.env.SECRETS.put(
    `${channel}_expires_at`,
    String(Date.now() + response.expires_in * 1000)
  );

  return response.access_token;
}

One gotcha: LinkedIn's access tokens expire every 60 days with no refresh token for the Community Management API. You need the Marketing Developer Platform OAuth 2.0 flow which provides refresh tokens. Dev.to and Medium tokens are long-lived (not expiring), so their expires_at is set far in the future as a simple sentinel.

Step 4: Error Tracking with D1

Each syndication attempt is logged to a D1 events table for debugging and observability:

CREATE TABLE syndication_events (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  post_slug TEXT NOT NULL,
  channel TEXT NOT NULL,
  status TEXT NOT NULL,  -- 'success', 'failed', 'retrying'
  url TEXT,
  error TEXT,
  attempted_at INTEGER NOT NULL,
  retry_count INTEGER DEFAULT 0
);
CREATE INDEX idx_syndication_post ON syndication_events(post_slug);

The pipeline retries failed channels up to 3 times with exponential backoff (30s, 2min, 10min). After exhausting retries, the event is marked as permanently failed and a notification is dispatched via Telegram or email.

Design Decisions Worth Calling Out

Staggered syndication timing

I intentionally sequence channels to optimize indexing and avoid spamming overlapping audiences:

1. Dev.to and Medium first — they index quickly and cache syndicated copies
2. LinkedIn next — slower to appear in feeds, so publishing earlier doesn't help
3. Email digests last — avoids sending notifications to subscribers who may have already seen the post on another platform

Rate limiting per channel

Each platform has different API rate limits. Dev.to allows 5 API calls per minute, LinkedIn has daily post limits. The plugin maintains a per-channel rate limiter using D1 counters:

async function checkRateLimit(channel, context) {
  const key = `ratelimit:${channel}:${Math.floor(Date.now() / 60000)}`;
  const count = await context.env.SYNDICATION_QUEUE.get(key) || 0;
  const limit = RATE_LIMITS[channel];  // { max: 5, window: 60000 }
  if (count >= limit.max) throw new RateLimitError(channel);
  await context.env.SYNDICATION_QUEUE.put(key, count + 1, { expirationTtl: 120 });
}

Canonical URL enforcement

Every syndicated copy includes a canonical_url pointing back to the original. This is critical for SEO — without it, syndicated copies can outrank the original for search queries. Dev.to and Medium support canonical URLs natively. LinkedIn's article API requires setting canonicalUrl in the payload.

Dry-run mode

Before hitting live APIs, the plugin includes a dry-run mode that returns the formatted payload without posting. You can preview exactly what each platform will receive in EmDash's admin UI:

if (options.dryRun) {
  return { channel, payload: adapter(post) };
}

What I'd Do Differently Next Time

1. Use a message queue from day one — I started with simple Promise.all across all channels. First LinkedIn API timeout blocked Dev.to and Medium. Sequential processing with a proper queue (Workers Queues) fixed this.
2. Platform-specific test fixtures — each platform has subtle JSON schema differences that surface as 400s at runtime. Mocking the actual API responses in tests would have caught these earlier.
3. Graceful degradation per channel — one platform being down shouldn't stop syndication to others. Each channel should be fully isolated in its own Worker invocation.

Metrics to Track

• Syndication velocity — time from initial publish to full syndication across all channels (target: under 10 minutes)
• Channel performance — which syndication channel drives the most referrer traffic back
• Failure rate — percentage of attempts requiring retries. High failure rates indicate token issues or API changes
• SEO impact — monitor whether syndicated copies outrank your canonical page. If they do, strengthen canonical tags or delay syndication by 24 hours

Building a content syndication plugin this way turns a single-platform CMS into a multi-channel distribution engine. Each published post automatically reaches Dev.to's developer audience, LinkedIn's professional network, Medium's general readership, Hacker News's tech community, and email subscribers — with zero manual effort after the initial publish click.