WeChat publish vs mass send: what freepublish actually does

Here is the short answer: “publish” inside WeChat Official Accounts is not the same action as “mass send.” freepublish turns an existing draft into a public article URL, without notifying followers and without consuming a mass-send quota. masssend, by contrast, is the step that actually pushes the article into followers’ subscription feeds. If you automate content distribution, that distinction is not wording trivia. It defines the real safety boundary of the workflow.

Many teams see “auto publish” and assume it means “auto send to followers.” That assumption causes two kinds of mistakes: they either overestimate what a tool can safely do, or they put a high-impact broadcasting decision into an unattended job. For a local-first distribution layer such as OmniGoAI’s OmniPost, the better model is: WeChat can absolutely join an automation pipeline, but the automation boundary usually stops at draft creation or freepublish, not at mass sending on your behalf.

If you are also sorting out API mode, QR-login mode, draft creation, and public publishing, these two related articles help provide the surrounding context:

• https://omnigoai.com/en/blog/wechat-mp-api-draft-guide/
• https://omnigoai.com/en/blog/wechat-cover-auto-upload/

Why do teams keep mixing up publish and mass send?

Because in day-to-day editorial language, both actions sound like “sending an article out.”

When someone on a content team says “we published this WeChat post today,” they may actually mean one of three different actions:

1. saving the article into the draft box;
2. turning the article into a public URL;
3. pushing the article to followers.

If those steps stay blended together, automation design quickly goes wrong. Teams start assuming that:

• if a public link exists, the followers must already have received it;
• if a tool reports “published successfully,” today’s send quota must have been consumed;
• if QR login works, the tool should be able to finish the whole WeChat flow automatically.

None of those assumptions is reliable. WeChat is precisely the kind of platform where draft creation, public publishing, and follower broadcasting are separate layers. If you do not align the language first, the permission model and the workflow will stay blurry.

What does freepublish actually do?

The platform rule summary makes the key point explicit: formal public publishing on WeChat goes through “publish” (freepublish), not “mass send.”

More concretely, freepublish does this:

1. it starts from an existing article draft;
2. it turns that draft into a publicly accessible article URL;
3. it does not push the article to followers;
4. it does not consume the account’s mass-send quota.

That makes freepublish closer to making an article publicly available than to broadcasting it.

For distribution tooling, this matters a lot because it provides a much safer automation endpoint than mass sending:

• the article becomes a public asset with a stable URL;
• the URL can be archived, referenced, and reused across your publishing system;
• but one unattended task does not suddenly message your entire follower base.

That is why WeChat “auto publish” in tooling discussions often really means freepublish rather than subscriber broadcast.

Why is masssend a different class of action?

masssend is the action most teams instinctively mean when they say “send a WeChat article.” It is what actually delivers the content into subscriber feeds.

Compared with freepublish, it differs in at least four important ways:

1. The target is different.

freepublish creates a public page; masssend targets followers.

1. The risk profile is different.

freepublish is closer to putting an article online; masssend is a broadcast action whose mistakes are much harder to absorb.

1. The quota model is different.

The rule summary explicitly notes that mass send is quota-limited, while freepublish does not consume that quota.

1. The automation boundary is different.

A tool like OmniPost can safely automate the public-link step, but it should not automatically mass send on your behalf.

In other words, even when both outcomes make an article “visible,” they are not the same kind of visibility. Blurring them causes predictable errors:

• assuming the tool supports full automated follower delivery;
• treating “public URL created” as “campaign delivered”;
• handing off a human editorial decision to an unattended workflow.

Why does OmniPost treat formal WeChat publishing as freepublish rather than masssend?

Because it is the only public-publishing path that is both automatable and reasonably controlled.

Based on the WeChat rule summary and the OmniPost operating model, the practical logic looks like this:

• if the account is in API mode (verified service account + appId/appSecret + server IP allowlist), OmniPost can use freepublish to create a public article URL;
• if the account is only logged in through browser QR login, OmniPost can still prepare drafts, but a request for formal publish will fall back to MANUAL_PUBLISH rather than broadcasting or pretending to be fully automatic;
• automatic mass sending is intentionally out of scope, because it is a higher-impact, harder-to-reverse action.

That product boundary makes sense for three reasons.

1) Public availability is not the same as follower delivery

Many teams simply want:

• the canonical website article to have a matching public WeChat URL;
• that URL to be shareable and archivable;
• but not every article to become a follower push immediately.

For that need, freepublish is a better fit than masssend.

2) Mass send is an editorial and operational decision, not just a technical one

Mass sending raises questions such as:

• should we spend a send slot on this article today;
• has the article passed final editorial review;
• are the title, summary, and cover ready for the follower-facing channel;
• is this the right item in today’s publishing calendar?

A successful content-generation step should not auto-answer those questions.

3) freepublish fits content pipelines far better

