canonical: https://jentic.com/apis/cloud66.com/cloud66

# Cloud 66 API

Jentic publishes the only available OpenAPI specification for Cloud 66 API, keeping it validated and agent-ready. Cloud 66 is a DevOps-as-a-Service platform that deploys and manages applications on any cloud provider. The v3 API exposes stacks (the unit of an application deployment), servers under those stacks, services and containers, deployments, environment variables, settings, backups, firewalls, actions, notifications, and account-level data, so an integration can drive a full deploy-and-operate workflow against an existing Cloud 66 account.

## For AI agents

Trigger deployments, reboot servers, manage environment variables, and inspect stacks across Cloud 66-managed applications.

## Scope

Does not handle source-control hosting, CI build pipelines, or DNS registration - use for managing Cloud 66 stacks, deployments, and servers only.

## Capabilities

- List and create stacks that represent application deployments across cloud providers
- Trigger redeploys and other lifecycle actions against an existing stack
- Read and update environment variables for a stack without redeploying
- Reboot individual servers or all servers in a stack
- Inspect services and containers running on a stack and remove them when needed
- Configure stack-level settings such as deploy hooks and resource sizes
- Read account-level data and notifications across the user's stacks

## Use cases

### ChatOps Deploy Triggers

Trigger Cloud 66 deployments from a chat command or pull-request merge by calling POST `/stacks/{stack_uid}/deployments.json.` The endpoint kicks off the standard Cloud 66 deploy pipeline against the target stack, which removes the need for engineers to log into the Cloud 66 dashboard for routine releases. Combined with `/stacks/{stack_uid}/notifications`, the same workflow can post deploy results back into the chat channel.

Example prompt: Call POST `/stacks/{stack_uid}/deployments.json` for the production stack and poll until the deployment completes

### Auto-Healing and Restart Workflows

Build an auto-heal loop that detects failing services and reboots the underlying server or removes a stuck container. POST `/stacks/{stack_uid}/servers/{server_uid}/reboot_server.json` triggers a single-server reboot, POST `/stacks/{stack_uid}/reboot_servers.json` reboots the entire stack, and DELETE `/stacks/{stack_uid}/containers/{container_uid}.json` removes a problematic container. This pattern replaces ad-hoc SSH access for routine recovery actions.

Example prompt: If a stack reports a failing container, call DELETE `/stacks/{stack_uid}/containers/{container_uid}.json` then poll `/stacks/{stack_uid}/containers.json` until a replacement is healthy

### Configuration Drift Management

Sync environment variables and stack settings into Cloud 66 from a central config store so that drift between environments is eliminated. PUT `/stacks/{stack_uid}/environments/{key}.json` updates a single env var without redeploying, and GET `/stacks/{stack_uid}/settings.json` plus PUT `/stacks/{stack_uid}/settings/{key}.json` manage stack-level configuration. This is the standard pattern for keeping staging and production aligned.

Example prompt: Read env vars from a source-of-truth file and PUT `/stacks/{stack_uid}/environments/{key}.json` for each that differs

### Observability and Backup Audits

Pull the list of backups, server inventory, and notifications across an account into a central observability tool. GET `/stacks/{stack_uid}/backups.json`, GET `/stacks/{stack_uid}/servers.json`, and GET `/stacks/{stack_uid}/notifications` give enough surface to drive a backup-coverage report and an inventory dashboard for compliance reviews.

Example prompt: Iterate stacks via GET /stacks.json, then call GET `/stacks/{stack_uid}/backups.json` for each and report stacks with no backup in the past 24 hours

### Agent-Driven Deploy Workflows via Jentic

AI deployment assistants discover Cloud 66 operations through a Jentic search like 'redeploy my stack' and execute the call without parsing Cloud 66's REST docs. Jentic stores the OAuth token and issues a scoped credential per call that respects the requested scope (public, redeploy, jobs, admin), which keeps long-lived tokens out of agent context.

