canonical: https://jentic.com/apis/runcloud.io/runcloud

# RunCloud API

RunCloud API allows you to manage your servers, web applications, databases, and more programmatically. The API exposes 13 endpoints secured with basic authentication.

## For AI agents

Programmatically test API authentication, create a server. Covers 13 operations with basic authentication.

## Scope

Does not handle payments, crm, or developer tools - use for communications only.

## Capabilities

- Test API authentication
- Create a server
- List servers
- Get server details
- Monitor RunCloud API operational status and events

## Use cases

### Communications Operations

Use the RunCloud API to perform communications operations programmatically. The API provides 13 endpoints covering core functionality including test API authentication, create a server, list servers.

Example prompt: Call GET /ping to test API authentication

### Automated Ping Management

Automate ping operations by combining multiple RunCloud API endpoints. Agents can create a server and then list servers in a single workflow.

Example prompt: Call POST /servers to create a server, then verify the result

### AI Agent Integration via Jentic

AI agents discover and call RunCloud API endpoints through Jentic without managing credentials directly. An agent searches for the required operation by intent, receives the matching endpoint schema, and executes the call with Jentic-managed authentication. This eliminates the need to read API documentation or handle basic tokens manually.

Example prompt: Search Jentic for 'test API authentication', load the operation schema, and execute with Jentic-managed credentials

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| GET | `/ping` | Test API authentication |
| POST | `/servers` | Create a server |
| GET | `/servers` | List servers |
| GET | `/servers/shared` | List shared servers |
| GET | `/servers/{id}` | Get server details |
| GET | `/servers/{id}/installationscript` | Get server installation script |
| GET | `/servers/{id}/stats` | Get server stats |
| GET | `/servers/{id}/hardwareinfo` | Get server hardware info |

## Key resources

- **Ping** — Operations for ping
- **Servers** — Operations for servers

## AI readiness

This API is usable in Jentic One now. Its AI-readiness score against Jentic's framework shows where it stands today and where improvements would make it even easier for agents to use.

- **Score:** 38 / 100
- **Maturity:** Non-Ready
- **Dimensions:**
  - Foundational Compliance: 99 / 100
  - Developer Experience & Jentic Compatibility: 63 / 100
  - AI-Readiness & Agent Experience: 42 / 100
  - Agent Usability: 94 / 100
  - Security: 10 / 100
  - AI Discoverability: 61 / 100
- **View full report:** https://jentic.com/apis/runcloud.io/runcloud/scorecard
- **How the score is calculated:** https://docs.jentic.com/reference/api-readiness-framework/overview/
- **More about the dimensions:** https://docs.jentic.com/reference/api-readiness-framework/specification/#dimensional-model-overview

### Score it yourself

Every API in the directory is allowlisted, so you can re-score it with no key required.

- **Score your own API:** https://jentic.com/scorecard.md
- **Scoring CLI agent skill:** https://github.com/jentic/jentic-api-scorecard/blob/main/skills/jentic-api-scorecard/SKILL.md

```sh
npx @jentic/api-scorecard-cli score <openapi-url>
```

## Why Jentic

- **Setup:** Wiring RunCloud by hand means setting up its basic auth against manage.runcloud.io/api/v2 and building your own request handling across the servers collection. Through Jentic you install once, import RunCloud from the API Directory, store the credential once, and your agent calls it.
- **Permission scoping:** RunCloud puts the server id in the URL path (`/servers/{id}`), so a rule can pin your agent to one server: it can read that server's details and stats and nothing else. You choose the operations it may call, so creating a server is not included unless you add it.
- **Credential handling:** Your RunCloud basic auth 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 'list my servers' or 'get a server's installation script', and Jentic returns the matching RunCloud operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **Twilio** — Alternative communications API
- **Sendgrid** — Alternative communications API
- **Pusher** — Complementary communications API

## FAQ

### What authentication does the RunCloud API use?

The RunCloud API uses HTTP Basic authentication with username and password. Through Jentic, these credentials are stored encrypted in your Jentic One instance and injected at execution time, so raw secrets never enter the agent context.

### Can I test API authentication with the RunCloud API?

Yes. Use the GET /ping endpoint. The API returns structured JSON responses that agents can parse and act on directly.

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

Rate limits are not specified in the OpenAPI spec. Check the vendor documentation for current limits. Through Jentic, rate limiting is handled automatically with retry logic built into the execution layer.

### How do I test API authentication through Jentic?

Install the Jentic SDK with pip install jentic, authenticate through Jentic One, the self-hosted execution layer, then search for 'test API authentication'. Jentic returns the matching RunCloud API operation with its input schema. Load the schema and execute the call - credentials are injected automatically.

### How many endpoints does the RunCloud API have?

The RunCloud API exposes 13 endpoints covering ping, servers operations.

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

Yes. Because Jentic One is self-hosted, you set the rules that decide which RunCloud operations and credentials your agent may use. Since RunCloud puts the server id in the URL path (`/servers/{id}`), you can pin an agent to a single server so it only reads that server's details and stats through endpoints like GET `/servers/{id}` and GET `/servers/{id}/stats.` You choose the operations it may call, so a write action such as POST /servers to create a server is excluded unless you explicitly allow it.