In an automated flow that writes, validates, deploys to the website, and distributes to multiple channels, freepublish behaves like a stable “make this article a public asset” operation. It does not pretend to replace the final audience-delivery decision.

A common mistake: seeing a public link and assuming the article was mass-sent

This is one of the easiest misreads in WeChat automation.

Once teams see a live article URL, they often assume the content has already been pushed to subscribers. On WeChat, that conclusion is unsafe. A public URL only proves the article was published as a public page, not that it was mass-sent to followers.

That distinction changes at least three downstream decisions:

1. operational reporting becomes more accurate;
2. quota tracking stops being wrong;
3. performance analysis becomes more realistic, because public-page traffic can come from links, search, communities, and your website—not necessarily from follower delivery.

That is why WeChat status reporting should ideally be written as separate states:

• draft created;
• public article published;
• mass sent.

A single vague “published” label is too lossy.

How do QR login, API mode, freepublish, and masssend relate to each other?

Looking at all four together makes the workflow much easier to reason about.

QR login

QR login solves the question: can the tool enter a logged-in backend session and automate draft-layer actions? It is useful for:

• draft creation;
• preparing the article with its cover;
• handing the result to an editor for review.

But it does not automatically grant a safe scripted public-publish capability, and it definitely does not imply mass-send permission.

API mode

API mode solves a different question: does the account satisfy the prerequisites for a formal, scriptable public-publish path? That usually means:

• a verified service account;
• the correct appId and appSecret;
• a stable server public IP on the whitelist.

Only when that layer is in place can a tool like OmniPost reliably use freepublish.

freepublish

freepublish solves the public-link problem without notifying followers.

masssend

masssend solves the follower-delivery problem, and should remain a deliberate human-controlled action.

Put together, a realistic workflow often looks like this:

1. publish the canonical website article first;
2. create the WeChat draft through QR login or API mode;
3. if API mode is available, optionally publish it as a public WeChat URL;
4. decide separately whether it deserves a follower broadcast.

Which teams should stop at freepublish instead of chasing automatic mass send?

Honestly, most teams.

“Automatically publish a public link, then let humans decide whether to broadcast it” is a better fit for teams that:

• need a public article URL for archiving and reference;
• want to reuse that URL in communities, support workflows, or documentation;
• keep an editorial review step before follower-facing distribution;
• treat WeChat as one distribution node among several, not the only output.

Those teams usually care more about:

• whether the article is prepared correctly;
• whether a proper public URL exists;
• whether the final audience-delivery choice stays under human control.

From that angle, freepublish is already the right automation target.

When is it worth caring about the publish-vs-mass-send distinction?

The answer is simple: the moment you start automating anything.

Without that distinction, teams repeatedly get the following wrong:

• status labels;
• permission expectations;
• tool capability assumptions;
• risk controls around follower delivery.

The distinction matters even more in scheduled content pipelines. Automated jobs are a strong fit for:

• writing;
• validation;
• website deployment;
• search submission;
• WeChat drafts or public-page publishing;
• technical-platform distribution to channels such as Zhihu, CSDN, Juejin, and CNBlogs.

But the decision “should this article go to followers today?” is still much closer to editorial judgment than to content engineering.

Practical advice for content teams

If you are building WeChat automation, a clean design looks like this:

1. Automate drafts, covers, body formatting, and website synchronization.
2. Treat freepublish as the public-link layer, not the follower-delivery layer.
3. Keep mass send as a separate human decision.
4. Record draft, public publish, and mass send as separate statuses.
5. Only add API mode when you truly need unattended public-link publishing.

This gives you clearer tooling boundaries, clearer platform expectations, and clearer team ownership. It becomes much easier to answer a simple but important question: did this article become a draft, a public page, or an actual follower push?

If you want to connect website publishing, Chinese-platform distribution, and WeChat-safe automation into one repeatable pipeline, OmniPost is built for exactly that kind of boundary-aware workflow. Download it here: https://omnigoai.com/en/download/omnipost/ .

Frequently asked questions

What is the single most important difference between WeChat publish and mass send?

The key difference is this: freepublish creates a public article URL without notifying followers, while mass send is the actual subscriber-facing broadcast step. That is why freepublish is the safer automation target.

Does freepublish consume a WeChat mass-send quota?

No. The rule summary explicitly states that freepublish does not consume mass-send quota. The quota-limited action is masssend.

Why do some tools say they support “formal WeChat publishing” when they do not mean mass sending?

Because they are automating the safer public-publish action: turning a draft into a public URL. They are not claiming to replace the final follower-broadcast decision.

Can a QR-login account auto-run freepublish?

Usually not. QR login is best understood as a draft-layer capability. Automated freepublish generally requires API mode with the right account type, credentials, and IP whitelist setup.

When do I still need a human to mass send?

Whenever you actually want the article delivered to followers and counted as a formal send. That decision usually depends on editorial priority, timing, and final review—not just on whether a public link already exists.