Complete reference for every integration-facing endpoint in the SynC API. Each endpoint lists parameters, request body schemas and required permissions.
The endpoints every integration calls first. Health is unauthenticated; whoami and help confirm your credentials and let an agent self-configure.
GET /api/healthCheck API availability. No authentication required.
GET /api/whoamiReturns your identity, permissions, and rate limit status. Use to verify your API key works. `user.company_id` is your company: send it as subject_id to create or list your company library. `permissions` is the list GRANTED to the key — a declaration of intent, not authority: a key can only ever do what its OWNER can do, so effective power is this list intersected with the owner’s live abilities at call time. Two fields qualify it. `dormant` lists granted permissions the owner holds NOWHERE — every call gated on one of these will 403 until that changes; each entry carries a `reason` and, where the owner can fix it themselves, a `remedy` saying what they do (e.g. sign in and accept the Contributor License Agreement for wiki contribution rights). `scoped` lists granted permissions whose authority is per-resource — held on some projects/companies/standards and not others — so they cannot be reported globally and a 403 means "not on that resource", not "never"; pass the resource id and try another. A permission in neither list is held globally and unconditionally. There is deliberately no flat "effective permissions" list: enumerating permission x resource is unbounded.
GET /api/helpThe API catalog: every endpoint with its description, permission and parameters. No authentication required. The full answer is large. An AI client should start with ?format=index (one short row per endpoint plus how to authenticate and call SynC), then fetch one group in full with ?group=<group>.
| Name | In | Type | Description |
|---|---|---|---|
| format | query | string | "full" (default): every entry with all its fields. "index": one short row per endpoint (method, path, summary, permission, mutates, tier) plus a `guide` on authentication, revisions, pagination and errors, and the endpoint count per group. Any other value is a 400. |
| group | query | string | Only the endpoints under /api/<group>/, for example "projects", "standards", "datasheet", "files", "wiki". An unknown group is a 404 that lists the groups. Combines with format. |
/api/projects, 67 endpoints. Create, read, update, and publish construction projects. Projects own datasheets, standards, files, and members./api/standards, 40 endpoints. Read and edit standards (specifications) — the structured documents that define project requirements. Supports revisioning, working copies, and comments./api/datasheet, 19 endpoints. Datasheet instances are project-specific fill-ins of a standard. These endpoints read, revise, and upgrade datasheets./api/files, 14 endpoints. Upload, list, download, and delete files attached to projects. Files are scoped to project revisions./api/wiki, 64 endpoints. Read and edit the open SynC Standards wiki. Reads are public — no API key needed. Writes require the relevant wiki permission./api/libraries, 7 endpoints. Standard libraries group related standards. Each library is scoped to a subject (global, company, or project)./api/categories, 7 endpoints. Categories organize standards within a library. Like libraries, categories are scoped to a subject./api/integrations, 8 endpoints. Manage your own API integrations programmatically. Creating, editing, and revoking integrations requires session auth, not an API key./api/account/cla, 2 endpoints. The Contributor License Agreement gates contribution to the public SynC Standards wiki. Read it, and accept it to be granted the wiki:standard:read and wiki:standard:create permissions.