Authentication

Nearly everything you can do in the console, you can do over the API. Requests authenticate with an API key passed as a bearer token.

Create an API key

Go to Settings → API keys and create a key. When you create it you choose:

• Scope — read (safe for dashboards and monitoring; can't change anything) or full (can create, modify, and delete resources).
• Expiry — optional: never, 30 days, 90 days or a year in the console; any whole number of days up to 730 over the API. Set one for keys you hand to CI or third parties, and rotate them regularly.

Make an authenticated request

Send the key in the Authorization header as a bearer token:

curl https://console.ekire.net/api/v1/instances \
  -H "Authorization: Bearer $EKIRE_API_KEY"

All endpoints live under /api/v1. Request and response bodies are JSON.

# Deploy a server
curl -X POST https://console.ekire.net/api/v1/instances \
  -H "Authorization: Bearer $EKIRE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "planId": "nano", "regionId": "<region-id>", "osImageId": "<image-id>", "name": "api-demo" }'

Scopes

A read key that attempts a write is rejected with 403 Forbidden and the code read_only_key.

Scope isn't the only limit. A key of either scope is refused on the routes that add or remove a way to sign in — two-factor setup, passkeys, connected accounts — on creating an API key or changing a key's IP allowlist, on inviting a team member, resending an invite or changing a member's role, and on exporting your data and closing the account; those answer 403 with session_required, because these decisions need the person at the console, not a token sitting in CI. So a leaked key can't issue itself a successor, lift its own allowlist or bring someone onto your team: revoking it (which a key may still do, including itself) ends its access. What it changed while it worked stays, so after a leak also check your SSH keys and webhooks. A key also acts only as its own owner, never as a team account you've been given access to.

While an account is suspended — including the zero-balance billing lock — every key on it stops resolving and answers 401 invalid_token, the same reply a wrong key gets. Add funds in the console to bring them back.

IP allowlist

A key can be locked to the addresses it's allowed to call from. Set an IP allowlist when you create the key, or edit it any time from Settings → API keys (the shield button on a key). Entries are single IPs or IPv4 CIDRs, comma- or newline-separated:

203.0.113.4
198.51.100.0/24

With an allowlist set, a request from any other address is rejected with 403 Forbidden and the code ip_not_allowed — checked before anything else the key can do. Leave the allowlist blank and the key works from anywhere (the default). The address we match is the real source IP of the request, so put your server's or CI runner's egress IP here, not a local address. IPv6 callers list their exact address (no CIDR for v6).

Keep keys secure

• Never commit keys to source control or paste them into client-side code.
• Give each integration its own key, so you can revoke one without disrupting the others.
• Lock a key to its caller's IPs with the allowlist above when the integration runs from a fixed address.
• Set expiries and rotate. Revoke immediately from Settings → API keys if a key may be exposed.

Explore the API

The API reference is generated from the live OpenAPI schema and lists every endpoint, field, and response — with a built-in client so you can try calls right in the browser.