docs: multiple social accounts per network - #15
Merged
Conversation
The cap on how many accounts a workspace connects on one network is now a setting rather than a fact, and several pages stated it as a fact. - social-accounts: replaces "Connection limits (Cloud only)" with a section covering both modes, spells out which platform pairs share a network, and adds a reconnect section — reconnecting is now bound to one card, so the messages it can answer with are worth knowing - configuration: documents ALLOW_MULTIPLE_SOCIAL_ACCOUNTS and its fallback - list-social-accounts: warns that `platform` is no longer unique in the response, so integrations must key on `id` - youtube: the channel picker is gone; the channel comes from Google's screen - telegram: a reconnect has to be confirmed from the card's own channel, and no longer claims you can always connect as many channels as you like - facebook / instagram: pickers leave out what is already connected - instagram / linkedin: both networks are one card with a chooser, not two buttons — the old flow had been gone for a while - plans-and-billing: notes that the two LinkedIn and Instagram flavours share one network slot Adds a self-hosting Upgrading page. The release ships a migration that merges duplicate identities and deletes rows to make room for a new unique index, it runs unattended, and it is one-way — that needed somewhere to live, and the two places that tell you to run `migrate --force` now point at it.
Checked every factual claim in this branch against the code. Three did not hold up. The upgrade page invented its own deploy sequence, which diverged from the one in Production — it was missing `event:cache`. Two copies of the same routine is how docs go stale, so it now points at the existing one and covers only what is specific to upgrading. It also blurred two different outcomes when a merge leaves a post aimed at the same account twice. One target survives only when the post has not published there yet; once it has, every unpublished repeat goes. Spelled both out, since this is a page about a migration that deletes rows. The picker note claimed TryPost always speaks up rather than showing an empty list. True when filtering leaves nothing, but it also skips the picker entirely when exactly one identity is left, which is worth knowing.
CLAUDE.md already says the docs are cloud-first and that self-hosted specifics belong in a Note or the self-hosting section. This branch had not been reading it: the cap on accounts per network turned into a two-mode comparison in body prose, which makes every reader work out which half is theirs — including in api-reference, where the endpoints are documented against app.trypost.it. Cloud is the statement again. One account per network, two flavours of a network share the slot, add a workspace for a second account. Self-hosting gets a pointer at the end, matching how the rest of the knowledge base already handles it. The reconnect table also listed "Every account on this login is already connected", which only ever appears where multiple accounts are enabled — gone. Records the rule it broke in CLAUDE.md with the failing shape next to the working one, since the abstract version did not stop it.
…t do The self-hosting configuration page never told you the API reference applies to your instance. It does — same routes, same payloads, same MCP tools. What differs is the base URL and that responses follow the settings on that page rather than the Cloud plan, multiple accounts per network being the one you can actually see in a response. With that written down where a self-hoster reads it, the note on the endpoint goes back to being a cloud statement. Also says there that accounts are connected from the dashboard: every platform needs a browser to authorize, so the API only lists and toggles. Worth stating on the endpoint people reach for when looking for a way to add one.
Reading the branch as a whole rather than edit by edit turned up three things. The LinkedIn page told you to repeat the flow to add another identity, three lines above a note saying a workspace holds one or the other. The first was left over from the two-mode draft. The picker note claimed identities already connected get filtered out of the list. True of the code, invisible on Cloud: the connect card only renders when the network is empty, so there is never anything to filter. Rewrote it around what a Cloud reader actually meets — a picker that only appears when there is a choice — and dropped the same claim from the Facebook and Instagram steps. It also said a single available identity connects without a picker. That holds for Facebook, Instagram and YouTube, not for LinkedIn, which always shows its identity screen even when the profile is the only thing on it.
"If you try to connect an account that's already connected, TryPost will update the existing connection" was true when a connect upserted by identity. It no longer is: the network's slot is taken while an account sits in it, so there is no connect button to press. Refreshing an account is Reconnect, which the FAQ now points at.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Documentation for trypost#286, which lets a workspace connect more than one account on the same social network.
Why
The number of accounts a workspace can hold on one network used to be a fact — one on Cloud, uncapped when self-hosted. It is now a setting,
ALLOW_MULTIPLE_SOCIAL_ACCOUNTS, and several pages still stated the old rule as though it could not change.Reconnecting also changed shape. It used to be indistinguishable from connecting again; it now targets one specific card, which means it can refuse — and none of the things it says were written down anywhere.
What changed
The new setting
self-hosting/configuration.mdx— new section forALLOW_MULTIPLE_SOCIAL_ACCOUNTS, its default, and the fallback toSELF_HOSTEDwhen unsetHow many accounts, and which platforms share a slot
knowledge-base/social-accounts.mdx— "Connection limits (Cloud only)" becomes "How many accounts per network", covering both modes and naming the pairs that count as one network (LinkedIn profile + Page, Instagram Standalone + Facebook Business)knowledge-base/plans-and-billing.mdx— the Cloud social set now says those pairs share one slot, which the network list alone did not conveyplatforms/telegram.mdx— dropped "connect as many channels and groups as you like", which is only true where multiples are allowedReconnecting
knowledge-base/social-accounts.mdx— new section: what a reconnect keeps, why it can refuse, and a table of every message it can answer withplatforms/telegram.mdx— a reconnect must be confirmed from the card's own channel; posting the code elsewhere is rejected without consuming itFlows that no longer match the product
platforms/youtube.mdx— the channel picker was removed; the channel now comes from the account picked on Google's own screenplatforms/facebook.mdx,platforms/instagram.mdx— pickers leave out identities already connected to the workspaceplatforms/instagram.mdx,platforms/linkedin.mdx— each is one card with a chooser, not two separate connect buttons. This had been true for a while and the docs never caught up; fixed here since both pages were being touched anywayAPI
api-reference/endpoint/list-social-accounts.mdx—platformis no longer unique in the response. Two entries can share"linkedin", so integrations must key onid. The response shape itself did not changeNew page
self-hosting/upgrading.mdx— the general upgrade routine, plus a note for this release. Its migration merges duplicate identities and deletes rows to make room for a new unique index; it runs unattended and cannot be undone, so the page explains what it keeps, what it drops, and how to rehearse it against a database copy firstself-hosting/installation.mdx,self-hosting/docker.mdx— the two places that tell you to runmigrate --forcenow point at itdocs.json— page added under Self-hosting → ConfigurationChecks
docs.jsonstill parses; the edit is one line