Integrations

Use Social SDK with web frameworks, databases, and job runners such as Next.js, Hono, Supabase, SurrealDB, and Inngest.

To add auto-posting to a SaaS app, run Social SDK on your server and let each customer connect their own social accounts:

1. Connect accounts per customer. Use ConnectionManager from @opencoredev/social-sdk/server with the platform’s OAuth factory (X, Bluesky, Threads, Instagram, LinkedIn, TikTok, or YouTube). It records a grant for the customer’s tenant. Tokens are saved only where you send them: pass a credentialSink that encrypts them at rest in your own store (for Bluesky, a sessionSink for the whole session). To skip registering an app with each platform, use a managed backend such as Zernio, Post for Me, or PostFast, and connect accounts through that provider instead.
2. Check the tenant on every call. Configure an AuthorizationPolicy in createSocial that looks up the customer’s grants. Without a policy, the client checks nothing.
3. Publish with social.posts.publish. Pass the draft ID as the idempotencyKey and configure a durable idempotencyStore, so a retried request doesn’t post twice. You get one outcome per destination. An unknown outcome means the post may exist, so reconcile it rather than sending it again.
4. Schedule with a job runner you own, such as Trigger.dev, Inngest, or Restate, and call social.posts.publish when each job is due. The SDK starts no background work. PostFast is the exception: it schedules on its side and needs a future schedule.at on every post.

npm install @opencoredev/social-sdk

pnpm add @opencoredev/social-sdk

yarn add @opencoredev/social-sdk

bun add @opencoredev/social-sdk

nub add @opencoredev/social-sdk

aube add @opencoredev/social-sdk

Authentication covers the connection flow, authorization covers the tenant check, and choose an integration compares direct and managed routes. To try publishing without platform credentials, start with the mock quickstart.

Social SDK is a server-side TypeScript library with no framework dependency. It runs anywhere its tested runtimes run: Node 22.12+, Node 24, and Bun. These guides show the recommended wiring for popular stacks: where the client lives, where credentials stay, how webhooks reach the verifier, and where durable state belongs.

Every integration keeps the same rules. Credentials and connected-account references stay on the server. Your application authorizes the tenant before every operation. Publishing returns one outcome per destination, and uncertain outcomes are reconciled explicitly.

Frameworks

Next.js

Publish from App Router route handlers and server actions.

TanStack Start

Publish from server functions and verify webhooks in API routes.

Express

Wire routes and raw-body webhook verification in the standard Node server.

Hono

Use the fetch-native handler pattern on Node or Bun.

Elysia

Validate publish bodies with schemas and verify webhooks from unparsed requests.

NestJS

Provide the client through dependency injection with a webhook controller.

Databases

Convex

Call the SDK from Node actions and keep deliveries in Convex tables.

Supabase

Store connections, idempotency claims, and delivery outcomes in Supabase Postgres.

Neon

Run the SDK next to Neon Postgres and reconcile on a scheduled trigger.

SurrealDB

Keep publish state in SurrealDB and stream delivery changes with live queries.

Job runners

The SDK never starts background work: no polling, no timers, no queues. Scheduled publishing and reconciliation belong to a durable job runner you own.

Trigger.dev

Run scheduled publishes and reconciliation tasks with retries you control.

Inngest

Drive event-based publishing flows with durable steps and idempotency.

Restate

Keep each draft in a durable object that schedules its own reconciliation.