Syndroodocs
WebsiteGitHubOverview

Syndroo docs

Overview

The local syndroo workflow publishes from this machine, in the foreground, with no Syndroo server in the path. Its independent first-level commands are syndroo connect, syndroo publish and syndroo status. An optional syndroo server command family may operate a user-owned Cloudflare deployment. 0.7.0 available on npm; fixture-tested, with live-account acceptance still pending.

No live social-network call has been made from this project. Everything on this site describes the 0.7.0 release target, its schemas and its fixture tests. Treat every platform guide as unverified against a real account until you run it yourself.

The independent local commands

CommandWhat it does
syndroo connect <provider>Start, resume or maintain one provider connection. Credentials come from an explicit source; Core stores them and the plugin never sees the connection record.
syndroo publish --input <file>Prepare, execute or retry a publication. Preparing freezes the content and returns an approval token; executing needs that token on standard input.
syndroo statusRead providers, connections and operations. Read-only: it never contacts a platform and never repairs local state.

The full flag list, the exit codes and the global flags live in the CLI reference. Every command and flag printed on this site is checked against the built CLI before the site is published.

Optional self-hosted Server. The server commands deploy to your own Cloudflare account. server init uses 0.7.0 @syndroo/cli and @syndroo/cloudflare packages and installs project-local Wrangler. See the Deploy a server guide for the setup path and the CLI reference for acceptance limits.

1. Install Syndroo

Use Node.js 24.19.0 or newer and npm. Supported local writes require macOS or Linux. One command installs the CLI, provider SDK, and all five official platform plugins at 0.7.0:

npm install --global @syndroo/[email protected] @syndroo/[email protected] @syndroo/[email protected] @syndroo/[email protected] @syndroo/[email protected] @syndroo/[email protected] @syndroo/[email protected]

Verify the install with syndroo --version; it should report 0.7.0. Contributors who need a source build can follow the product repository README; readers do not need a checkout or build step.

Local CLI covers the configuration file, the state root and the first run in full.

2. Let an Agent set up

Paste this prompt into a local-shell Agent. It checks prerequisites, installs the pinned packages, resolves the bundled Skill below npm root --global, and asks whether you want the local or self-hosted Server workflow.

You are a local-shell coding Agent. Set up Syndroo 0.7.0 for me.

1. Check that Node.js 24.19.0 or newer and npm are available, and confirm that my platform is macOS or Linux for supported local writes.
2. Install Syndroo and its official platform plugins with:
   npm install --global @syndroo/[email protected] @syndroo/[email protected] @syndroo/[email protected] @syndroo/[email protected] @syndroo/[email protected] @syndroo/[email protected] @syndroo/[email protected]
3. Run `syndroo --version`. Resolve the global npm root with `npm root --global`, then read `<global-root>/@syndroo/cli/skills/syndroo/SKILL.md` and follow that bundled Skill. Do not run or invent a separate Skill-installer command.
4. Ask whether I want the local workflow or the self-hosted Server workflow, then continue with my choice.
5. For Server setup, ask whether I want GitHub. Create or push a repository only when I explicitly authorize it. Reuse authorization I have already given.
6. Keep secrets out of prompts, command arguments, logs, and tracked files. Publish content only with authorization for that content and destination.

The Server branch asks whether GitHub is wanted. Creating or pushing a repository remains opt-in; authorization already given is reused, and secrets must stay out of prompts, arguments, logs, and tracked files. Read the full Agent guide.

3. Connect one account

syndroo connect reads exactly one credential source: the environment variable SYNDROO_CREDENTIALS with --from-env, or a private JSON file with --credential-file. It never reads a .env file and never guesses.

export SYNDROO_CREDENTIALS='{"identifier":"you.bsky.social","password":"APP_PASSWORD_PLACEHOLDER"}'
syndroo connect bluesky --from-env --label work

The exact field names for all five providers are in Credentials, and each platform guide shows where the credential comes from.

4. Prepare, then execute

A publication is two phases. Write a request document, prepare it, and read the approval token that comes back:

{
  "type": "prepare",
  "content": { "text": "Syndroo publishes from the command line." },
  "targets": [{ "provider": "bluesky" }]
}
syndroo publish --input post.json --json

On a terminal the command prints the frozen preview and asks Publish to N accounts? [y/N/v]: only an unambiguous y sends, v expands the complete frozen preview and asks again, and n, an empty line or end-of-input cancels and sends nothing. --yes auto-confirms the frozen intent this run just prepared, without a prompt. With --json and without --yes the single envelope is the prepared result, confirmation_required with an approvalToken, and the command exits 0 without sending anything; with --yes --json the one call prepares, confirms and executes and prints exactly one final envelope, with no second prepared result and no approval token. Execute a prepared result by feeding that token back on standard input:

{ "type": "execute", "approvalToken": "<token>" }
syndroo publish --input - < execute.json --json

An execute request is only ever read from standard input, never from a file path or --data, so a token cannot be left in a shell history or in process arguments.

5. Read the result

syndroo status answers five queries. Pass the operation id from the publish result to see one operation, or page through the recent ones:

syndroo status --operation <operationId> --json
syndroo status --operations --limit 20 --json

A delivery is succeeded, failed with disposition not_applied, unknown, or not_started when it never reached a call. Unknown and not sent are different facts: an unknown write may have been accepted, so it stays non-retryable and the platform is inspected by hand instead of resending, while a target that never started was plainly not sent. The exit code carries the same distinction, and the exit code table lists it.

Where to go next

Still unresolved

UNRESOLVED. Hosted Syndroo service instructions, the public HTTP API and SDK, and earlier-release walkthroughs remain outside this documentation surface. This is separate from the optional user-owned Server deployment guide, and no page here describes a hosted Syndroo service as available.