Example prompt: Search Jentic for 'redeploy cloud 66 stack', load POST `/stacks/{stack_uid}/deployments.json`, and execute it for the user-specified stack

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| GET | `/stacks.json` | List stacks in the account |
| POST | `/stacks` | Create a stack |
| POST | `/stacks/{stack_uid}/deployments.json` | Trigger a deployment |
| PUT | `/stacks/{stack_uid}/environments/{key}.json` | Update an environment variable |
| POST | `/stacks/{stack_uid}/servers/{server_uid}/reboot_server.json` | Reboot a server |
| GET | `/stacks/{stack_uid}/containers.json` | List containers on a stack |
| GET | `/stacks/{stack_uid}/backups.json` | List backups for a stack |
| POST | `/stacks/{stack_uid}/actions.json` | Trigger a stack action |

## Key resources

- **stacks** — Application deployment units across cloud providers
- **deployments** — Trigger and track stack deployments
- **servers** — Underlying compute servers attached to a stack
- **services** — Services running on a stack
- **containers** — Containers running on a stack
- **environments** — Environment variables for a stack
- **settings** — Stack-level configuration
- **backups** — Stack backups
- **accounts** — Cloud 66 account metadata

## Why Jentic

- **Setup:** Wiring Cloud 66 by hand means running its OAuth2 flow, minting scoped tokens (public, redeploy, jobs, admin), and pointing every call at app.cloud66.com/api/3 with your own refresh and retry handling. Through Jentic you install once, import the Cloud 66 API from the API Directory, store the OAuth credential once, and your agent calls it.
- **Permission scoping:** Cloud 66 puts the stack id in the URL path (`/stacks/{stack_uid}/...`), so a rule can pin your agent to one stack: it can read servers, containers, and backups and trigger deployments for that stack and nothing else. You choose the operations it may call, so actions like rebooting a server are only in reach if you include them.
- **Credential handling:** Your Cloud 66 OAuth credential is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'redeploy a stack' or 'reboot a server', and Jentic returns the matching Cloud 66 operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **Render** — Modern PaaS for deploying web services, static sites, and background workers.
- **DigitalOcean** — Cloud provider with App Platform, droplets, and Kubernetes.
- **Netlify** — Front-end hosting with Git-driven build pipelines.

## FAQ

### Why is there no official OpenAPI spec for Cloud 66 API?

Cloud 66 does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call Cloud 66 API via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer.

### What authentication does the Cloud 66 API use?

Cloud 66 uses OAuth 2.0 authorization-code flow with four scopes - public (read-only), redeploy (trigger deployments), jobs (manage jobs), and admin (full access). Through Jentic, the OAuth token is held in the vault and a scoped access token is issued per call so the raw token never enters the agent's context.

### Can I trigger a redeploy of a stack with this API?

Yes. POST `/stacks/{stack_uid}/deployments.json` kicks off a Cloud 66 deployment against the target stack, and the redeploy scope is the minimum scope required. Combine with GET `/stacks/{stack_uid}.json` to poll for deployment status.

### What are the rate limits for the Cloud 66 API?

Cloud 66 does not document a strict rate limit in this spec. Treat the API as low-volume control-plane traffic - back off on 429 responses and avoid bursting more than a few requests per second per OAuth token.

### How do I reboot a single server in a stack through Jentic?

Run pip install jentic, search for 'reboot cloud 66 server', load the POST `/stacks/{stack_uid}/servers/{server_uid}/reboot_server.json` operation, then execute with the stack_uid and server_uid. The call returns the action status.

### Can I update environment variables without redeploying?

Yes. PUT `/stacks/{stack_uid}/environments/{key}.json` updates a single environment variable on a stack and does not force a redeploy on its own. Use POST `/stacks/{stack_uid}/deployments.json` afterwards if the running app needs the new value.

### Can I limit what my agent is allowed to do with the Cloud 66 API?

Yes. Because you run Jentic One yourself, your own rules decide which Cloud 66 operations and which stored OAuth credential the agent may use. Since Cloud 66 puts the stack id in the URL path (`/stacks/{stack_uid}/...`), you can pin the agent to a single stack and pick exactly which operations it may call, for example letting it list servers, containers, and backups (GET `/stacks/{stack_uid}/servers.json`) and trigger deployments (POST `/stacks/{stack_uid}/deployments.json`) while withholding a destructive action like rebooting a server. Any operation you do not include stays out of the agent's reach.