request_login vs add_account in OmniPost

If the account already exists in OmniPost and only its session expired, use request_login. If you want to connect a brand-new account that is not in OmniPost yet, use add_account.

That is the practical rule: restore an old account with request_login; grow your account pool with add_account. In OmniGoAI's OmniPost, that distinction is what keeps multi-account publishing predictable instead of messy.

People often blur the two actions because both eventually open a login flow. But operationally they solve different problems: one repairs an existing publishing node, while the other creates a new node you can later target, label, group, and audit.

What request_login is for

request_login is OmniPost's “re-login an existing account” action. In CLI form, the entry point is:

D:\soft\omnipost\omnipost.cmd login <platform> [--accountId id]

The OmniPost skill definition is explicit: this action is for an existing account. It opens a login window so a human can authenticate that same account again. If a session expires, cookies become invalid, or a platform asks for a fresh QR-code scan, this is the right fix.

Use it when:

1. the account is still listed in accounts, but no longer valid;
2. publishing fails with a login-related error such as NEED_LOGIN;
3. you want to keep the same accountId, label, history, and group membership;
4. you do not need another account on that platform—only the current one repaired.

So request_login is about session recovery, not account expansion.

What add_account is for

add_account maps to:

D:\soft\omnipost\omnipost.cmd account add <platform> [--label name]

This action creates a new account record for that platform. OmniPost generates a new accountId, which means the new account can live alongside the existing ones instead of replacing them.

That matters a lot in real publishing workflows. If you already have csdn:default and now want to connect another CSDN account for a second author or another content lane, the correct move is not to re-login default. The correct move is to add a second account and then target it precisely with targets or groups.

Use add_account when:

1. you need a second or third account on the same platform;
2. you want separate identities for different authors, brands, or traffic strategies;
3. you need to keep the current account active while onboarding a new one;
4. the new account should get its own label, group membership, and publishing history.

So add_account is about growing the account set, not repairing an expired session.

A quick decision checklist

When you are unsure, go through these questions in order:

1. Did this exact account already exist in OmniPost?

• Yes: prefer request_login.
• No: use add_account.

1. Do you need to preserve the current accountId and its history?

• Yes: use request_login.
• No, because this is a different identity: use add_account.

1. Do you want multiple accounts on the same platform to coexist?

• Yes: you need add_account.
• No, the old account just lost auth: use request_login.

1. Is the problem “the session is broken” or “the account pool is too small”?

• Broken session: request_login.
• Small pool: add_account.

A quick accounts run usually makes the answer obvious:

D:\soft\omnipost\omnipost.cmd accounts

If the account is already there but invalid, re-login it. If it is missing entirely, add it.

Why the choice affects publishing later

This is not just a login detail. It shapes everything that happens later in your publishing workflow.

OmniPost lets you publish with platforms, exact targets, or account groups. If you accidentally turn “I need a second account” into “I re-logged the default one,” you can distort your later targeting logic. And if you create duplicate accounts when the real issue was only an expired session, your groups, labels, and account-health checks become harder to trust.

This becomes even more important in multi-account content operations:

• request_login keeps the original account doing the original job;
• add_account introduces a new delivery node;
• mixing them carelessly makes it harder to know which identity actually published a post.

If multi-account distribution is part of your setup, these two related reads may help:

• https://omnigoai.com/en/blog/omnipost-platform-groups-vs-targets/
• https://omnigoai.com/en/blog/omnipost-multi-account-groups/

A safer operating sequence

A reliable order of operations is:

1. run accounts to inspect the current pool;
2. run check-auth for the account you plan to use;
3. if the account exists but is invalid, run login;
4. if the account does not exist yet, run account add;
5. after adding a new one, assign a label and update groups.

This is safer than reacting blindly after a failed publish, because it classifies the problem before taking action.

Common mistakes

Mistake 1: “It is the same platform, so it must be request_login”

Not necessarily. The platform can be the same while the identity is different. If it is a different identity, you are onboarding a new account, so use add_account.

Mistake 2: “Adding an account will replace the old one”

It will not. The whole point of add_account is coexistence. After that, you manage the accounts intentionally with labels, groups, and targets.

Mistake 3: “If publishing says NEED_LOGIN, I should delete and recreate the account”

Usually not. If the account already exists, request_login is the lower-risk repair because it preserves the existing account object and its operational context.

FAQ

What is the safest fix when an existing account loses its login state?

Check whether the account still exists in accounts. If it does, and only auth has expired, use request_login. That preserves the same account identity, history, and grouping.

Can I use request_login to connect a second account on the same platform?

No. request_login is for an existing account record. If you want a second identity on the same platform, you need add_account so OmniPost can create a new accountId.

When should I remove an account and add it again?

Only when you truly want to retire the old account record or you attached the wrong identity in the first place. For ordinary session expiration, request_login is the cleaner and safer repair.

Why does this distinction matter if both actions end in a login window?

Because operationally they produce different account models. One restores continuity; the other expands capacity. Once your account model gets messy, targeting, health checks, and publish debugging all get slower.

Bottom line

In OmniPost, request_login and add_account are not interchangeable. One restores an existing account; the other adds a new one. One tries to preserve continuity around the same accountId; the other intentionally creates another publishing identity.

If you run content across multiple platforms or authors, getting this boundary right pays off immediately. And if you want to turn that account model into a repeatable publishing workflow, you can download OmniPost here: https://omnigoai.com/en/download/omnipost/