My Telegram-to-Strapi publishing workflow

A voice note lets me record an idea before I've worked out how to explain it. A content calendar can still leave that recording waiting indefinitely.

Telegram gives me somewhere to capture the first version while I remember what happened. I can describe a failure, then consider what I'd change. Turning that recording into an article takes another pass for the reader, who needs enough detail to understand the claim.

My original Content fabric setup aimed at LinkedIn publishing. It now has a separate route through Strapi to a Gatsby website. That expansion made me define when an idea has been captured, when the article is ready, then when delivery has actually finished.

Let the first recording be unfinished

A voice note can contain repetition or an unfinished sentence. It can also wander into an example that doesn't explain the point. Asking for a publishable brief before recording would remove the reason I use this input method.

The first edit needs to identify what happened with the detail a reader would need. It should also preserve uncertainty. If the speaker says, "I think this helped," the brief needs to keep that qualification instead of claiming a proven business result.

My Content fabric prompt asks for thinking aloud to be converted into an actionable task. The cleaned brief should make the next step explicit while keeping the original intent recognizable.

Keep the recording with the brief. If a later article has lost a concrete detail, the recording lets me check what was actually said.

Give the article a stable address

A social post can carry one version of an idea. I want the full article at an address where I can edit its content, with a publication date visible beside its cover.

Strapi stores the content in this setup. Gatsby builds it into the public website. Each CMS entry contains the article body under a title with its slug. The excerpt supplies the listing text; tags help group the content, while the cover supplies the image. For a migrated gist, source fields preserve its identity with the original timestamps.

The display date records publication of the article version. Source dates record the earlier gist's history. This distinction is necessary for a model-launch note whose claims may have changed during the intervening year.

Strapi's REST API lets the client request a draft or published version through the status parameter. The website build needs the published version. A successful draft lookup proves that the draft exists, leaving publication to be checked separately. Strapi status documentation

Track the editorial stage

Research needs to support the argument before the text is revised. Critique can expose gaps in that argument; image direction has its own requirements. An automation's successful execution says which steps ran, while an editorial judgment determines whether their result is ready to publish.

I keep that editorial work separate from delivery. An interactive writing session can produce the article now; another writing tool could supply it later. Both can return the same fields to the publishing path, so changing the writing method leaves the delivery contract intact.

Each stage can also fail independently. A research service may be unavailable while the CMS works normally. A draft may await review while deployment is ready. Naming the delayed stage helps identify the action that could move it forward.

A status report should say which result exists. Capturing an idea creates an input. Research creates evidence for a draft. CMS publication makes the article available to a build, whose output still needs checking on the public website.

Trigger the build from publication

After publication, Strapi sends an event to an authenticated n8n webhook. My rebuild workflow filters the event before asking GitHub Actions to build the website.

n8n has separate webhook URLs for testing and production. Header authentication can protect the endpoint. Publishing the workflow enables its production endpoint, so a test inside the editor checks a different URL from the one Strapi needs afterward. n8n webhook documentation

Publishing articles close together can create competing builds. GitHub Actions concurrency groups control how pending jobs interact with running jobs. The policy needs to specify whether each intermediate snapshot must deploy or whether a newer content snapshot can supersede it. GitHub Actions concurrency

A webhook response confirms receipt of the event. Successful deployment confirms a later step. Opening the resulting article at its public URL checks that the completed work reached the reader.

Find the stage where work stops

I judge the system by whether a recorded thought becomes a readable page. That outcome can be inspected directly. Reach depends on distribution, with business results depending on more than the publishing mechanism.

The change to make depends on where work accumulates. Lost ideas need an easier capture method. A queue of drafts needs editorial attention. Finished articles waiting for a manual build need a delivery trigger.

For my workflow, the recording provides an easy starting point. Editing turns it into an article. Delivery finishes when the page is available at an address I can share.