Publish to multiple social accounts with one request.

1. Authenticate

Workspace API requests use a bearer API key. Keep live keys on your server and never embed them in browser code or an AI prompt.

Authorization: Bearer sk_live_...
Content-Type: application/json

2. Connect accounts

Start a managed OAuth flow for most platforms, then store the returned MonoChalk account ID in your product. Bluesky uses a handle and dedicated app password instead; the password is exchanged for encrypted session tokens and is never stored. Your application does not receive platform refresh tokens.

GET /v1/oauth/{platform}/start
POST /v1/oauth/bluesky/connect
GET /v1/accounts

Supported adapter names are facebook, instagram, threads, linkedin, x, tiktok, youtube, pinterest, and bluesky. Connection availability can vary during beta.

3. Create a post

Send account IDs, text, and optional media or scheduling information. Use an idempotency key so a retry caused by a timeout does not create a duplicate post.

curl -X POST https://app.monochalk.com/v1/posts \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: launch-post-2026-07-15" \
  -d '{
    "account_ids": ["acc_facebook", "acc_linkedin"],
    "text": "We just shipped our new release.",
    "scheduled_at": "2026-07-16T09:00:00Z"
  }'

4. Treat each target independently

A post has one delivery target per connected account. A multi-platform request can therefore be partially successful. Store target status instead of reducing the result to a single boolean.

{
  "id": "post_123",
  "status": "scheduled",
  "targets": [
    { "platform": "facebook", "status": "pending" },
    { "platform": "linkedin", "status": "pending" }
  ]
}

5. Handle normalized errors

Failures include a stable error code, the platform, and whether retrying is safe. Retry rate limits, timeouts, and temporary platform failures. Ask the user to reconnect or change media for non-retryable failures.

{
  "code": "RATE_LIMITED",
  "platform": "linkedin",
  "retryable": true,
  "message": "The platform temporarily limited this request."
}

6. Verify webhook signatures

Use webhooks for delivery outcomes instead of frequent polling. Verify the HMAC-SHA256 signature against the raw request body, reject stale timestamps, and make the consumer idempotent because a delivery can be retried.

Using MonoChalk from an AI agent

Put a narrow tool or MCP server between the model and MonoChalk. The tool should validate account IDs, enforce approval rules, attach an idempotency key, and return target-level status. Do not expose live API keys or raw social tokens to the model.

Beta limits and evaluation

Platform scopes, media constraints, rate limits, and connection availability can change as platform approvals progress. Before choosing MonoChalk for production, confirm that the platforms and operations your product requires are enabled for your workspace. The public health endpoint confirms API availability but does not guarantee a third-party social platform is operational.