Topolo Docs Topolo Platform
Open workspace

Check Socialize publishing readiness

Inspect the connected-account readiness of one authorized brand across seven platform groups before planning social content.

Outcome

Inspect the connected-account readiness of one authorized brand across seven platform groups before planning social content.

Before you start

  • Use the intended environment and the same verified organization throughout. This guide grants no access.
  • Discover granted canonical Socialize workspaces through supported Auth/resource discovery. A brand uses the Auth workspace id; display names and provider account ids are not substitutes.
  • Select resource context separately from action input. Application permission and workspace access are both required; organization ownership alone does not establish access.
  • Published application permission: app_topolo_socialize.accounts:read.

Find the target

  • Use the canonical Socialize workspace id returned by supported Auth/resource discovery. A provider account id, campaign id or display name is not this input.
  • A named brand must be granted to the original credential; a wrong named resource does not silently fall back to another workspace.

Request

GET /api/brands/{id}/publishing-readiness

FieldRequiredMeaning
idYesCanonical Socialize brand/workspace id. Non-empty string; no extra input properties.

Interpret the response

  • The input id and returned brandId are the canonical Auth workspace id. Access is verified before loading connections.
  • The response has seven platform groups: x, linkedin, facebook, instagram, threads, tiktok and youtube. x groups the twitter provider; linkedin groups personal and company connections.
  • connected is true when at least one matched connection is active. canSchedule is true when an active connection has error_count equal to zero and no last_error.
  • With a usable connection, reason is omitted. Without an active connection it is account_not_connected; active connections with errors produce connection_error. connection_unavailable is the handler’s remaining fallback.
  • The schema also permits token_expired, but this reviewed handler does not select it. It does not directly test token expiry or perform a provider publish. Do not describe canSchedule as a guarantee that a post will succeed.

Effects

  • Workspace authorization can insert a missing local brands mirror or update its organization/status to active before returning. The source labels these actions read-only, but that is not a guarantee of zero storage writes. They do not create, schedule or publish a campaign/post.
  • Reads local connection rows and Nexus connection metadata, matching by nexus_connection_id. A local row with no matching Nexus connection does not contribute to readiness. No social post is sent by this handler.

Worked examples

These examples are synthetic and unrun. Replace the example identities with discovered, authorized resources; the examples provide no execution approval.

No active connections

Request

{
  "id": "ws_socialize_example"
}

Response illustration

{
  "brandId": "ws_socialize_example",
  "platforms": {
    "x": {
      "connected": false,
      "canSchedule": false,
      "reason": "account_not_connected"
    },
    "linkedin": {
      "connected": false,
      "canSchedule": false,
      "reason": "account_not_connected"
    },
    "facebook": {
      "connected": false,
      "canSchedule": false,
      "reason": "account_not_connected"
    },
    "instagram": {
      "connected": false,
      "canSchedule": false,
      "reason": "account_not_connected"
    },
    "threads": {
      "connected": false,
      "canSchedule": false,
      "reason": "account_not_connected"
    },
    "tiktok": {
      "connected": false,
      "canSchedule": false,
      "reason": "account_not_connected"
    },
    "youtube": {
      "connected": false,
      "canSchedule": false,
      "reason": "account_not_connected"
    }
  }
}

Each platform reports disconnected and cannot schedule. This does not create a connection or authorize a connect operation.

Mixed connection readiness

Request

{
  "id": "ws_socialize_example"
}

Response illustration

{
  "brandId": "ws_socialize_example",
  "platforms": {
    "x": {
      "connected": true,
      "canSchedule": false,
      "reason": "connection_error"
    },
    "linkedin": {
      "connected": true,
      "canSchedule": true
    },
    "facebook": {
      "connected": false,
      "canSchedule": false,
      "reason": "account_not_connected"
    },
    "instagram": {
      "connected": false,
      "canSchedule": false,
      "reason": "account_not_connected"
    },
    "threads": {
      "connected": false,
      "canSchedule": false,
      "reason": "account_not_connected"
    },
    "tiktok": {
      "connected": false,
      "canSchedule": false,
      "reason": "account_not_connected"
    },
    "youtube": {
      "connected": false,
      "canSchedule": false,
      "reason": "account_not_connected"
    }
  }
}

LinkedIn has an active connection without recorded errors; X has an active connection with errors. This is a snapshot of connection metadata, not a publishing test.

Errors and recovery

  • 403 workspace_forbidden: Use the intended existing workspace grant. Unknown and inaccessible brands share this denial; stop rather than probe other ids.
  • 500 failed_to_fetch_publishing_readiness: Preserve the request id and organization/workspace context and ask the application owner to inspect the failure. This handler’s generic failure code differs from the catalogue’s generic error examples.

Catalogue error metadata additionally lists authentication_required, permission_denied, rate_limited, invalid_input and dependency_unavailable. Those are declared platform-level recovery categories, not captured responses or proof that each application handler emits that exact body. Preserve the actual status, body and request id. Do not invent an error envelope.

This read does not create or publish campaign content and needs no content rollback. Authorization may synchronize a local brand mirror; do not delete or rewrite that mirror as recovery. After a read failure, preserve context and investigate the actual error before any further operation.

Change log

  • 2026-10-21: Added action-specific discovery, response interpretation and illustrative examples from source f8e30bad6947f868302f24e9cb31b6a2bdd1fbf6. Explicitly documented authorization mirror writes and the limits of read-only/readiness metadata. Current input/output/permission declarations were rechecked; no business action or provider test was run.

Source

Reviewed immutable Socialize source and the current credential-visible action declaration. This documents the reviewed implementation; it does not certify which source is currently deployed.