FAQ

Common questions about Social SDK hosting, pricing, runtimes, scheduling, live verification, and platform support.

No. Social SDK is a library. It provides no hosted service, database, queue, credential proxy, scheduler worker, or billing layer. Direct integrations call platforms with your credentials. Optional managed backends call Zernio, Post for Me, PostFast, Postiz, or Buffer with your own provider account; Postiz can be Postiz Cloud or an instance you host yourself.

What does it cost?

The package is open source under the MIT license. Anything else is billed or granted by the provider under your own account, and the models differ:

The X API bills developer accounts by usage. See X API pricing.
Meta (Threads, Instagram), Google (YouTube), TikTok, and LinkedIn publish no per-call fees for the APIs these adapters use. They gate access through app review, product approval, and quotas instead.
Zernio, Post for Me, PostFast, Postiz Cloud, and Buffer bill under their own plans. A self-hosted Postiz instance has no Postiz bill.

Check each provider’s current terms; these were checked on 2026-10-05. The SDK never pools keys or resells provider usage.

Which runtimes are supported?

Node 22.12+, Node 24, and Bun are the tested targets. The package is ESM-only; CommonJS is not supported. Deno, edge runtimes, and Cloudflare Workers are not tested targets.

Does it work in the browser or React?

No. The SDK is server-only because credentials and connected-account references are server secrets. There is no React dependency. Your frontend talks to your own server routes, which call the SDK.

Can it schedule posts?

Only where the route stores the post and publishes it later. Among direct adapters, only YouTube does; the others reject schedule during preparation because their platform APIs have no publish-time field. The managed backends (Zernio, Post for Me, PostFast, Postiz, and Buffer) schedule on the provider side. See native scheduling.

The SDK never runs background jobs itself. To publish later on other routes, run the publish from a job runner such as Trigger.dev, Inngest, or Restate.

Why did my publish return processing or unknown?

Platforms separate acceptance from publication. Processing means the platform is still working; unknown means the response was lost after dispatch. Both are reconciled explicitly with the saved delivery reference. Treating them as success or silently retrying can double-post. See references and outcomes.

Which platforms and operations are supported?

The platform matrix summarizes the direct adapters, and the capability matrix lists every declaration with its formats and limits. Support is specific to a backend, platform, operation, content format, runtime, and evidence level.

Has every adapter been verified against live accounts?

No. Current repository evidence is deterministic contract and fixture coverage plus mocked transports. The evidence levels page explains exactly what each level proves. Live verification requires approved accounts and credentials and is recorded separately when it happens.

How do I test without credentials?

Use the deterministic mock backend from the testing entrypoint. It supports explicit accounts, fixtures, scenarios, and a fake clock, so the quickstart runs without network access.

Can I access platform features the shared model doesn’t cover?

Yes, through typed native modules and the explicitly unsafe native escape hatch. Those paths bypass normalized middleware, so your application must supply tenant authorization around them. See native access.

What should I include in a bug report?

Run social-sdk version --json and social-sdk doctor --adapter <name> --json, then paste both outputs into the issue. version reports the installed package version. doctor lists the names of missing environment variables for the selected adapter and never prints their values, so its output is safe to share. See the diagnostic CLI for every command.