Introduction

Two ways in

Both use the same API keys, the same permissions and the same rules. Pick the one that fits the tool on the other side.

• REST API at https://squidx.io/api/v1. JSON in, JSON out. For scripts, automations (Zapier, Make, n8n), and anything that speaks HTTP.
• MCP server at https://squidx.io/api/mcp. For Claude, Cursor, Codex and any client of the Model Context Protocol. The agent gets tools such as squidx_create_post and squidx_get_analytics, and only the ones the key allows. See MCP server.

Quick start

1. Open Settings › API and MCP access in the dashboard and create a key. Pick Read only to look, Read and write to also schedule and publish. The key is shown once.
2. Send it as a bearer token. The first call to make is /me:

curl https://squidx.io/api/v1/me \
  -H "Authorization: Bearer sqx_your_key"

Then queue a post for tomorrow morning:

curl -X POST https://squidx.io/api/v1/posts \
  -H "Authorization: Bearer sqx_your_key" \
  -H "Content-Type: application/json" \
  -d '{
    "segments": ["Shipping the squidX API today. Here is what it does:"],
    "status": "queued",
    "scheduledAt": "2026-09-24T09:00:00Z"
  }'

The response is the post as squidX stored it, with its id and the instant it will actually go out. From there, Posts has the rest: edit, reschedule, cancel, or publish right now.

Conventions

• Envelope. A success is { "data": ... }, plus meta on lists. A failure is { "error": "<code>", "message": "<sentence>" }. Codes are stable strings; messages are for people. See Errors and rate limits.
• Time. Every instant is ISO 8601 in UTC, in and out. The workspace timezone (from /workspace) only matters for posting slots.
• Ids. squidX ids are UUIDs. X ids (posts, users) are strings, because they overflow JavaScript numbers.
• Pagination. Lists take limit (1 to 200, default 50) and offset, and answer with meta.total.
• Versioning. The path carries the version. Fields are added, never renamed or removed, inside a version.

All endpoints