Social settings
Connect and disconnect network accounts over OAuth, refresh tokens, and govern publishing with approval chains, a risky-content classifier, brand-voice docs, and post archiving.
Social settings
Settings is where an admin wires the social workspace up and puts guardrails
around it. It has two halves: connected accounts (the OAuth lifecycle for
each network) served from /v1/social, and compliance (approvals,
brand voice, content flagging, archiving) served from /v1/social/compliance
(api/routes/social_compliance.py).
Live surface
Provider listing, OAuth connect/callback, enable/disable, disconnect, manual token refresh, approval chains, the risky-content classifier, brand-voice docs, and archiving are all real, tenant-scoped endpoints. Connecting and disconnecting accounts is restricted to admin/owner.
Connecting accounts
The provider grid is server-driven from GET /v1/social/providers, which
returns each registered network plus its capabilities and whether it needs an
app credential. Connecting runs a standard OAuth flow:
- 1
Configure app credentials
An admin adds the network's OAuth app credentials through the BYOK credentials wizard. Providers resolve them per-tenant, so nothing is shared or hardcoded. - 2
Start OAuth
POST /v1/social/{provider}/connectreturns anauthorize_url; the browser sends the admin to the network's consent screen. - 3
Finish OAuth
GET /v1/social/{provider}/callbackcompletes the exchange and redirects back to the app. The connected account lands intenant_social_accountswith its tokens BYOK-encrypted at rest.
Manage a connected account with PATCH /v1/social/accounts/{public_id} (enable
/ disable), POST /v1/social/{provider}/accounts/{public_id}/refresh (manual
token refresh), and DELETE /v1/social/accounts/{public_id} (soft delete +
token wipe). Tokens are auto-refreshed before use via ensure_fresh_token, and
secrets never appear in API payloads or audit events — only ids, kinds, names,
and the account's display name.
Publishing governance
The compliance settings (GET/PUT /v1/social/compliance/settings) let an
admin gate publishing and configure content flagging:
- Approval chains — set
approval_required: truewith an orderedapproval_chain. When a governed post lands in draft,maybe_open_approval_chainopens the chain; each step is approved or rejected viaPOST /v1/social/compliance/approvals/{public_id}/approve/.../reject, and the current status is readable per post. - Risky-content classifier —
POST /v1/social/compliance/posts/{public_id}/classifyruns an Anthropic-backed scan for the operator-enabledflag_categories(e.g. financial advice and peers) and records flag rows readable at.../posts/{public_id}/flags.
Brand voice
Upload brand-voice reference docs (POST /v1/social/compliance/brand-voice,
admin only) and retrieve them with RAG plus an optional Anthropic rewrite
(POST /v1/social/compliance/brand-voice/retrieve, backed by
suggest_with_brand_voice in core/social_compliance.py).
Brand-voice retrieval is a standalone endpoint today
The retrieve route returns the top matching brand-voice passages and, if a
query is supplied, an on-brand rewrite. It is not yet wired into the composer's
ai-improve or the inbox's ai-draft prompts — those AI paths run their own
instructions and do not automatically pull your uploaded brand-voice docs.
Consuming brand-voice retrieval from the composer and inbox is the planned next
step.
Archiving
Published posts are archived automatically, and
POST /v1/social/compliance/posts/{public_id}/archive performs a manual
archive; GET .../archive reads the archive row. This gives you a durable
record of what actually went out — useful for regulated industries and
after-the-fact review.