Social / Postiz

This guide covers how the erxes company brain connects to Postiz for social media publishing. The Postiz integration lives under Social / Postiz at /agent/postiz in your workspace.

Who can enable Postiz

On the shared SaaS deployment, Postiz enrollment requires approval from a platform admin.
A workspace owner cannot enroll the shared deployment on their own; the request must be approved first.
Enterprise owners do not need this approval for their own deployment.

Enterprise enrollment

An enterprise owner connects Postiz from the Social / Postiz page.

The erxes origin must be a verified HTTPS origin.
Connect generates a single-use operator code.
The operator code expires 15 minutes after it is issued.
Use the code during that window; if it expires, generate a new one.

Workspace creation in Postiz

After connecting, the owner creates the Postiz workspace.

Choose a workspace name in Postiz.
Set a separate Postiz password, distinct from any erxes password.
The Postiz login email is derived from the server, not chosen by the owner.
If enrollment is retried, workspace placement in Postiz is preserved; retries do not create duplicate workspaces.

Initial erxes Postiz Admin

The owner selects the initial active erxes Postiz Admin during enrollment.

The admin can be any active tenant user, including an existing workspace member.
Selecting a user as Postiz Admin does not give the owner implicit access to Postiz. If another user is selected, the owner has no Postiz access through their ownership role alone.
The initial admin choice is immutable after enrollment.
Admins cannot change their own access level in Postiz.

Team membership

The erxes Postiz Admin invites active tenant users to Postiz.

Use Invite team member to add users with the Admin or Member role.
Only active tenant users can be invited.
Membership is managed inside Postiz after the initial setup.

Access boundaries

Postiz accounts are separate from erxes accounts.

erxes access does not create Postiz accounts and does not enable SSO into Postiz.
Postiz login and membership are managed separately from erxes users and permissions.
Provider OAuth is configured at the top level of Postiz, not per member.

Social channels require an operator-configured provider app before they can be connected.

Each social network needs provider app configuration and approval by the operator.
Team members create drafts in Postiz, then submit them for review.
After review approval, content is scheduled in Postiz.
Check delivery status in Postiz after the scheduled time; confirm the post was delivered, not just that it was submitted.

CMS publishing bridge

The CMS can publish content to Postiz, but this is disabled by default.

An admin must enable cmsPublishingEnabled to turn on CMS publishing.
CMS content permissions are independent of Postiz permissions.
The bridge is a signed server-to-server flow: content_api sends to agent_api, which forwards to the gateway, which reaches Postiz.
The CMS bridge is not an agent tool; it never runs through the assistant runtime.
JWT_TOKEN_SECRET must match between the CMS side and the agent side for the signed bridge to verify.
The legacy CMS_POSTIZ_SHARED_SECRET is retired; matching JWT_TOKEN_SECRET is the only supported bridge secret.

Expiry and revocation

When the operator code expires or access is revoked:

erxes access to Postiz is removed.
Direct Postiz sessions are not terminated.
Existing Postiz schedules are not removed.
Postiz data stays in place.
Only the erxes-side link is affected.