# Workspace, projects, environments

Source: https://www.jawsdeploy.net/rest-api/working-with-resources

How the core resource graph fits together when calling the API.

The Jaws Deploy resource graph is straightforward:

- An **organization** owns one or more **workspaces**.
- Each **workspace** holds the deployment topology: **projects**, **environments**, **feeds**, **lifecycles**, **tags**, **cloud accounts**, **step templates**, **script modules**, **workspace variables**.
- Each **project** has its own **channels**, **steps**, **variables**, and **releases**.
- A **release** is an immutable snapshot tied to a project, containing chosen package versions and the deployment plan at creation time. **Deployments** execute a release against one or more environments.

## Typical CI/CD call sequence

1. Upload built artifacts to a workspace feed: `POST /api/packagestore/package`.
2. Create a release: `POST /api/release`.
3. Deploy or promote it: `POST /api/release/deploy` or `POST /api/release/promote`.
4. Poll deployment status: `GET /api/deployment`.

Topology management endpoints (projects, environments, lifecycles, etc.) are available for teams that prefer to keep infrastructure-as-code in their own repos.