Syndroo
Manual HTTP workflow
Any agent or script that can send HTTPS calls POST /v1/posts with your Bearer token. You
confirm the text before it leaves the client.
0.2.0-rc.1 Unpublished release
candidate
Publish from your AI agent.
Give your agent or script one authenticated HTTP call. Syndroo accepts the post, queues one publication per platform, and reports what each platform actually did.
Self-hosted on your Cloudflare account Bring your own platform credentials Text publishing
Where this stands: agent setup today means wiring your own agent to the documented HTTP API. Syndroo ships no skill, plugin or MCP server yet, and no platform client has passed live-account acceptance.
One request, four documented outcomes
The same scenario drives both views: what your agent shows you, and what the API returns at each step.
Simulated - no posts are sent
Ready. Nothing has been sent.
What the agent shows you
What the API returns
Show the status response
Per-platform results
Available adapters in the 0.2.0-rc.1 candidate
Text only. No platform has a live-account acceptance record yet, so each one keeps its honest status.
Each guide lists the credentials that platform needs and what has actually been verified. Start with Bluesky.
Agent setup
Connect an agent, not an account
Syndroo is an endpoint, not a hosted service. Your agent holds its own instructions; the Worker holds the platform credentials and does the publishing.
Skill or plugin
No Syndroo-authored skill, plugin or tool package exists for this candidate. There is nothing to install, and no fake install command is published here.
MCP server
This version ships no MCP server and no SDK package. The supported interface is the documented HTTP API.
How it works
Acceptance, delivery and failure are three different things
The reply to a request is an acceptance receipt, not a delivery report. That is why it says
queued, and why every platform keeps its own stored status that you can read back.
One accepted request, one publication per platform
POST /v1/posts validates the request and stores one row per selected platform, then answers
with HTTP 202 and status: "queued". That receipt does not confirm platform
success, and it is not proof that a platform has not published yet; only the post's own status and
publications tell you what happened.
Delivery happens in the background
A Queue consumer claims one publication and calls that platform once. A failure on one platform never re-sends the platforms that already succeeded.
Retries are bounded and explicit
A retryable failure waits at least 60 seconds, then 120, and stops after three total attempts. A timed-out write is recorded as ambiguous and is never resent automatically.
You can always read the result back
GET /v1/posts/{id} returns the post status plus every platform's own status, error code and
identifier, so automation can stay honest about what happened. Scheduling uses the same surface:
scheduledAt is scanned by a Cron Trigger every 15 minutes.
What it runs on
A Cloudflare Worker with D1 for the stored post and publications, Queues for immediate delivery, a Cron
Trigger for scheduled work, and one explicit adapter switch per platform. Unconfigured platforms are
rejected with 422 and PLATFORM_NOT_CONFIGURED before anything is stored.
Recipes
Three jobs people actually run
Each recipe has its inputs, the exact request, the expected responses, and what to do when a platform fails.
Ship a product update
Post a release note from your own machine or pipeline, with a shorter first line for Bluesky.
Summarize a blog post
Summarize the article in your own client, then publish the summary to the platforms you chose.
Call it from CI
Send one authenticated request from a pipeline step and poll the post until it reaches a terminal state.
Why Syndroo
Boring answers to the parts that go wrong
Ownership stays with you
You deploy the Worker into your own Cloudflare account and choose SYNDROO_API_KEY. Platform
credentials stay in your secrets.
Retries stay honest
An optional Idempotency-Key ties one key to one logical post: a replay returns the original
result, while the same key with different content returns 409.
Ambiguity stays visible
A timed-out platform call is stored as failed with errorAmbiguous: true. Nothing is resent
automatically, and a person decides what happens next.
FAQ
A few things to know
Is 0.2.0-rc.1 released?
No. It is prepared in the repository but not published, tagged, deployed or accepted as a release.
Do I need a Syndroo account?
No. You deploy the Worker to your own Cloudflare account, set your own SYNDROO_API_KEY, and
add platform credentials as secrets.
Is there a Syndroo skill, plugin or MCP server?
No. The interface is the documented HTTP API. Agent setup means pointing your own agent or script at your deployment; no installable Syndroo package exists for this candidate.
Which platforms work right now?
Bluesky and Threads are exercised locally by the Mock SNS end-to-end gate and have no live-account
acceptance record yet. X, Tumblr and LinkedIn are experimental. Unconfigured platforms return
PLATFORM_NOT_CONFIGURED.
Can I publish images or video?
No. Every installed adapter is text only, with per-platform length limits enforced before publishing.
What happens if a platform call fails?
Retryable failures wait at least 60 seconds, then 120, up to three attempts in total. Ambiguous outcomes are never retried automatically.
How precise is scheduling?
scheduledAt takes an ISO date-time with an explicit timezone. Cron looks for due posts every
15 minutes, and queue and platform time are added on top, so the requested time is the earliest intended
time rather than a promised delivery time.
Start with one platform
Deploy your Worker, configure one platform's credentials, and send one post you are happy to see in public. The first-post guide takes one platform end to end.
