OpenCore released Social SDK, a typed TypeScript client for seven social platforms, and the repository picked up 406 GitHub stars in under four weeks

A product that posts to more than two social platforms from a server usually carries one wrapper per platform, one authentication path, one error shape and one set of edge cases, which is seven versions of the same thing by the time it covers Bluesky, Instagram, LinkedIn, Threads, TikTok, X and YouTube. OpenCore released Social SDK as an MIT project that replaces those seven wrappers with one typed call, and the repository on github.com/opencoredev/social-sdk reports 406 stars 26 days after its first commit on 8 September 2026, per the GitHub REST API on 4 October 2026.

What is in the package

Social SDK is a TypeScript client with direct adapters for all seven of those platforms, plus optional adapters for the hosted services Zernio, Post for Me, PostFast and Postiz. OpenCore's README says the same client shape works against either a direct adapter or a managed backend, so a team can start on a hosted service and switch to a direct integration later as a config change.

The design decision that marks the SDK out is that a publish returns one outcome per destination, with four possible states: complete, processing, uncertain, and failed. OpenCore's README describes these as "independent per-destination outcomes" and ties them to a reconciliation page in the docs. A caller that posts to five platforms and loses one knows which one, and gets a typed object for the ones that worked.

A deterministic mock backend ships for local development and contract tests. OpenCore's example in the README verifies an integration without credentials, platform calls or billable provider requests, by passing mockBackend({ scenario: "immediate-text-success" }) to the client factory. That means a CI run can exercise the entire publish flow on every pull request.

The offline CLI, and what it refuses to do

The social-sdk command-line tool is deliberately offline. The README states it does not authenticate accounts, upload media, publish content, or make hidden network requests. What it does is list the installed adapters, print the capability matrix for a chosen adapter in JSON, run diagnostics (social-sdk doctor --adapter zernio --json), print the usage examples, and validate a request file against an adapter's schema. A team can run those checks before any token or managed-provider key is created.

Capability manifests are typed and loaded through explicit subpath imports, so a project only pulls the adapter it uses rather than every platform's dependencies at once.

The limits OpenCore states up front

Social SDK runs in trusted server-side code on Node.js 22.12 or newer, or Bun. OpenCore says explicitly: keep platform tokens, managed-provider keys, OAuth secrets and webhook secrets out of browser bundles. The capability matrix in the docs describes the normalized operations each integration implements and does not replace provider permissions, account eligibility or live verification: a team still has to apply for API access on each platform.

The managed-service adapters are sponsored, so a reader should know that the project's hosted-backend options include its sponsors. The direct adapters do not require a Social SDK account.

The latest release on GitHub is @opencoredev/social-sdk@0.5.0, published on 24 September 2026. The latest commit on main is from 29 September 2026, a documentation upgrade.

Source

• Social SDK GitHub repository, primary source: https://github.com/opencoredev/social-sdk
• Social SDK project site, with the installation guide and capability matrix: https://social-sdk.dev
• GitHub REST API for star and release information, queried 4 October 2026: https://api.github.com/repos/opencoredev/social-sdk