SynckHub Platform API

The complete interactive server reference covers every HTTP route registered by synckhub-server, including write and delete operations. Download the full OpenAPI JSON for tooling. Operations are grouped by server area and searchable by path.

For machine authentication and reads, follow the integration guide. For new files and same-file revisions, use the file-write workflows. The reference shows one complete server catalog; the read-only /openapi/integration-v1.json artifact remains available for existing clients.

High-value endpoint families

  • items and folders: create, move, rename, metadata, lifecycle
  • repo users and access introspection
  • authz rules, groups, effective permissions, authz events
  • metadata and full-text search
  • audit events: /repos/{repo_id}/audit/events
  • blob, content, and version-history surfaces

What the data plane is responsible for now

The catalog also includes these server areas; availability and access depend on deployment configuration, edition, and permissions:

  • shared links and public browse or download flows
  • tus upload intent and finalize flows
  • Office WOPI and Yjs session lifecycles
  • connected mail and calendar operations
  • structured-data and case-oriented operations
  • folder-backed company and contact entity views
  • chat, realtime, AI runs, tools, workflows, and external-indexing workers
  • server-side federation and native desktop synchronization
  • administration, maintenance, readiness, and metrics
  • CardDAV, webhook receivers, and internal service callbacks

That does not change the rule: repository context is still the center of gravity.

Working pattern

  1. use repo_id, the access token, and the API base URL from your SynckHub session
  2. send authenticated request to the owning SynckHub API base
  3. enforce least-privilege assumptions in client UX

Contract notes

Community and enterprise authz modes differ. Design client behavior around explicit permission checks, not role-name shortcuts.

Use the credential specified by the operation. WOPI uses a minted query token and Office proof headers; CardDAV uses scoped app credentials; callbacks and maintenance routes may require service credentials. Tus uploads use their upload-intent lifecycle and protocol headers. PROPFIND and REPORT are listed with CardDAV because OpenAPI cannot represent them as standard operation keys.

The catalog reflects the pinned server revision. It includes all registered methods and the automatic HEAD methods provided by GET routes. Handler validation and permissions remain authoritative; a route’s presence does not make it callable by every user or deployment.

Common mistakes

  • hard-coding one API base URL for all repos
  • inferring permissions from UI roles instead of checking server behavior
  • bypassing upload, save, or finalize lifecycles because they look inconvenient
  • assuming companies, contacts, cases, mail, and calendar all behave like plain files or folders in the API
Previous
Next
Next
Prerequisites