How to Build a Multi-Tenant Social Media Integration
Single-account social integrations are solved. Multi-tenant — where each of your 25 clients has fully isolated credentials, analytics, and posting queues — requires a different architecture. Here's the pattern.
The core problem: shared vs isolated state
When you build a social integration naively, all clients share one OAuth app. Their tokens live in the same database table. Their posts hit the same rate limit bucket. Their analytics are commingled. This creates:
- —Security risk: a token leak exposes all clients, not just one
- —Rate limit bleed: one client's burst posting throttles everyone else
- —Debugging hell: when a post fails, which client's token expired?
- —Billing complexity: how do you charge clients individually if usage is pooled?
The right data model
A proper multi-tenant social API has these entities:
Token encryption pattern
Never store OAuth tokens in plaintext. AES-256-GCM with a key stored in environment variables is the standard pattern:
The retry queue
Social platform APIs fail. Instagram goes down. Twitter rate limits mid-batch. Your queue must handle this gracefully:
- →Attempt 1: immediate
- →Attempt 2: +30 seconds (exponential backoff)
- →Attempt 3: +2 minutes
- →After 3 failures: mark as failed, send email notification, allow manual retry
Fanout uses Inngest for this — a durable function runner that handles retries, scheduling, and failure tracking out of the box.
Skip the build — use Fanout
This architecture takes 4-8 weeks to build correctly. Token encryption, refresh logic, retry queues, per-client rate limit tracking, analytics collection — all of it. Fanout is this infrastructure, already built, at $49/mo for 3 client profiles or $199/mo for 25.