Initial situation
The text is ready, the picture is ready, the link is ready. Then a manual circle through the channels begins.
Each channel has its own requirements. Telegram —its own markup and its own behavior with link preview. VK has its own markup and its own way to attach an image. LinkedIn cuts off the post after the first lines and hides the rest under “more,” so the first paragraph is rewritten under attack. Short formats are strictly limited in length, and the text has to be cut. Website and newsletter are two more options.
One text is rewritten as many times as there are channels. The image is loaded the same number of times. The link is inserted manually - and some publications are left without a source label, because the label was typed from memory.
Second loss - out of sync. The typo was found after publication, corrected in two of the four channels, the old version lives in the rest. A month later, no one remembers which is which.
The third is exit time. Manual publication happens when a person gets his hands on it. This is usually not the time when the channel is read.
Fourth - failures. The network fell off in the middle, the API response did not arrive, the person clicked “send” again. There are two identical posts in the channel, and you also have to delete them manually.
The background switches between tabs, each with its own authorization and its own whim.
What did you watch?
The scale of a task is measured by facts, not by the feeling of “long”.
- Time from finished text to last publication. Time the clock on three to five materials in a row.
- Actual channel coverage. Download the history of publications for the month for each channel and check by text: how many materials reached everywhere, how many got stuck in one or two. The intention to publish everywhere and the fact are very different.
- Percentage of links without tags. Calculated using the same upload: there is a link, there are no parameters.
- Dispersion of publication time of one material —from the first channel to the last.
- Number of takes and posts shot.
A separate boring job for a couple of hours - a table of channel requirements: character limit, supported markup, is an image required, how does a link preview behave, what happens with several images, is there an API and what can it do, how authorization works and how long the token lasts. This table determines the entire further design, and without it the conveyor is assembled blindly.
A sign that the problem is generally solved by automation: the core of the text is more than half the same between channels, and the differences come down to the format. If each channel has its own essentially written material, you need an editor, not a conveyor belt.
What was changed
1. One source. A file in a repository or a row in a table. Fields: the core of the text, pictures, a link without parameters, the desired publication window, a list of channels and - only where there is no other way - redefining the text for a specific channel. Overriding is allowed, but not by default, and lies next to the kernel in the same file.
2. Channel adapter. Small function: the input is the source, the output is a ready-made payload for the API. Everything capricious lives inside - cropping to the limit along the sentence boundary, markup conversion, the decision to “attach an image or give a preview link,” the order of loading media. A new channel has appeared - one file is added, the rest are not touched.
3. Queue. Between “material is ready” and “post published” there is a state store: a JSON file, a table, anything with a reliable record. One recording - one material in one channel. Fields: status (queued / sending / sent / failed), number of attempts, next time, external publication identifier, error text.
4. Idempotency key. Composed of the material ID and channel name. Sending checks the key before the request and writes the result immediately after the response. A replay after a failure does not create a second publication—the post already has sent and an external id.
5. Scheduler. cron, launchd, systemd timer - any. Once every few minutes, it picks up records that are due. The output of the material ceases to depend on when a person reaches the tab.
6. Links are collected by code. One function builds an address with labels from the source and channel name fields. You don’t write the link into the text by hand at all - then the share of publications without tags drops to zero, not by force of will, but by design.
7. Two-phase APIs. Some platforms publish in two steps: create a container with content, wait for processing, publish by its identifier. The wait lives inside the adapter, with a timeout and a clear error instead of an endless loop.
8. The act of writing is separated from the act of reading. The command that actually publishes is called explicitly and separately. Queue viewing, dry run, format checking are safe and can be called as often as you like.
9. Report after. Once a week, using saved external identifiers, it collects what came out and how it was distributed. Labels in links provide a cross-section of channels in general analytics without a separate dashboard.
What was not touched
Writing text. The conveyor belt delivers, but does not compose. Auto-posting, combined with auto-generation, quickly turns the channel into noise, and subscribers into exes.
Comments and responses to readers. Remains in native applications. The response to the comment is a conversation, there is nothing to deliver it on schedule.
Channel analytics. The first step is not to compile the statistics of all sites into one dashboard: there are enough tags in the links to understand where they came from.
Image rendering. If a template or script for pictures has already been assembled, it remains as is, the conveyor takes the finished file.
Manual mode. The ability to publish one post in one channel manually bypassing the queue is preserved - with a note in the source so that the weekly report does not lie.
Reversibility
- Dry run. Flag when the adapters work completely, the result is written to the log, the request to the API does not go away. The first run of a new channel is always like this.
- Queue pause. Field in the config or flag file: the scheduler wakes up, sees a pause and leaves. Stops everything in a second without breaking anything.
- Removing the schedule. Returns the previous manual mode entirely: the sources remain regular files, you can publish by copy-paste, as before.
- The automation does not know how to delete a published document. An erroneous post is removed by a person in the channel interface, the entry in the queue is marked manually. The script is not given the right to delete other people's publications.
- Tokens and keys are located separately from the code and are responded to in the platform account in a minute. A revoked token stops one channel without affecting the others.
Boundaries
Channels without API. Some platforms either do not allow publishing programmatically or allow access only to business accounts after verification. The bypass through browser control breaks at the first redesign and gets blocked.
Coordination. If the post goes through a lawyer, customer or compliance, the bottleneck is approval, not publication. The conveyor here speeds up the last step of five.
Formats with manual labor. Video for each channel with its own aspect ratio and subtitles, carousels, stories - file delivery is automated, but not its preparation.
Small volumes. A couple of materials per month: assembling and maintaining the pipeline will not pay off, and the tokens will go bad between publications.
High cost of error. The official channel of the company, where an incorrect post is expensive: the queue remains, but the last step is taken by a person using a button.
Different audiences. If channels are read by different people with different tasks, a single source gives an average text that does not work anywhere.
One line rule: publishes a queue, not a person or a model - one source, adapter per channel, idempotent key for each attempt.