Control direct publishing by API clients
Allow trusted automation without weakening the brand's ordinary review policy.
An API client can bypass review only when its key has posts:publish and the brand has allow_direct_publish=true. Keep the setting off by default, isolate trusted publishers with dedicated keys, and require explicit confirmation for user-facing AI actions.
What this means in practice
An API client can bypass review only when its key has posts:publish and the brand has allow_direct_publish=true. Keep the setting off by default, isolate trusted publishers with dedicated keys, and require explicit confirmation for user-facing AI actions.
Use the documented brand and account boundaries consistently across the scheduler, REST API, SDK, MCP tools, SSE consumers, and webhooks. That makes the same social operation explainable to an operator and reproducible by an integration.
Implementation checklist
Document the exact automation that needs direct publication.
Create a dedicated key with no unrelated administrative scopes.
Enable brand direct publishing only after failure and rollback behavior is tested.
Use idempotency and target-level results for every automated dispatch.
Monitor audit events and revoke the key when the automation is paused.
Operational details
Direct publishing does not bypass provider capabilities, content policy, billing, or rate limits.
Jaxia scheduling, publishing, approvals, and inbox replies still require confirmation unless policy is already satisfied.
A content-generation service can create drafts without receiving publish authority.
Common mistakes to avoid
- Do not reuse a broad admin key for content automation.
- Do not treat AI-generated confidence as user confirmation.
- Do not enable direct publishing merely to make staging demos shorter.