REST API

Inklate’s REST API exposes the same guarded operations as the dashboard and the MCP server over plain HTTPS and JSON. It is versioned under /api/v1 and fully described by an OpenAPI 3.1 document you can read or generate a client from.

• Base URL: https://api.inklate.com/api/v1
• Auth header: Authorization: Bearer <token> — an Organization API key (prefix inklate_) or an OAuth 2.1 access token. x-api-key: <token> is also accepted.
• Spec: curl https://api.inklate.com/api/v1/openapi.json (served unauthenticated)

Create a key under Settings → API in the dashboard — see API keys. A key is bound to one organization, so requests act on that organization automatically.

The lifecycle in one call

One POST /posts takes a post from nothing to drafted, scheduled, or published — the scheduled_at field decides which. The response always carries per-channel validation: ready, errors[] with machine fixes, warnings[], and any fixes_applied.

# one call: create AND schedule — Idempotency-Key makes a retry replay instead of duplicating
curl -X POST https://api.inklate.com/api/v1/posts \
  -H "Authorization: Bearer inklate_XXXXXXXX" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: 3f1c-announce-series-a" \
  -d '{
    "content": "We just closed our Series A.",
    "channels": ["chn_linkedin_page", "x"],
    "scheduled_at": "2026-07-21T09:00:00-07:00"
  }'

Omit scheduled_at to save a draft (a draft with validation errors saves fine — the response tells you what to fix), send "now" to publish immediately, or PATCH /posts/{id} later to change anything, the schedule included ("scheduled_at": null returns it to draft). channels mixes channel ids and provider names; only scheduling/publishing a post that isn’t ready refuses, atomically.

# the dry run — same validation response, nothing stored
curl -X POST https://api.inklate.com/api/v1/posts/validate \
  -H "Authorization: Bearer inklate_XXXXXXXX" \
  -H "Content-Type: application/json" \
  -d '{
    "content": "We just closed our Series A.",
    "channels": ["chn_linkedin_page", "x"]
  }'

The full reference lives in the API tab

Every operation has its own page — parameters, request and response schemas, and code samples — generated from the endpoint definitions the server mounts, so the reference cannot describe a route that does not exist.