Set up social integrations
Choose a social network, configure its credentials, and connect your first account.
Choose the network you want to connect. Each guide takes you through its setup, permissions, and a first test post.
If you use OpenPost Hosted, go straight to connecting your accounts. These guides are for people running their own OpenPost server.
Choose a social network
| Network | Connection requirements |
|---|---|
| Bluesky | Handle and app password |
| Mastodon | Server OAuth, usually automatic app registration |
| Pixelfed | Instance OAuth for photo publishing |
| PeerTube | Instance login and channel selection |
| Lemmy | Instance login and community selection |
| PieFed | Instance login and community selection |
| Discord | Channel webhook, or bot app with readiness records |
| Telegram | Instance bot, HTTPS webhook, and readiness records |
| Developer app; approved Page access if needed | |
| X | OAuth 1.0a app with write access |
| Meta app and a Page you manage | |
| Professional account with direct Instagram login or a linked Facebook Page | |
| Threads | Threads API app |
| YouTube | Google OAuth client and YouTube channel |
| TikTok | Login Kit and Content Posting API access |
| Business account, API app approval, and readiness records |
A developer app identifies your OpenPost instance. Connect each workspace's social accounts after configuring that app.
What you need
- Set your instance's public HTTPS URLs and check proxy and media access.
- Sign in as the instance administrator or prepare to edit the deployment's secret settings.
- Follow the network's guide above. You need access to the destination account, Page, channel, or community.
Save your provider credentials
Save the credentials from your network's guide using one method below.
Use the OpenPost settings form
For X, LinkedIn, Facebook, Instagram, Threads, YouTube, TikTok, and Mastodon:
- Sign in as the instance administrator.
- Open Settings → Instance → Configuration → Provider apps.
- Choose the provider and enter its client ID, client secret, and redirect URI. Mastodon also needs the instance URL.
- Save the app and restart OpenPost.
OpenPost encrypts saved secrets. Entries supplied by the environment appear as read-only. If an environment entry matches a saved app, the environment entry wins. Edit that entry in your deployment instead.
Use your deployment environment
Set OPENPOST_PROVIDER_APPS to a JSON array. The provider guides include complete examples. For a Docker Compose installation that uses env_file: .env, put the JSON on one line in .env:
OPENPOST_PROVIDER_APPS='[{"provider":"linkedin","client_id":"YOUR_CLIENT_ID","client_secret":"YOUR_CLIENT_SECRET","redirect_uri":"https://post.example.com/api/v1/accounts/linkedin/callback"}]'Replace the example values. Append other providers to this same array. Keep one OPENPOST_PROVIDER_APPS entry so adding a network does not replace existing credentials.
Use this method for Pinterest, Telegram, and Discord bot credentials, which the settings form does not yet expose. Bluesky passwords and Discord webhook URLs belong in the workspace connection dialog, not this registry.
Keep .env private and out of Git. If your deployment provides a secret store, set the variable there. You can also set OPENPOST_PROVIDER_APPS_FILE to a mounted file containing the JSON array. Recreate the Compose service to load changed environment values:
docker compose up -d --force-recreate openpostA plain docker compose restart does not reload changed environment variables. Keep the same database, media volumes, and encryption key when recreating the container.
Register the right callback
For OAuth providers other than Mastodon's code flow, the callback has this form:
https://post.example.com/api/v1/accounts/PROVIDER/callbackCopy the exact path from the provider guide into both the developer portal and OpenPost. Replace the example domain with yours.
Mastodon normally returns an authorization code that you paste back into OpenPost. Bluesky, Telegram, and Discord webhooks use their own connection steps and do not use this callback pattern.
Connect an account and check delivery
- Open Settings → Workspace → Social accounts.
- Choose the configured network and complete its connection flow.
- Confirm the account, Page, or channel shown in OpenPost is the one you intended.
- Create a small post in a format the network supports. Use the provider guide's suggested test.
- Open the post to check delivery, then check the post on the network itself.
A successful sign-in confirms access to the account. It does not confirm that every publishing permission, media URL, or optional feature works. Test the formats you plan to use before filling your calendar.
If setup fails, use connection troubleshooting. If the account connects but a post fails, start with publishing troubleshooting.
Readiness records for bot apps and Pinterest
Pinterest, Telegram, and Discord bot mode require administrator readiness records, including on self-hosted instances. Discord channel webhooks do not. Valid credentials alone do not enable a gated operation.
- Record the app's approval or permitted trial status using the operator readiness guide.
- Connect a test account. For Telegram, follow its guide's webhook registration order first.
- Run the first publishing test with
certification_testintent. It allows testing before earlier evidence exists, but still checks the app, account authorization, provider policy, and enabled runtime controls. - Record local and live test results for each required operation. Normal immediate and scheduled publishing need their own current evidence.
While signed in as an instance administrator, use /api/v1/docs on your own server to submit the records. Choose The OpenPost instance serving this contract as the server and leave openpost_session blank. The browser sends your session cookie. API tokens cannot perform these administrator operations.
There is no equivalent workspace settings form. Keep a provider unavailable until its required records and tests pass.