Adapter
The product has an implemented path for the network and operation. This is code readiness, not account readiness.
Connection safety guide, reviewed 12 August 2026
How to connect social media accounts safely
A network logo in a dashboard does not prove an account can publish. Safe connection requires the correct identity, explicit consent, minimum scopes, provider approval where required, format-level testing, token lifecycle handling and a clean revocation path. Use this checklist before putting a client or brand account into automation.
Social APIs, permissions and review programmes change frequently. Verify the current official documentation and test with an eligible account before treating a connection as production-ready.
Separate the five readiness facts
Separate the five readiness facts
Permission
The provider and account granted the exact scopes, roles and app review needed for the action.
Delivery
A real eligible account completed the exact format and returned a remote object or other attributable evidence.
Inventory identities before OAuth
List the legal owner, business manager, page or channel, account type, administrators, recovery methods and intended operators. Confirm the person completing consent can act for the correct brand. A successful login with the wrong personal or test account creates a technically valid but commercially useless connection.
Record the destination identity in a human-readable form and retain the provider identifier returned after consent. Do not rely on an avatar or display name alone. For agencies, decide whether the client or agency owns the provider app relationship and who can revoke access when the engagement ends.
Request the smallest permission set
Ask only for scopes required by the visible workflow. Separate reading profile data, reading analytics, creating drafts, uploading media and publishing. Explain why each permission is needed at the moment of connection. A broad scope list creates review friction and increases the impact of a compromised token.
Treat provider approval and user consent as different facts. An adapter can exist before the provider approves the app. A provider can approve a capability while a particular account lacks the correct type or role. The UI and operational status should expose those distinctions instead of collapsing them into “connected”.
Protect tokens and connection events
Keep access and refresh tokens server-side, encrypted at rest and out of URLs, logs, analytics and browser storage. Bind OAuth state to the initiating session and verify redirect targets. Rotate secrets through a documented process and make token access observable without printing token values.
Log connection time, provider account identifier, granted scopes, expiry, refresh result and revocation. Alert on repeated refresh failures or unexpected scope loss. A disconnected or expired account should block direct publication and produce a clear owner action, not silently fall back to another account.
Test every network and format combination
Run a real canary for each combination you sell: text, image, vertical video, carousel, document or other supported format. Verify account type, media constraints, caption handling, destination, visibility, returned identifier and remote result. One successful text post does not prove video upload or analytics access.
Keep direct, notification, manual and unsupported paths explicit. Social providers control their APIs and can change permissions or formats. If a provider timeout leaves delivery uncertain, reconcile the remote state before retrying. At-most-once local locking reduces one class of duplicate risk but does not replace provider reconciliation.
Plan renewal, revocation and offboarding
Test expiry before it happens in production. Know whether refresh is automatic, when re-consent is required and who receives the alert. Provide a visible disconnect action and remove scheduled work or move it to a clearly manual state when permission disappears.
During offboarding, revoke provider access where appropriate, delete stored tokens, retain only the evidence required by policy and export client-owned records. Re-run the inventory after role changes, acquisition, employee departure or provider security notices. A connection is a lifecycle, not a one-time setup screen.
Official provider references
Official provider references
The provider links below are primary documentation. Exact scopes, review rules, formats and eligibility can change, so inspect the current version before implementation or purchase.
- Instagram Platform content publishingReviewed 12 August 2026
- TikTok Content Posting APIReviewed 12 August 2026
- LinkedIn Posts APIReviewed 12 August 2026
- YouTube Data API video uploadReviewed 12 August 2026
- Cascads network capability referenceReviewed 12 August 2026
FAQ
Social account connection FAQ
Does “connected” mean a tool can publish?
No. It may only prove consent. Publishing also depends on adapter, provider approval, account role, format support and a successful real delivery.
Should social media access tokens be stored in the browser?
No. Tokens should be kept server-side, protected at rest and excluded from URLs, logs and analytics.
How should an agency connect a client account?
Confirm ownership, role, provider app responsibility, granted scopes, destination identifier, revocation owner and offboarding plan before the first publication.
What happens when a social token expires?
Direct publication should block or move to an explicit manual path. The owner needs a clear re-consent action, and scheduled work must not silently target another account.
Continue with a focused path
Continue with a focused path
Test with one brand and one real account
Validate the workflow, permissions and evidence before expanding the scope.
Create a Cascads workspace