Help center

SOPCompass API overview

The SOPCompass REST API reads your SOPs, libraries, boards, people and assignments, assigns SOPs and adds new SOPs, from your own code or a no-code tool.

Business plan Updated
On this page
  1. What you can build
  2. Endpoints
  3. Base URL
  4. Conventions
  5. What a key can see
  6. Versioning

The SOPCompass API lets your own code, Zapier, Make or n8n work with the SOPs in your workspace. It is part of the Business plan.

What you can build

  • A knowledge base mirror. Copy every SOP into an intranet, wiki or data warehouse and keep it current with updated_since. See Keep a knowledge base in sync.
  • An internal chatbot. Find the right SOP with full-text search, then read it in full and hand it to your model. See Build an internal chatbot on your SOPs.
  • Onboarding automation. When your HR system adds a new hire, assign their onboarding SOPs automatically. See Auto-assign onboarding SOPs.
  • Reporting. Pull assignments, including overdue ones, into a dashboard or a weekly report.
  • Content pipelines. Turn Markdown written elsewhere into a new SOP in one request.

Endpoints

Method Path What it does Scope
GET /sops List SOPs, oldest change first, with a cursor Read
GET /sops/{id} Get one SOP with its cards, steps and images Read
POST /sops Create an SOP from Markdown or plain text Read and write
GET /search Full-text search, best match first Read
GET /libraries List libraries, including shared-in ones Read
GET /boards List boards (pillars) Read
GET /people List workspace members Read
GET /assignments List assignments, newest first, with a cursor Read
POST /assignments Assign an SOP to a member Read and write

Base URL

Shell
https://app.sopcompass.com/api/v1

Every path in these docs is relative to that base URL. Always use HTTPS.

Conventions

  • REST over HTTPS. Resources are nouns, GET reads and POST creates. There is no update or delete endpoint in v1.
  • JSON everywhere. Responses are application/json; charset=utf-8. POST bodies must be JSON sent with Content-Type: application/json.
  • Envelopes. A success wraps its result in data. A list is {"data": [...]}; a single object is {"data": {...}}. Paginated lists add has_more and next_cursor. An error is {"error": {"code": "...", "message": "..."}}.
  • snake_case for every field and parameter, for example library_id and updated_at.
  • Timestamps are ISO 8601 in UTC with microseconds, for example 2026-09-18T09:41:07.004512Z.
  • Calendar dates (due_on, next_review_on) are YYYY-MM-DD.
  • IDs are UUIDs, for example 5b7e9d1a-2c4f-4e6b-8a1d-3c5e7f9a0b03.
  • Null, not missing. A field with no value is present and null. Lists with no values are [].
  • No caching. Every response carries Cache-Control: no-store.

What a key can see

An API key sees exactly what a member of its workspace sees in the app, no more:

  • The workspace’s own libraries and SOPs, plus libraries shared into the workspace from another one. SOPs and libraries from a shared library are marked "shared": true. Nothing else from any other workspace is reachable.
  • Archived SOPs are left out of lists and search, as in the app. include_archived=true on GET /sops adds the workspace’s own archived SOPs. An SOP you already have the id of can always be fetched, archived or not, and says so in archived_at.
  • New SOPs can only be created in the workspace’s own libraries.
  • Anything that belongs to another workspace answers 404 not_found, never 403, so a key can’t learn that it exists.

Versioning

The version is in the path (/api/v1), and every response carries this header:

Shell
X-SOPCompass-API-Version: v1

Within v1 we only make additive changes:

  • new endpoints;
  • new optional parameters;
  • new fields in responses;
  • new error codes.

Write your integration so it ignores fields and error codes it doesn’t recognize. Anything that would break an existing integration, such as removing or renaming a field, changing a type or changing a default, ships as /api/v2, and v1 keeps working alongside it. Every change is listed in the changelog.

Note: The API is a Business plan feature. If a workspace moves to another plan, its keys stop working with 403 plan_required until it moves back. See Authentication and API keys.