utoploy
Automation

Schedule a LinkedIn post

Send it a post and it publishes to your connected LinkedIn profile right away, or at the time you name, fired by the platform.

Linkedin

What it does, step by step

  1. Read the post text, the optional publish time, and the post key from what was sent in.
  2. Decide whether this run is the 15-minute watchdog waking to reconcile an unconfirmed publish, or a normal post going out.
    • reconcile goes to "Reconcile the unconfirmed publish"
    • fresh goes to "Publish now or later?"
  3. If the claim is still mid-publish at its deadline and this exact attempt still owns it, mark it unconfirmed, with no second post to LinkedIn.
  4. The unconfirmed publish was settled, and it is never retried automatically.
  5. Decide whether a future publish time was named, or the post should go out right away.
    • later goes to "Wait for the publish time"
    • now goes to "Check the connection"
  6. Park until the named time; the platform scheduler wakes this automation then and the post publishes, laptop closed.
  7. When a scheduled wake-up arrives, check that this is still the current planned time before touching LinkedIn.
  8. Fetch a fresh short-lived token for the connected profile, which also checks the connection still works.
  9. Decide whether the saved connection still works, or needs to be reconnected by you.
    • yes goes to "Claim the publish"
    • reconnect goes to "Needs reconnect"
  10. The connection needs to be reconnected from Settings, so nothing publishes and the post is kept, never lost.
  11. Write this post into the Published posts list keyed by its post key, arm the 15-minute watchdog, and atomically claim the right to publish so only one run ever posts it.
  12. Decide whether this run won the right to publish, or the post is already handled (published, unconfirmed, or claimed by another run).
    • won goes to "Publish to LinkedIn"
    • settled goes to "Already handled"
  13. This exact post was already published or claimed, so it is never posted twice.
  14. Publish the post to your connected LinkedIn profile through the official Share API.
  15. Decide the publish outcome: published, cleanly refused (nothing posted, safe to retry), or unconfirmed (a post may exist, so never retry automatically).
    • published goes to "Record the published post"
    • failed_safe_to_retry goes to "Record the clean refusal"
    • publish_unknown goes to "Record the unconfirmed publish"
  16. Mark the Published posts row published, with the post id the network reported, only if this exact attempt still owns it.
  17. Release the claim so it is safe to try again, only if this exact attempt still owns it.
  18. Mark the row unconfirmed so it is never retried automatically, only if this exact attempt still owns it.

Build it just by talking to Claude

You do not wire this by hand. You describe it in a sentence, your Claude builds it, and Autoploy keeps it running.

Paste this to your Claude

Use the Autoploy MCP for every read and save in this task. If it is not connected, stop and tell me instead of improvising. What to build: Post now or schedule a post. Send it a post and it publishes to your social profile right away, or at the time you name, fired by the platform with your connection watched the whole way. This is for engineers and non-technical builders alike. How it behaves: 1. Runs when you send it a post: { "text": "...", "scheduleAt": "2026-07-15T09:00:00Z" } (scheduleAt optional). 2. Read the post text, the optional publish time, and the post key from what was sent in. 3. A watchdog wake-up, or a post? If reconcile, go to "Reconcile the unconfirmed publish"; if fresh, go to "Publish now or later?". 4. If the claim is still mid-publish at its deadline and this exact attempt still owns it, mark it unconfirmed, with no second post to LinkedIn. 5. The unconfirmed publish was settled, and it is never retried automatically. 6. Publish now or later? If later, go to "Wait for the publish time"; if now, go to "Check the connection". 7. Park until the named time; the platform scheduler wakes this automation then and the post publishes, laptop closed. 8. When a scheduled wake-up arrives, check that this is still the current planned time before touching LinkedIn. 9. Fetch a fresh short-lived token for the connected profile, which also checks the connection still works. 10. Connection still good? If yes, go to "Claim the publish"; if reconnect, go to "Needs reconnect". 11. The connection needs to be reconnected from Settings, so nothing publishes and the post is kept, never lost. 12. Write this post into the Published posts list keyed by its post key, arm the 15-minute watchdog, and atomically claim the right to publish so only one run ever posts it. 13. Won the publish? If won, go to "Publish to LinkedIn"; if settled, go to "Already handled". 14. This exact post was already published or claimed, so it is never posted twice. 15. Publish the post to your connected LinkedIn profile through the official Share API. 16. What did LinkedIn say? If published, go to "Record the published post"; if failed_safe_to_retry, go to "Record the clean refusal"; if publish_unknown, go to "Record the unconfirmed publish". 17. Mark the Published posts row published, with the post id the network reported, only if this exact attempt still owns it. 18. Release the claim so it is safe to try again, only if this exact attempt still owns it. 19. Mark the row unconfirmed so it is never retried automatically, only if this exact attempt still owns it. The tools: - LinkedIn (for "Where should the post be published?"). Shared memory: This automation remembers its work in a list called "Published posts" (Every post this automation has published or scheduled, one row per post.) that I can open in the Context section of my dashboard and see every row. Its columns are: post_key ("Post key"), post ("Post"), when ("Publish time"), status ("Status"), post_id ("Post id"), attempt ("Attempt"). Before anything runs, make sure the list exists: check with list_collections over my Autoploy MCP, and create it with create_collection (exactly that name, that purpose, and those columns) only if it is missing. Never create a second list under a similar name; reuse this one. The platform never creates a list silently at run time, so a missing list stops the work with a plain refusal. In the automation's code, write rows through ctx.collections.insert with an idempotency key built from the id of the thing the row is about (for example the booking id), so a replayed trigger can never write the same row twice. Read prior rows with ctx.collections.query when the automation must know what it already did. The platform: Connect to my Autoploy MCP server, call get_authoring_guide to read the authoring guide, and build the automation with the Autoploy SDK contract. Model every yes/no fork as a condition step with truthful labeled branches, keep every external side effect idempotent and keyed, and deploy it with deploy_automation. Before you build: Repeat the plan back to me in plain English and ask follow-up questions about anything unclear or ambiguous. Do not guess. Ask me for each key by name when it is time, and never ask me to paste a key anywhere except my own secure setup.

Start building

Free to start. No card needed.