Connect a Mastodon instance and choose post visibility
Authorise a public HTTPS Mastodon server, verify the account and publish text or supported images with the intended visibility.
Use these steps in your selected Pixie CRM company workspace. The module, dependent tools and actions available to you follow its configuration and your permissions.
Social accounts → Mastodon; Configuration where applicable
PermissionManage connections; administrator for app credentials; Create posts + Publish posts for a live test
Before you begin
An authorised account on a publicly reachable HTTPS Mastodon instance. You do not need to paste a pre-created global client secret into Configuration.
Follow these steps
- Enter the public instance hostname in the Mastodon connection flow. The module registers an application for that instance and opens its official consent page. Approve the intended account.
- In Social accounts, choose Verify connection and compare the account or destination identity with the intended test account.
- Use supported text or images, keep composed text within this adapter’s 500-character limit and choose Public, Unlisted or Followers only. Video publication is not supported here.
- When a controlled test is authorised and the direct gate is enabled, select only this destination, choose Post Now once and inspect its existing receipt.
Fields and options
- Requested OAuth permissions
- read:accounts, write:statuses and write:media. These are the scopes requested by the current adapter; provider products/review must permit them.
- Destination and scope
- Application credentials are stored per instance. Internal hostnames, loopback/private addresses and unsafe destinations are rejected; this is not a connector to an internal HTTP service.
- Publishing format
- Use supported text or images, keep composed text within this adapter’s 500-character limit and choose Public, Unlisted or Followers only. Video publication is not supported here.
Rules and limits
- Saving credentials or passing connection verification does not prove that a live publication succeeded.
- Use a dedicated test destination and the most restrictive appropriate visibility. Provider consent, app review and organisational approvals remain separate requirements.
Check the result
- Open the account on that instance and verify the final post and visibility. Image processing may need reconciliation before the post is ready.
- Match the actual provider outcome to the destination receipt, remote reference and intended visibility.
If something does not look right
- If registration or consent fails, check public HTTPS reachability, instance app-registration policy and authorised scopes. Do not work around a rejected internal hostname.
- Do not repeat Post Now after an ambiguous result until the original provider outcome has been checked.
Common questions
Does a connected account mean publishing is approved?
No. Connection identity, app publishing entitlement, content eligibility and the separate direct-publishing gate are independent checks.
What is a complete first test?
Official consent, correct destination discovery, successful verification, one deliberate test publication, a destination receipt and direct verification in the actual provider account.