# Set up SosoAPI for the person using this assistant Use the person's existing assistant and keep the original task, content and media references in this conversation. Use one SosoAPI MCP for their connected social accounts. Reuse an existing connection, or choose local or hosted access below. Setup does not publish a post. The person signs in and chooses what to authorize in their browser. Never enter their credentials or approve consent for them. Free does not require a card. ## 1. Connect this assistant Check the current host and its existing SosoAPI configuration first. Reuse a working connection; do not log out, overwrite configuration or create another connection just because this guide was opened again. For a local shell, check that Node.js 20 or later and npx are available. Use an existing supported runtime. If it is missing, explain the prerequisite in plain language; do not make privileged or global system changes automatically. Claude Code: ```sh claude mcp add sosoapi -e SOSOAPI_TOOL_PROFILE=core -- npx -y sosoapi ``` Codex: ```sh codex mcp add sosoapi --env SOSOAPI_TOOL_PROFILE=core -- npx -y sosoapi ``` After registering the server, check that you can call its tools in this conversation. If the host needs a reconnect or restart, tell the person which action to take. Wait until the tools work before saying the connection is ready. New connections use the existing 28-tool core profile for ordinary publishing, media, comments and insights. A working full-profile connection should be reused. If a requested administration operation is absent, explain that the full profile is available; hiding a tool does not grant or revoke permission. For a browser-only client such as ChatGPT with custom MCP app support, add this remote MCP URL and choose OAuth with automatic client registration: `https://gqeshlawtcexsapabaui.supabase.co/functions/v1/remote-mcp` No API key, client ID or client secret needs to be pasted. The person signs in to SosoAPI and chooses their Workspaces/actions. ChatGPT custom apps depend on its plan and developer-mode availability. Reuse a working local or remote connection if one is already configured. X supports original text and links. Each Organization shares 10 Free X credits once, or 100 per Pro billing period. Plain text costs 1; a Post containing a URL costs 10. Read `sosoapi_get_x_usage` with workspace_id before planning X usage. No automatic overage charge is made; an uncertain publication holds its credit reservation and must be reconciled before another send. ## 2. Sign in without an API key The first authenticated MCP call opens the existing browser sign-in and agent consent flow. The person can use Google, or register and verify their email. Let them choose their workspace and whether the assistant can only prepare content or can also schedule and publish. Do not ask them to copy credentials. Publishing consent is ongoing within the selected scope, not an enforced approval screen for each post. Keep key management off for ordinary posting. Email signup and sign-in use background security verification, without a checkbox for the person to solve. If verification fails, report the actual error and use the available retry action; do not ask the person to find or click a CAPTCHA box. The existing **Continue with Google** option is also available if the person wants to use Google; Google may require its own identity check. Let the person choose their account and approve access. Keep the current login/approval link and its return destination; do not replace it with a bare signup URL or silently switch to an existing maintainer identity. One sign-in error is not evidence that every sign-in method is unavailable. Pause only the step that needs the person's identity or consent. While they complete it, finish installation checks and prepare the original draft without inventing an account or workspace. Explain what is already ready and the one action needed next. After sign-in, re-read authenticated context and resume the same task. Do not disable CAPTCHA, use administrator signup APIs, ask for tokens, or claim the account/connection is ready before the actual flow completes. If the MCP tools need a host reload, the local CLI is also available to this assistant. Run `npx -y sosoapi auth status` first; use `npx -y sosoapi auth login` only when login is needed. Never read the credential file or print tokens. If login opens the wrong browser profile, stop that pending login before starting a fresh `npx -y sosoapi auth login --no-open`. The person opens the new printed link in their intended profile and checks the signed-in identity before approving. Never race two profiles on the same link. Use `--help` first to confirm this recovery flag exists in the installed CLI; if absent, explain the version limitation rather than inventing a working flag. The CLI can inspect its embedded contracts: ```sh npx -y sosoapi api contract --summary npx -y sosoapi api contract --route /studio-api/scheduled-posts/ ``` CLI request syntax is `sosoapi api post < request.json`. Write the JSON with your file tool; do not interpolate user content into shell commands. Read http_status and the response body, not only the process exit code. An API error is not success. Use only routes and schemas from the embedded contract; do not invent names or bypass a missing capability. ## 3. Connect the person's own social account Resolve the authenticated Organization and Workspace from SosoAPI context. Never guess identifiers or silently substitute a different workspace. If there is more than one suitable brand, ask which one the person intends. Use an existing connection when it is healthy. Otherwise run `npx -y sosoapi connect ` (instagram, threads, facebook, youtube or x) or give the person https://app.sosoapi.ai/connect. They complete provider consent and review the exact account in the browser. After they return, re-read the accounts and publishing capabilities. A connection callback is not proof that publishing is permitted. Reuse the original draft; do not ask the person to copy an internal identifier or recreate their content. ## 4. Complete the original posting task Use the person's existing request or ask what they want to promote. Do not invent a test post. Show the exact destination account, content, media and local date/time before the first submission. Confirm the timezone when it is unknown. Read current account capability facts; a personal Instagram account or missing provider permissions may need a supported account type or reconnection. X accepts original text and links only; keep media empty. X media, replies, quotes, reposts and thread publishing are not supported. For destinations that support media, register it before scheduling: for a local file use sosoapi_upload_asset within its permitted folders; for an external URL use sosoapi_import_asset_url and check sosoapi_get_asset_import_status with include_asset=true until the bounded import is ready. The ready asset.id becomes media.asset_id and asset.asset_url becomes media.url; no separate get_asset call is required. Keep the same import identity, honor retry guidance and stop on a terminal failure. A successful request is not proof that decoding/import has completed. If progress stalls, read sosoapi_job_status using that import's job_id before waiting again. A pending job can already carry an execution error. A service configuration error needs operator attention, not another import, a new social connection or permission from the person. Report the blocker without claiming the image is ready. Use the returned registered asset ID and canonical media URL together. Never schedule the original external URL or a temporary preview URL as a substitute. Reuse an existing ready asset only after checking its workspace and identity. Use sosoapi_get_scheduled_post_eligibility when an advisory preview is helpful; it is optional and does not replace canonical create/execution validation. Use the canonical Scheduled Post tools. One post is one destination. Reuse the same idempotency_key for retries of the same exact request; a changed draft is a new request. After a timeout, read the existing post before taking another action. Never blindly resend an uncertain provider write. Updates, cancellation and explicit retry use the current version and the server's action eligibility. The result must distinguish: - Scheduled: accepted for the stated time; not yet published. - In progress or reconciling: the final result is unconfirmed; do not resend. - Published: a provider-backed terminal result confirms the exact post; return its live link when available. - Failed or needs attention: say what is known and the next permitted action; reconnect only the affected account when the person must grant access again. For multiple destinations, report each separately. Do not call the whole task successful when only some platforms succeeded. For a future schedule, return the post IDs and accepted times; do not keep the conversation waiting until the due time or create a polling loop. On return, read the same posts again. The person can also revisit the exact result at https://app.sosoapi.ai/scheduled-posts/, using the actual ID returned by SosoAPI. That page requires their own authorized sign-in. For a custom environment, use its explicitly configured app origin instead. Do not promise to wake a closed assistant or send a success notification that has not been configured and verified. ## References - Human quickstart: https://app.sosoapi.ai/start - Product guide: https://sosoapi.ai/docs/quickstart - Supported scope: Instagram, Threads, Facebook Pages, YouTube and X original text/links. Formats and permissions vary by account; other platforms are not available simply because the person requests them.