WeChat publish vs mass send: why QR login stops at drafts

Here is the short answer: “publish” in WeChat Official Accounts is not the same action as “mass send,” and QR login does not grant safe auto-publish rights. freepublish turns a draft into a public article URL without notifying followers and without consuming a mass-send quota. Mass send is the action that actually delivers the content to subscribers. For automation, the more important boundary is this: only API mode gives a tool a safe path to automated public publishing; if you only have browser QR login, the safest endpoint is usually draft creation.

That is where many teams make the wrong inference. Once they see a tool log in through QR code, upload a cover, and save a draft, they assume formal publishing should also be fully automatic. But for a local-first tool such as OmniGoAI’s OmniPost, WeChat has always been a layered system: draft creation, public publishing, and follower broadcasting are different actions; QR login and API mode are different capabilities. If you blur those layers, the first thing that breaks is usually not the code. It is the permission model.

If you are bringing WeChat into a broader content pipeline, these related articles provide useful context:

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

What exactly are “publish” and “mass send” on WeChat?

When content teams say “we sent the WeChat article,” they may actually mean 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 remain blended together, the automation design is almost guaranteed to drift. The second and third steps both look like “formal publishing” from a distance, but the platform semantics are very different.

Publish (freepublish)

The core job of freepublish is to:

1. start from an existing draft;
2. create a publicly accessible article URL;
3. avoid notifying followers;
4. avoid consuming the account’s mass-send quota.

In other words, publish is much closer to making an article publicly available than to broadcasting it. That makes it a strong automation boundary because it turns the article into a stable public asset:

• it can be referenced externally;
• it can be reused in your website, support replies, and knowledge workflows;
• it can serve as the source link in broader distribution;
• but one unattended task does not suddenly push the article to every follower.

Mass send (masssend)

Mass send is the action most operators intuitively mean when they say “send this WeChat article.” It means:

• the content goes into subscriber feeds;
• the audience is the full follower base;
• send slots and campaign timing matter;
• mistakes are harder to unwind than at the public-link layer.

So even if both outcomes make an article visible, they belong to very different risk classes. Publish is a safer public-availability action; mass send is a much heavier distribution decision.

Why should QR login stop at drafts?

This is the most common assumption in WeChat automation: if the tool can already log into the backend, why can’t it just publish the article automatically?

Because QR login solves “enter the backend session,” not “obtain a stable, scriptable formal publishing capability.”

QR login is excellent for draft-layer work such as:

• creating drafts;
• uploading covers;
• preparing the body and layout;
• handing the result to an editor for review.

Those actions depend on an authenticated backend session, not on a formal publishing API boundary. For content teams, that is already extremely valuable because it automates the repetitive preparation work.

But once the goal becomes “automatically publish the article,” the requirement changes. WeChat’s formal publish path is not just a simulated button click in a logged-in browser. It needs a more stable and auditable boundary. When only QR login is available, OmniPost deliberately falls back to draft-only or MANUAL_PUBLISH behavior, which protects you from handing a higher-impact action to a fragile web session.

Why can only API mode automate publish safely?

Because API mode is one of the few WeChat paths that provides a formal, script-friendly public-publishing boundary.

In practice, that usually means three things are all true:

1. the account itself is eligible, for example a verified service account;
2. you have the correct appId and appSecret;
3. the server’s public IP is allowlisted so the calls are explicitly authorized.

Only when those conditions are in place can a tool reliably map “formal publish” to freepublish. Even then, the action is still not mass sending. It is converting a draft into a public article URL.

That is why you need to read WeChat automation claims carefully. When OmniPost says WeChat can support automatic formal publishing, it means API-mode freepublish, not QR-mode browser automation that somehow mass-sends content.

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

This is one of the easiest misreads in WeChat operations.

A live article URL only proves that the article became a public page. It does not prove that followers received it. That misunderstanding distorts three downstream decisions:

1. status tracking becomes ambiguous;
2. quota tracking becomes inaccurate;
3. performance attribution becomes misleading, because traffic to a public page can come from your website, communities, search, or other references—not necessarily from follower delivery.

A safer status model is to record three different states:

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

Do not collapse all three into one vague “published” label.

Why is automation better suited to publish than to mass send?

Because publish solves the content-asset problem, while mass send solves the audience-delivery decision.

For content pipelines, the first one fits engineering naturally:

• write the article;
• validate it;
• deploy the website version;
• create a WeChat draft;
• if API mode is available, turn it into a public article URL;
• distribute the article to Zhihu, CSDN, Juejin, CNBlogs, and similar platforms.

That is a workflow centered on “content is ready and publicly available.”

Mass send belongs to a different layer of judgment:

• is this article worth spending a send slot on today;
• are the title, summary, and cover ready for a follower-facing push;
• should a human editor review it one more time;
• is this the right item in today’s editorial calendar?

Those questions should not be auto-answered just because article generation succeeded. For most teams, “automate publish, keep mass send human” is the healthiest WeChat division of labor.

When does the QR-login vs API-mode distinction become critical?

The answer is simple: the moment you introduce scheduled jobs or unattended publishing.

That distinction does not merely tell you whether the tool is connected to WeChat. It tells you how far the automation can safely go:

• QR login: best for draft preparation;
• API mode: safe path to freepublish;
• mass send: still a human-controlled action.

This is why many WeChat automations appear to be “almost working” and then stop at formal publish. The issue is often not writing quality or login success. It is that the platform itself draws the capability boundary there.

Practical advice for content teams

If you are designing WeChat automation, use this layered model:

1. Automate body preparation, cover handling, drafts, and website synchronization.
2. Treat publish as the public-link layer, not the follower-delivery layer.
3. Enable automatic publish only when API mode is fully configured.
4. Keep mass send as a separate human decision outside unattended jobs.
5. Record draft, publish, and mass send as separate statuses in logs.

That structure makes tooling boundaries, platform expectations, and team ownership much clearer. You no longer have to argue over what “this article has already been published” actually means: is it in drafts, live as a public page, or truly delivered to followers?

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

Frequently asked questions

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

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

Why can’t a tool auto-publish just because QR login already works?

Because QR login only proves the tool can enter a backend session. It does not provide a stable, scriptable formal publishing capability. Draft-layer automation fits QR login; formal public publishing usually requires API mode.

Does automatic formal publish in API mode mean automatic mass send?

No. In API mode, the automated action is still freepublish, which creates a public article page. It does not automatically push the content to followers.

How should teams record WeChat status in logs?

At minimum, split it into three states: draft created, public article published, and mass sent. That keeps your reporting, quota reasoning, and performance analysis honest.