# Introduction

Sync ECM is a complete enterprise content management system (ECM) built from the ground up for agentic workloads. Our RESTful APIs can be used to access the ECM's full functionality programmatically. There are two main sets of APIs: the Admin APIs which are hosted on Sync Cloud and the Workspace APIs which may be hosted in your own deployment or in Sync Cloud depending on your Sync ECM edition.

## Starting Configuration

Once you start with Sync, you are assigned an Account object with a unique ID (prefixed `scd-` e.g. `scd-12345678`). Each account can have:

* One or more Dataspaces (ID prefixed with `sds-` e.g. `sds-12345678`), which consist of storage layers where your content and its metadata will be stored
* One or more Workspaces (ID prefixed with `sws-` e.g. `sws-12345678`), which consist of virtual (stateless) computing resources responsible for storing, retrieving and manipulating content and its metadata.
* Users and Agents that can interact with the Dataspaces/Workspaces and their underlying objects, as well as Roles that can be granted to each user/agent
* Other objects.


Each Dataspace is fully segmented from each other, much how a database server can have multiple databases within it. Workspaces are also isolated from each other, but any one Workspace can be used to access data across various Dataspaces. This distinction and isolation allows administrators to independently scale storage and compute resources to fit business needs.

## Dataspaces

Each Dataspace itself has the following major resources:

* A unique Ontology. The Ontology defines how content is organized within that dataspace. Users can define categories of content (e.g. “Driver's License” or “Purchase Agreement”), as well as other user-defined keys and values (such as “Customer Id” or “Fiscal Year”) that describe properties of the content and can be used to quickly group or filter content within the Dataspace.
* A collection of Content. Each Content consists of a file (such as a document, CAD file or a video recording), along with derivative data related to the file.
* A collection of Projects. Each Project acts as a container that groups together disparate pieces of Content according to business rules and logic. We recommend using projects to organize Content according to business-specific workflows and not by properties of the Content itself (that's what the Ontology is for!)


Dataspaces do not have their own compute resources; they simply represent data at rest: similar to a hard drive in your computer. As such, Dataspaces must always be accessed through a Workspace which provides the necessary computing power to perform operations over the Content.

## Workspaces

Workspaces are superficially simpler but complex under the hood: they are bundled, fully-managed computational services that are used to interact with the content such as search services, APIs for content transactions, AI models & Agents that operate on the conent etc.  Workspaces can be “scaled” up/down by administrators to provide more computing power as needed with a single dial, and administrators can set up different workspaces to handle and budget different business workloads on top of the same data. Workspaces are designed to only have an ephemeral state, meaning that scaling them down to 0 or a minimum size will not result in any data loss to the businesses. Furthermore, workspaces are desigened to be fully decoupled from storage, meaning that Datasspaces can continue to grow in size without needing to scale up Workspaces.