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

# devopness API

The Devopness API exposes a complete DevOps automation platform that lets teams provision servers, deploy applications, manage credentials, and orchestrate environments without writing custom infrastructure tooling. It covers cloud server lifecycle, application deployments, cron jobs, daemons, network rules, SSH keys, SSL certificates, and pipelines across multiple environments. Two hundred or so endpoints provide programmatic access to every resource the Devopness web console manages, making it suitable for building higher-level deployment workflows or AI agent operators.

## For AI agents

Provision servers, deploy applications, configure environments, and run cron jobs and daemons through the Devopness DevOps platform. Covers credentials, networks, SSL certificates, and pipelines across staging and production.

## Scope

Does not handle source-code hosting, application monitoring, or container registry storage - use for DevOps deployment and environment orchestration only.

## Capabilities

- Trigger application deployments and re-run failed actions on existing servers
- Provision and manage cloud servers, daemons, and cron jobs across environments
- Configure environment variables, hooks, and pipeline steps for an application
- Manage SSH keys, SSL certificates, and source-code credentials used by deployments
- Define network rules, services, and load-balancer configuration per environment
- Inspect action logs and step outputs to diagnose failed deployments

## Use cases

### Automated Application Deployments

Trigger and monitor application deployments to staging and production environments without leaving the agent runtime. The Devopness API exposes a deployments endpoint per application that accepts the target environment, branch, and pipeline, then returns an action ID whose logs can be polled until success or failure. This replaces manual console clicks with a structured workflow that tracks every step.

Example prompt: Trigger a deployment of application 1234 to the production environment on branch main and poll the resulting action until it reports success or failure

### Server and Environment Provisioning

Provision new cloud servers, attach them to environments, and configure network rules and services without touching infrastructure consoles. The API exposes server creation, environment membership, network rule configuration, and service installation as discrete operations, letting agents stand up reproducible environments on demand. Useful for ephemeral preview environments and disaster-recovery setups.

Example prompt: Create a new server in the staging environment, install the web service role, and add an inbound network rule allowing TCP 443 from any source

### Credential and Key Rotation

Rotate SSH keys, source-code credentials, and SSL certificates programmatically across all environments. Devopness stores credentials per organisation and lets agents update them, list which repositories or applications consume each credential, and verify status after rotation. This makes scheduled credential rotation safe and auditable.

Example prompt: Update credential 5678 with a new GitHub personal access token and verify it can still reach all attached repositories

### AI Agent DevOps Operator

An AI agent acting as an on-call operator can use Devopness to investigate deployment failures, retry actions, and roll back changes in response to alerts. Through Jentic the agent searches for an operation by intent (such as retry deployment), loads the schema, and executes against the correct environment without hard-coding paths. This turns the Devopness console into a callable service for autonomous remediation.

Example prompt: On a deployment-failed alert, fetch the latest action log, identify the failing step, retry the deployment, and post the outcome to the on-call channel

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| GET | `/actions/{action_id}` | Retrieve the status and metadata for an action |
| POST | `/actions/{action_id}/retry` | Retry a failed action |
| POST | `/applications/{application_id}/deployments` | Trigger a deployment for an application |
| GET | `/applications/{application_id}/variables` | List environment variables for an application |
| GET | `/credentials/{credential_id}/get-status` | Check whether a credential is still valid |
| GET | `/cron-jobs/{cron_job_id}` | Retrieve a cron job definition and schedule |

## Key resources

- **Actions** — Track, retry, and inspect logs for any asynchronous operation including deployments and provisioning
- **Applications** — Manage application records, deployments, hooks, and environment variables
- **Environments** — Group servers, applications, credentials, networks, and services into staging or production environments
- **Servers** — Provision, configure, and remove cloud servers across supported providers
- **Credentials** — Store and rotate SSH keys, source control tokens, and provider credentials
- **Cron Jobs and Daemons** — Schedule recurring jobs and manage long-running background processes per environment

## Why Jentic

- **Setup:** Wiring the devopness API by hand means setting the bearer header and finding the operations you need across a 199-endpoint surface yourself. Through Jentic you install once, import the devopness API from the API Directory, store the bearer token once, and your agent calls it.
- **Permission scoping:** The application id travels in the URL path (`/applications/{application_id}/...`), so a rule can pin your agent to one application. You choose the operations it may call, so you can allow reading variables and triggering a deployment while leaving other actions out unless you add them.
- **Credential handling:** Your devopness bearer token 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 'deploy an application' or 'check an action's status', and Jentic returns the matching devopness operation with its input schema so the agent calls the right endpoint without reading the 199-endpoint spec.

## Related APIs

- **DigitalOcean API** — Cloud provider API offering droplets, Kubernetes, and managed services that Devopness orchestrates on top of
- **GitHub API** — Source-control side of the deployment loop - pair with Devopness to deploy specific commits or pull requests
- **Cloudflare API** — DNS, CDN, and edge-network configuration that complements Devopness server provisioning

## FAQ

### What authentication does the Devopness API use?

Devopness uses HTTP Bearer authentication. Requests must include an Authorization header carrying a personal or service token issued from the Devopness console. Through Jentic the token is stored in the encrypted vault and never enters the agent's prompt context.

### Can I trigger application deployments through the Devopness API?

Yes. POST to `/applications/{application_id}/deployments` with a target environment and branch returns an action ID. Polling GET `/actions/{action_id}` reports the deployment status, and POST `/actions/{action_id}/retry` retries a failed run without recreating the deployment record.

### What are the rate limits for the Devopness API?

Devopness does not publish a fixed public rate limit and applies fair-use throttling per token. For high-volume deployment automation, batch action polling and exponential backoff on 429 responses are recommended.

### How do I provision a new server through Jentic?

Run a Jentic search for "provision a server" to surface the Devopness server-creation operation, load its schema to see the required cloud provider and environment fields, and execute. The agent never needs the raw OpenAPI spec - Jentic returns the operation plus the input schema.

### Can the Devopness API manage cron jobs and background daemons?

Yes. The API exposes /cron-jobs and /daemons resources at both the environment and global level so agents can schedule recurring jobs, update commands, and start or stop long-running daemons attached to specific servers.

### How do I install the Jentic SDK to call Devopness?

Run pip install jentic, set JENTIC_AGENT_API_KEY to your ak_* key, then import Jentic, SearchRequest, LoadRequest, and ExecutionRequest. Run Jentic One, the self-hosted execution layer, to issue an API key.

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

Yes. You run Jentic One yourself, and your own rules decide which Devopness operations and credentials the agent may use. Because the application id travels in the URL path (`/applications/{application_id}/...`), you can pin the agent to a single application, and you choose the exact operations it may call, so you can allow listing variables and triggering a deployment while leaving other actions off unless you add them. The bearer token you store stays with your own instance and is injected only at execution time, never entering the agent's prompt or logs.