Social publishing workflow lab
Inspect a publishing workflow before connecting an account. This lab combines executable examples, delivery decisions and a dated observation of the public Reeling MCP endpoint.
Reviewed 2026-10-21 · Reeling product team
Start with a reproducible offline check
The examples run with Node.js 22 or later and no third-party dependencies. Their default mode uses local fixtures or prints a request draft. It does not publish a post, require credentials or spend an AI allowance.
Run the tests, inspect the project and channel summary, then review the scheduling draft and status output. Passing fixture tests establishes the example’s local behavior; it does not demonstrate delivery to a live social account.
git clone https://github.com/yomariano/reeling-examples.git
cd reeling-examples
npm test
node examples/read-account.mjs
node examples/schedule-video.mjs
node examples/poll-status.mjsReview three workflow contracts
A useful demonstration shows the input, expected behavior and a failure case. Keep workspace selection, submission and delivery evidence separate when recording a tutorial or evaluating an integration.
| Stage | What to check | Evidence to retain |
|---|---|---|
| Select the workspace | Choose the exact project and owned channel; inspect destination capabilities. | A redacted account summary and the selection rule. |
| Draft the request | Review media ownership, destination, timezone, future date and visibility. Approve the write explicitly. | The redacted request and the reviewed adapter version. |
| Check delivery and recover | Poll the existing post ID with a bounded wait; inspect each destination result. | Per-destination status, public URL if returned, and any unresolved error. |
What does a successful request prove?
An accepted request is the start of a delivery workflow. Some destinations need additional actions, and an ambiguous timeout can occur after a request reaches the server. Review the existing item before attempting another write.
| Observation | What it establishes | Next check |
|---|---|---|
| Request accepted | The service accepted a submission. | Retain its post ID and inspect delivery status. |
| Scheduled or processing | Work remains queued or in progress. | Poll with a time limit; do not describe it as published. |
| Delivered to an inbox or companion | The content reached the next step in a handoff. | Complete and verify the destination’s required action. |
| One destination failed | That destination reports an error. | Inspect its error before repeating any successful destinations. |
| Submission timed out | The client did not receive a definitive response. | Look for an existing item before creating a duplicate. |
A dated public MCP observation
On 21 October 2026 we made five sequential tools/list requests to the public hosted MCP endpoint. The downloadable record contains the observation time, HTTP status, elapsed time, sorted tool names and a source checksum. No account credentials were used and no account tools were executed.
This small observation checks public tool discovery at one point in time. It is not a load test, uptime study, account authorization test or proof that any tool published successfully. Re-run the script to collect your own current result.
node examples/observe-mcp.mjs --samples=5 --writeMove from fixtures to an account deliberately
Create a Reeling project, connect the intended destination and generate an API key in Settings. First run the explicit live-read mode and select the correct project. Keep the key in local secret configuration.
The publishing example requires a separate --publish flag after request review. A Reeling API key is not a read-only credential. Live publishing may consume plan allowance and change an external account. Inspect the current platform requirements and exact REST or MCP schema before sending.
Reuse this lab in a useful tutorial
The example repository is MIT licensed. Include the tested revision, observation date, redacted inputs, expected output and a failure case when adapting it. Explain whether a step was run against fixtures, an authenticated read or a live publishing destination.
A useful comparison asks whether the workflow can select the intended account, express the required settings and verify the resulting delivery. Cite the current documentation for competing products and record unresolved limits instead of extrapolating from a successful request.
Try it with your own workflow
Start with the offline examples, check the intended account and choose the next action deliberately.
Open the runnable examplesCreate a Reeling workspace